原則系列-2020年終章之SaaS能夠走多遠
552
2020-12-21 16:36    文章來源:SaaS產品說
文章摘要:2020年終于快要結束了,對于大多數人來說,今年是一個悲催的一年

2020年終于快要結束了,對于大多數人來說,今年是一個悲催的一年。但是作為SaaS賽道來說,從各種角度來看,今年來算是真正的元年,中國SaaS賽道跨越了鴻溝階段,真正進入了大時代。

在這個大時代里,所有SaaS公司面臨的一個嚴峻挑戰是公司的可持續發展性,大批SaaS公司會從前期三五年的虛假繁榮中慢慢沉寂,被新興的公司所取代,真正可以持續發展的SaaS公司會越來越強大,最終笑到最后,這個比例一定是很小的。

今天想跟大家討論的是筆者覺得作為SaaS公司非常非常重要的一個話題,SaaS產品的可持續發展性。

不知道大家有沒有發現發現一個有趣的現象,2000年前后幾年,實際上在中國大量的管理軟件公司成立,每個賽道都有相對比較優秀的幾家公司,人事,CRM,ERP賽道都是如此,在市場上面也有相當的知名度。

但是20年過去了,我們看到每個賽道又開始有大量新的創業公司出現,占據了頭條以及所有的目光,很多老牌的供應商仿佛從我們的視野里面消失了一般,他們還在嗎?如果他們還在,為什么這么多年的客戶,品牌,產品技術積累居然干不過新的創業公司呢?

實際現實是,這些公司很多還活著,依據老客戶的維護費以及每年波瀾不驚的新增活著,死不了,也活不好,也很難前進了。這幾年我們很多新成立的SaaS創業公司實際上也在走他們的老路,正在走入泥潭,只是還需要幾年的時間才能陷得和他們一樣深,才能陷入一樣的狀況。

很多時候我們在評估一家公司的時候,我們看銷售增長率,看續約率,看銷售投入產出比。 

但是在B端產品里面,特別是面向中大型客戶的市場,很多時候銷售是依靠資源驅動的,不是靠產品力,所以銷售市場能力以及融資能力強的公司是容易拿到客戶的,60分的產品打敗90分的產品是常事(當然也有例外的場景,比如說筆者正在做的菜小秘,產品達不到很高的門檻,這群低文化老百姓是沒有辦法使用的)。

另外一點是B端客戶在使用產品之后,三五年內是很難棄用的,因為棄用成本實在太高,做決策的人也很難打自己的臉,所以續約率在三五年內都是很高的。所以大家可以看到,只要有錢,有資源,我們這三個數據似乎很容易做起來,在投資市場也很受熱捧,似乎產品只要馬馬虎虎,能夠湊合用就行了。 

我們在產品上面馬馬虎虎,我們不斷的依據客戶需求湊合粗糙的增加新功能,慢慢的我們的產品越來越臃腫,易用性越來越差,我們發現:

1: 新客戶的實施周期越來越長,回款周期越長越長,很多尾款還收不到了。

2: 產品的新功能開發速度越來越慢,開發成本以及維護成本越來越高。

3: 產品越來越難用,客戶在忍受了三五年之后,實在受不了,還是轉投別人懷抱。

這個時候我們發現已經陷入泥潭,我們發現產品需要做一些減法,但是已經有一些量的客戶在用了,我們做減法比登天還難;產品用戶體驗差,實施周期長,維護成本高,開發速度越來越慢,用戶口碑越來越差,我們卻也無能為力。

另外我們還不能速死,也很難發展,經過了很多年的掙扎,直到泥潭里面的泥沒過頭頂,也許我們內心終于松一口氣,我們終于死了。 

在中國,B端這塊,大家都說重視產品,但是實際上一直最重視的都是銷售。這么多年中國B端的產品力實質上是沒有多少進步的。除了續約,增長,銷售投入產出比等指標以外,筆者強烈建議所有的SaaS創業公司以及投資公司好好的去評估一下自家產品另外一個重要指標,那就是產品的可持續發展指數。

產品的可持續發展指數由很多因素決定,包括產品業務架構,功能架構,數據庫架構,邏輯耦合度,產品易用性等一系列因素決定。

可持續發展性好的產品公司,會維持良好的用戶體驗;產品可擴展性,可維護性強;新的開發效率高以及低以及實施培訓周期短,回款快;另外客戶口碑好,用戶獲客成本不斷降低,會形成一個良好的正向發展循環。

怎樣實現產品的可持續發展是SaaS產研團隊最核心的課題,筆者最近在崔牛會年會的產品閉門會以及人人年會上面做過一些關于可持續發展的產品原則的分享,再這里再整理分享一下這些原則: 

1: 整個產品策略先做薄,再做厚,每個迭代做小,做少,做極致。

在產品MVP的階段,要圍繞核心痛點,選擇客戶愿意買單并且形成最小閉環的最小功能組合來進行切入,整個產品路徑先做薄,再做厚,通過厚度來提升客單價以及客戶黏性。

比如說菜小秘剛開始找到的場景就是農批商行賒欠管理的痛點,通過開單賒欠管理切入獲取到客戶,通過不斷的驗證迭代,慢慢延展到庫存,結算以及上游的貨主以及下游的買家的相關場景以及功能。 

B端產品功能一旦被客戶使用之后,做減法和調整難度是極大的。所以在每個迭代過程中,遵循一個原則,就是做小,做少,做極致,怎樣控制需求以及設計的范圍是對產品力一個很大的挑戰。

另外一點對于B端產品產品就是不能先有再優,對于數據庫設計,功能架構,頁面架構更是要努力做到極致,否則后續調整成本是非常大的。

2: 做好架構設計,為產品的生長留下空間。

業務架構,數據庫架構,功能架構是地基,地基錯了上面的一切都是錯的。

對于C端,我們有一個很經典的怎樣做MVP以及產品驗證的圖,如下:

640.png

但是我們在B端產品里面,我們這樣去打造一個產品的MVP以及進行需求驗證的話,你會發現每一次都要做完全的重構,這種思路在B端產品一定是毀滅性的災難。

我曾經打過一個比方,C端產品更像是蓋大平房,B端產品更像是蓋小高樓,平房是很容易重構的,但是高樓的地基沒有打好,后續的調整是毀滅性的,很多時候不得不推倒重來。所以如果我們真的要造一輛汽車,可能首先還是要先造一下發動機還有四個輪子,然后慢慢補充車窗,轉向燈,車蓋等物件。

作為B端產品來說,業務架構,數據庫架構,功能架構極其重要,初創公司如果早期沒有合適的人才,也應該找高手作為顧問來把關,否則浪費大量時間和金錢不說,后患無窮。關于怎樣做B端產品的MVP, 我原來寫過一篇專門的文章“關于如何定義B端產品的MVP”,有興趣的關注一下SaaS產品說公眾號進去閱讀。

產品是不斷生長的,要找到最好的分類以及架構方式,為產品的生長留下空間。

我們需要記住的一點就是產品是不斷生長的,一點業務或者邏輯的增長,這一點業務或者邏輯都會不斷的去進行生長,開枝散葉,最后變得非常復雜。

所以在做產品的時候除了需要需求克制以外,保證業務架構,頁面架構,數據庫架構的合理性,實際上就是為了給產品的生長留下最合適的空間。

王興說過一句話,戰略就是分類,在思考產品架構的時候,實際上也是找到最好的分類方式。 

3: 讓功能和數據來找用戶。

精確的分發功能以及數據來給到每個場景下面的角色和用戶。

這句話似乎有點像推薦算法,實際上思路確實是類似的,大型復雜的erp系統動不動就有幾百上千個菜單,在這里面去找數據和功能是極其痛苦的。 

很長一段時間,企業管理軟件就是體驗差的代名詞,但是隨著iphone以及移動互聯網的出現,很多設計理念開始普及,B端軟件的設計概念正在發生改變。

基于場景的簡約式設計越來越普遍,整個思路從讓用戶去找功能和數據,變成了讓功能和數據精確分發給每個場景下面的用戶角色。在這個過程中,理解用戶,理解場景變得非常重要。

做好系統首頁以及每個模塊,功能首頁的設計。

作為B端產品來說,首頁的設計很重要,這里的首頁包括系統首頁以及每個模塊,以及復雜功能的首頁面。

我們要了解的一點就是B端產品可能功能非常多,但是每個角色每天高頻使用的功能一定是很有限的,所以很關鍵的一點是做好首頁的設計。

我們要了解每個角色每天最關心的數據,最高頻使用的幾個功能,一些關鍵的信息通知,以及建議需要做的事情,實際上將首頁設計好,你會發現客戶只需要通過幾個首頁就可以完成80%以上的工作,這樣產品才能大幅降低學習成本。

4: 找到真實的需求以及長期的解決方案。

客戶說的大多數都是期望的解決方案,要找到客戶真實的需求。

很多時候我們都有這樣的經驗,客戶很多時候提的需求都是他們希望的解決方案,不是真實的需求。

比如筆者最近碰到這樣的一個需求,就是客戶提出創建訂單之后,需要手工去修改訂單的時間,用戶需求很強烈。

如果不做,客戶不愿意繼續使用系統。我們覺得很奇怪,了解真實的情況之后發現,原來客戶經營的菜品很多,高峰期的時候特別忙碌,搜索菜品開單開不過來,所以都是事后錄入訂單,所以需要修改訂單時間到真實的訂單時間便于統帳。真實的需求實際上是客戶要提升菜品很多的時候,需要提升開單時候選擇菜品的效率。

找到長期的,產品級別的最佳解決方案,否則需求很容易項目制。

在面對每個需求的時候,我們會發現實際上有很多可能的解決方案,我們不能一家家去做,需要要找到這類客戶的最佳業務實踐并且產品化,這樣可以避免不同客戶需求分化導致的項目制。另外這樣的最佳實踐可以大大提升客戶的效率,增加產品的附加價值。 

5: 區分需求的高低頻,普遍程度,價值高低,做好主線,保證極端情況有路可走。

不要想面面俱到,必須要有所取舍。

在做產品的時候,不要想面面俱到,面面俱到的產品一定是一個平庸的產品。我曾經碰到一個經驗非常豐富非常努力的產品經理, 在做新產品的時候,業務需求寫得極其詳盡,各種極端case的考慮極其全面,但是由于沒有取舍,沒有優先級,產品遲遲無法推出。另外復雜度都花在極端case的處理上面,沒有輕重之分,團隊疲憊不堪,產品體驗差,bug多,最后產品的結果是非常失敗的。 

低頻,極端case不要想一定支持得非常友好,保證有路可走即可。

不要想把所有case都支持得非常方便,一般來說極端的case很多時候都要打破正常的主體邏輯。系統就要來建立一套規則的,如果需要打破規則之后還要把邏輯做圓,復雜度是非常高而且系統非常脆弱。

所以對于極端,低頻case不要想支持得非常友好,保證有路可走即可。你支持得非常好,就一定程度犧牲了高頻case的體驗,也從某種角度上面鼓勵大家去走小路了,對于業務也是不利的。 

這里打一個簡單的比方,比如說休假申請審批過程中,已經到了第二級審批人,這個時候申請人突然想修改申請單子,調整日期之類的,我們是否需要去支持一個審批過程中修改單子的功能呢?

也許是不需要的,針對這個case,可能最合適的解決方案,就是讓申請人跟上級線下說一下,讓上級拒絕申請,然后申請人重新提交就可以了,這樣的話已有系統不需要做任何改變。

這里的一個訣竅就是,對于低頻極端case,很多時候需要產品功能和線下動作配合去解決,不要想所有動作都線上化。

6: 圍繞場景,避免過度設計

過度設計是對場景以及業務把握程度不夠。

過度設計會導致產品體驗不貼身,實施成本高的問題。

很多時候我們會走入一個誤區,為了避免定制開發,我們很多時候將產品做得特別靈活,可配置性做的特別強,但是配置性做得特別強會帶來一些問題,比如說開發成本高,實施成本高,實施周期長,用戶體驗不貼身。

就像做衣服一樣,有的人胖一點,有些人瘦一點,為了做一件所有人都能穿的衣服,最后做了一件特別寬松的衣服,實際上這種衣服對于所有人都是不貼身的。在面向不同客戶的時候,每個人的需求形狀都是不一樣的,有的是長方形,有的是正方形,有的是圓形,有的不規則,最簡單的辦法就是畫一個大圓,把所有需求都滿足。但是真正的高手是做一個最小形狀的需求,剛好把所有形狀都能包含,非常貼身,無法做減法的產品才是最高境界的產品設計。 

為了追求靈活度,我們看到有些公司的產品的數據庫都可以配置,最后導致的數據庫字段意義無法固定,所有邏輯都要可配置化,這種后果是很恐怖的。

所以從長期的角度來看,所有的HR,CRM,ERP市場最終的格局是產品越來越垂直化,基于客戶size有不同的產品線來滿足,另外大的垂直市場的垂直SaaS都會有很大機會,垂直化細分化的產品一定是長期的大勢所趨。

關于PaaS,在中國我并不看好,原因很多,可以以后單獨寫一篇。 

7: 合并同類項,減少復雜度

每一條小的邏輯支線都會隨著業務的發展不斷生長,開枝散葉。

由于產品不斷生長,前端設計也好,后端邏輯也好,盡量抽象合并,減少支線。

做產品,就是和復雜度做斗爭,所有的業務,邏輯都會開枝散葉,越來越復雜。我們怎樣用簡潔的邏輯支持復雜的case,我們怎樣在業務以及設計角度進行抽象,合并同類項,用已有功能或者邏輯組合來滿足新的功能以及邏輯需求,是減少復雜度的非常重要的原則。

我們前端時間大熱的所謂中臺,核心邏輯其實也是合并同類項,實現共享,用這樣的思想去做系統就好了,不要過分追求概念化。

8: 盡一切可能降低耦合度

耦合度的增加會導致產品的可維護,可擴展性變差。

盡一切可能讓產品功能側,邏輯層的耦合度降低。

C端產品更多面向是點狀的需求,B端產品更多面向的是面狀的需求,需求之間的耦合度極高,在進行產品設計開發的時候需要遵循降耦的原則,否則耦合度太高之后,后續的維護成本會非常高,產品的穩定性也會變得比較差。

9: 找到業務,產品,技術之間的最佳平衡點。

不能完全產品或者需求驅動。

綜合考慮技術的實現成本,可擴展性,可維護性,找到最佳的平衡點。

我們的口號一直說業務驅動,產品驅動。但是作為B端產品來說,沒有考慮技術角度的輸入,完全業務或者產品驅動會導致災難性的后果。需要找到業務,產品,技術之間的最佳平衡點,保證產品的易用性,實現成本,可維護性,可擴展性,實現產品的可持續發展,這對于所有SaaS公司來說都是綜合性的挑戰。

作為SaaS,中國最缺的不是產品或者技術,而是能夠快速理解業務,懂產品和技術類似解決方案架構師這樣的復合性人才。

紅旗能打多久,SaaS能夠走多遠,除了產品的定位,戰略以外,產品的可持續發展指數是非常非常核心的。 


版權聲明:

凡本網內容請注明來源:T媒體(http://www.279457.tw)”的所有原創作品,版權均屬于易信視界(北京)信息科技有限公司所有,未經本網書面授權,不得轉載、摘編或以其它方式使用上述作品。

本網書面授權使用作品的,應在授權范圍內使用,并按雙方協議注明作品來源。違反上述聲明者,易信視界(北京)信息科技有限公司將追究其相關法律責任。

評論

(^ω^)MG艺伎故事首页 500万足球比分网 天天捕鱼官方正版下载 大东方娱乐官方网站-点击进入 AB真人-官网 陕西快乐十分奖金图 湖北11选5任选基本 三分彩龙虎万个位计划 日本雅虎官网棒球比分 比特币平台乱象 四川麻将群 中国竞彩 重庆时时彩综合走势 112期码报报特诗 广东快乐10分钟技巧 篮球让分胜负技巧 大赢家比分足球比分及时比分