2020年終于快要結(jié)束了，對于大多數(shù)人來說，今年是一個悲催的一年。但是作為SaaS賽道來說，從各種角度來看，今年來算是真正的元年，中國SaaS賽道跨越了鴻溝階段，真正進(jìn)入了大時代。
在這個大時代里，所有SaaS公司面臨的一個嚴(yán)峻挑戰(zhàn)是公司的可持續(xù)發(fā)展性，大批SaaS公司會從前期三五年的虛假繁榮中慢慢沉寂，被新興的公司所取代，真正可以持續(xù)發(fā)展的SaaS公司會越來越強(qiáng)大，最終笑到最后，這個比例一定是很小的。 今天想跟大家討論的是筆者覺得作為SaaS公司非常非常重要的一個話題，SaaS產(chǎn)品的可持續(xù)發(fā)展性。 不知道大家有沒有發(fā)現(xiàn)發(fā)現(xiàn)一個有趣的現(xiàn)象，2000年前后幾年，實際上在中國大量的管理軟件公司成立，每個賽道都有相對比較優(yōu)秀的幾家公司，人事，CRM,ERP賽道都是如此，在市場上面也有相當(dāng)?shù)闹取?br/>但是20年過去了，我們看到每個賽道又開始有大量新的創(chuàng)業(yè)公司出現(xiàn)，占據(jù)了頭條以及所有的目光，很多老牌的供應(yīng)商仿佛從我們的視野里面消失了一般，他們還在嗎？如果他們還在，為什么這么多年的客戶，品牌，產(chǎn)品技術(shù)積累居然干不過新的創(chuàng)業(yè)公司呢？ 實際現(xiàn)實是，這些公司很多還活著，依據(jù)老客戶的維護(hù)費(fèi)以及每年波瀾不驚的新增活著，死不了，也活不好，也很難前進(jìn)了。這幾年我們很多新成立的SaaS創(chuàng)業(yè)公司實際上也在走他們的老路，正在走入泥潭，只是還需要幾年的時間才能陷得和他們一樣深，才能陷入一樣的狀況。 很多時候我們在評估一家公司的時候，我們看銷售增長率，看續(xù)約率，看銷售投入產(chǎn)出比。 但是在B端產(chǎn)品里面，特別是面向中大型客戶的市場，很多時候銷售是依靠資源驅(qū)動的，不是靠產(chǎn)品力，所以銷售市場能力以及融資能力強(qiáng)的公司是容易拿到客戶的，60分的產(chǎn)品打敗90分的產(chǎn)品是常事（當(dāng)然也有例外的場景，比如說筆者正在做的菜小秘，產(chǎn)品達(dá)不到很高的門檻，這群低文化老百姓是沒有辦法使用的）。 另外一點(diǎn)是B端客戶在使用產(chǎn)品之后，三五年內(nèi)是很難棄用的，因為棄用成本實在太高，做決策的人也很難打自己的臉，所以續(xù)約率在三五年內(nèi)都是很高的。所以大家可以看到，只要有錢，有資源，我們這三個數(shù)據(jù)似乎很容易做起來，在投資市場也很受熱捧，似乎產(chǎn)品只要馬馬虎虎，能夠湊合用就行了。 我們在產(chǎn)品上面馬馬虎虎，我們不斷的依據(jù)客戶需求湊合粗糙的增加新功能，慢慢的我們的產(chǎn)品越來越臃腫，易用性越來越差，我們發(fā)現(xiàn)：
1: 新客戶的實施周期越來越長，回款周期越長越長，很多尾款還收不到了。
2: 產(chǎn)品的新功能開發(fā)速度越來越慢，開發(fā)成本以及維護(hù)成本越來越高。
3: 產(chǎn)品越來越難用，客戶在忍受了三五年之后，實在受不了，還是轉(zhuǎn)投別人懷抱。
這個時候我們發(fā)現(xiàn)已經(jīng)陷入泥潭，我們發(fā)現(xiàn)產(chǎn)品需要做一些減法，但是已經(jīng)有一些量的客戶在用了，我們做減法比登天還難；產(chǎn)品用戶體驗差，實施周期長，維護(hù)成本高，開發(fā)速度越來越慢，用戶口碑越來越差，我們卻也無能為力。
另外我們還不能速死，也很難發(fā)展，經(jīng)過了很多年的掙扎，直到泥潭里面的泥沒過頭頂，也許我們內(nèi)心終于松一口氣，我們終于死了。 在中國，B端這塊，大家都說重視產(chǎn)品，但是實際上一直最重視的都是銷售。這么多年中國B端的產(chǎn)品力實質(zhì)上是沒有多少進(jìn)步的。除了續(xù)約，增長，銷售投入產(chǎn)出比等指標(biāo)以外，筆者強(qiáng)烈建議所有的SaaS創(chuàng)業(yè)公司以及投資公司好好的去評估一下自家產(chǎn)品另外一個重要指標(biāo)，那就是產(chǎn)品的可持續(xù)發(fā)展指數(shù)。
產(chǎn)品的可持續(xù)發(fā)展指數(shù)由很多因素決定，包括產(chǎn)品業(yè)務(wù)架構(gòu)，功能架構(gòu)，數(shù)據(jù)庫架構(gòu)，邏輯耦合度，產(chǎn)品易用性等一系列因素決定。
可持續(xù)發(fā)展性好的產(chǎn)品公司，會維持良好的用戶體驗；產(chǎn)品可擴(kuò)展性，可維護(hù)性強(qiáng)；新的開發(fā)效率高以及低以及實施培訓(xùn)周期短，回款快；另外客戶口碑好，用戶獲客成本不斷降低，會形成一個良好的正向發(fā)展循環(huán)。 怎樣實現(xiàn)產(chǎn)品的可持續(xù)發(fā)展是SaaS產(chǎn)研團(tuán)隊最核心的課題，筆者最近在崔牛會年會的產(chǎn)品閉門會以及人人年會上面做過一些關(guān)于可持續(xù)發(fā)展的產(chǎn)品原則的分享，再這里再整理分享一下這些原則：
1、整個產(chǎn)品策略先做薄，再做厚，每個迭代做小，做少，做極致
在產(chǎn)品MVP的階段，要圍繞核心痛點(diǎn)，選擇客戶愿意買單并且形成最小閉環(huán)的最小功能組合來進(jìn)行切入，整個產(chǎn)品路徑先做薄，再做厚，通過厚度來提升客單價以及客戶黏性。
比如說菜小秘剛開始找到的場景就是農(nóng)批商行賒欠管理的痛點(diǎn)，通過開單賒欠管理切入獲取到客戶，通過不斷的驗證迭代，慢慢延展到庫存，結(jié)算以及上游的貨主以及下游的買家的相關(guān)場景以及功能。 B端產(chǎn)品功能一旦被客戶使用之后，做減法和調(diào)整難度是極大的。所以在每個迭代過程中，遵循一個原則，就是做小，做少，做極致，怎樣控制需求以及設(shè)計的范圍是對產(chǎn)品力一個很大的挑戰(zhàn)。 另外一點(diǎn)對于B端產(chǎn)品產(chǎn)品就是不能先有再優(yōu)，對于數(shù)據(jù)庫設(shè)計，功能架構(gòu)，頁面架構(gòu)更是要努力做到極致，否則后續(xù)調(diào)整成本是非常大的。
2、做好架構(gòu)設(shè)計，為產(chǎn)品的生長留下空間
業(yè)務(wù)架構(gòu)，數(shù)據(jù)庫架構(gòu)，功能架構(gòu)是地基，地基錯了上面的一切都是錯的。
對于C端，我們有一個很經(jīng)典的怎樣做MVP以及產(chǎn)品驗證的圖，如下：
但是我們在B端產(chǎn)品里面，我們這樣去打造一個產(chǎn)品的MVP以及進(jìn)行需求驗證的話，你會發(fā)現(xiàn)每一次都要做完全的重構(gòu)，這種思路在B端產(chǎn)品一定是毀滅性的災(zāi)難。
我曾經(jīng)打過一個比方，C端產(chǎn)品更像是蓋大平房，B端產(chǎn)品更像是蓋小高樓，平房是很容易重構(gòu)的，但是高樓的地基沒有打好，后續(xù)的調(diào)整是毀滅性的，很多時候不得不推倒重來。所以如果我們真的要造一輛汽車，可能首先還是要先造一下發(fā)動機(jī)還有四個輪子，然后慢慢補(bǔ)充車窗，轉(zhuǎn)向燈，車蓋等物件。
作為B端產(chǎn)品來說，業(yè)務(wù)架構(gòu)，數(shù)據(jù)庫架構(gòu)，功能架構(gòu)極其重要，初創(chuàng)公司如果早期沒有合適的人才，也應(yīng)該找高手作為顧問來把關(guān)，否則浪費(fèi)大量時間和金錢不說，后患無窮。關(guān)于怎樣做B端產(chǎn)品的MVP, 我原來寫過一篇專門的文章“關(guān)于如何定義B端產(chǎn)品的MVP”，有興趣的關(guān)注一下SaaS產(chǎn)品說公眾號進(jìn)去閱讀。
產(chǎn)品是不斷生長的，要找到最好的分類以及架構(gòu)方式，為產(chǎn)品的生長留下空間。
我們需要記住的一點(diǎn)就是產(chǎn)品是不斷生長的，一點(diǎn)業(yè)務(wù)或者邏輯的增長，這一點(diǎn)業(yè)務(wù)或者邏輯都會不斷的去進(jìn)行生長，開枝散葉，最后變得非常復(fù)雜。
所以在做產(chǎn)品的時候除了需要需求克制以外，保證業(yè)務(wù)架構(gòu)，頁面架構(gòu)，數(shù)據(jù)庫架構(gòu)的合理性，實際上就是為了給產(chǎn)品的生長留下最合適的空間。
王興說過一句話，戰(zhàn)略就是分類，在思考產(chǎn)品架構(gòu)的時候，實際上也是找到最好的分類方式。
3、讓功能和數(shù)據(jù)來找用戶
精確的分發(fā)功能以及數(shù)據(jù)來給到每個場景下面的角色和用戶。
這句話似乎有點(diǎn)像推薦算法，實際上思路確實是類似的，大型復(fù)雜的erp系統(tǒng)動不動就有幾百上千個菜單，在這里面去找數(shù)據(jù)和功能是極其痛苦的。 很長一段時間，企業(yè)管理軟件就是體驗差的代名詞，但是隨著iphone以及移動互聯(lián)網(wǎng)的出現(xiàn)，很多設(shè)計理念開始普及，B端軟件的設(shè)計概念正在發(fā)生改變。 基于場景的簡約式設(shè)計越來越普遍，整個思路從讓用戶去找功能和數(shù)據(jù)，變成了讓功能和數(shù)據(jù)精確分發(fā)給每個場景下面的用戶角色。在這個過程中，理解用戶，理解場景變得非常重要。
做好系統(tǒng)首頁以及每個模塊，功能首頁的設(shè)計。
作為B端產(chǎn)品來說，首頁的設(shè)計很重要，這里的首頁包括系統(tǒng)首頁以及每個模塊，以及復(fù)雜功能的首頁面。
我們要了解的一點(diǎn)就是B端產(chǎn)品可能功能非常多，但是每個角色每天高頻使用的功能一定是很有限的，所以很關(guān)鍵的一點(diǎn)是做好首頁的設(shè)計。
我們要了解每個角色每天最關(guān)心的數(shù)據(jù)，最高頻使用的幾個功能，一些關(guān)鍵的信息通知，以及建議需要做的事情，實際上將首頁設(shè)計好，你會發(fā)現(xiàn)客戶只需要通過幾個首頁就可以完成80%以上的工作，這樣產(chǎn)品才能大幅降低學(xué)習(xí)成本。
4、找到真實的需求以及長期的解決方案
客戶說的大多數(shù)都是期望的解決方案，要找到客戶真實的需求。
很多時候我們都有這樣的經(jīng)驗，客戶很多時候提的需求都是他們希望的解決方案，不是真實的需求。
比如筆者最近碰到這樣的一個需求，就是客戶提出創(chuàng)建訂單之后，需要手工去修改訂單的時間，用戶需求很強(qiáng)烈。
如果不做，客戶不愿意繼續(xù)使用系統(tǒng)。我們覺得很奇怪，了解真實的情況之后發(fā)現(xiàn)，原來客戶經(jīng)營的菜品很多，高峰期的時候特別忙碌，搜索菜品開單開不過來，所以都是事后錄入訂單，所以需要修改訂單時間到真實的訂單時間便于統(tǒng)帳。真實的需求實際上是客戶要提升菜品很多的時候，需要提升開單時候選擇菜品的效率。
找到長期的，產(chǎn)品級別的最佳解決方案，否則需求很容易項目制。
在面對每個需求的時候，我們會發(fā)現(xiàn)實際上有很多可能的解決方案，我們不能一家家去做，需要要找到這類客戶的最佳業(yè)務(wù)實踐并且產(chǎn)品化，這樣可以避免不同客戶需求分化導(dǎo)致的項目制。另外這樣的最佳實踐可以大大提升客戶的效率，增加產(chǎn)品的附加價值。
5、區(qū)分需求的高低頻，普遍程度，價值高低，做好主線，保證極端情況有路可走
不要想面面俱到，必須要有所取舍。
在做產(chǎn)品的時候，不要想面面俱到，面面俱到的產(chǎn)品一定是一個平庸的產(chǎn)品。我曾經(jīng)碰到一個經(jīng)驗非常豐富非常努力的產(chǎn)品經(jīng)理, 在做新產(chǎn)品的時候，業(yè)務(wù)需求寫得極其詳盡，各種極端case的考慮極其全面，但是由于沒有取舍，沒有優(yōu)先級，產(chǎn)品遲遲無法推出。另外復(fù)雜度都花在極端case的處理上面，沒有輕重之分，團(tuán)隊疲憊不堪，產(chǎn)品體驗差，bug多，最后產(chǎn)品的結(jié)果是非常失敗的。
低頻，極端case不要想一定支持得非常友好，保證有路可走即可。
不要想把所有case都支持得非常方便，一般來說極端的case很多時候都要打破正常的主體邏輯。系統(tǒng)就要來建立一套規(guī)則的，如果需要打破規(guī)則之后還要把邏輯做圓，復(fù)雜度是非常高而且系統(tǒng)非常脆弱。
所以對于極端，低頻case不要想支持得非常友好，保證有路可走即可。你支持得非常好，就一定程度犧牲了高頻case的體驗，也從某種角度上面鼓勵大家去走小路了，對于業(yè)務(wù)也是不利的。 這里打一個簡單的比方，比如說休假申請審批過程中，已經(jīng)到了第二級審批人，這個時候申請人突然想修改申請單子，調(diào)整日期之類的，我們是否需要去支持一個審批過程中修改單子的功能呢？
也許是不需要的，針對這個case，可能最合適的解決方案，就是讓申請人跟上級線下說一下，讓上級拒絕申請，然后申請人重新提交就可以了，這樣的話已有系統(tǒng)不需要做任何改變。
這里的一個訣竅就是，對于低頻極端case，很多時候需要產(chǎn)品功能和線下動作配合去解決，不要想所有動作都線上化。
6、圍繞場景，避免過度設(shè)計
過度設(shè)計是對場景以及業(yè)務(wù)把握程度不夠。
過度設(shè)計會導(dǎo)致產(chǎn)品體驗不貼身，實施成本高的問題。
很多時候我們會走入一個誤區(qū)，為了避免定制開發(fā)，我們很多時候?qū)a(chǎn)品做得特別靈活，可配置性做的特別強(qiáng)，但是配置性做得特別強(qiáng)會帶來一些問題，比如說開發(fā)成本高，實施成本高，實施周期長，用戶體驗不貼身。 就像做衣服一樣，有的人胖一點(diǎn)，有些人瘦一點(diǎn)，為了做一件所有人都能穿的衣服，最后做了一件特別寬松的衣服，實際上這種衣服對于所有人都是不貼身的。在面向不同客戶的時候，每個人的需求形狀都是不一樣的，有的是長方形，有的是正方形，有的是圓形，有的不規(guī)則，最簡單的辦法就是畫一個大圓，把所有需求都滿足。但是真正的高手是做一個最小形狀的需求，剛好把所有形狀都能包含，非常貼身，無法做減法的產(chǎn)品才是最高境界的產(chǎn)品設(shè)計。 為了追求靈活度，我們看到有些公司的產(chǎn)品的數(shù)據(jù)庫都可以配置，最后導(dǎo)致的數(shù)據(jù)庫字段意義無法固定，所有邏輯都要可配置化，這種后果是很恐怖的。 所以從長期的角度來看，所有的HR,CRM,ERP市場最終的格局是產(chǎn)品越來越垂直化，基于客戶size有不同的產(chǎn)品線來滿足，另外大的垂直市場的垂直SaaS都會有很大機(jī)會，垂直化細(xì)分化的產(chǎn)品一定是長期的大勢所趨。
關(guān)于PaaS，在中國我并不看好，原因很多，可以以后單獨(dú)寫一篇。
7、合并同類項，減少復(fù)雜度
每一條小的邏輯支線都會隨著業(yè)務(wù)的發(fā)展不斷生長，開枝散葉。
由于產(chǎn)品不斷生長，前端設(shè)計也好，后端邏輯也好，盡量抽象合并，減少支線。
做產(chǎn)品，就是和復(fù)雜度做斗爭，所有的業(yè)務(wù)，邏輯都會開枝散葉，越來越復(fù)雜。我們怎樣用簡潔的邏輯支持復(fù)雜的case，我們怎樣在業(yè)務(wù)以及設(shè)計角度進(jìn)行抽象，合并同類項，用已有功能或者邏輯組合來滿足新的功能以及邏輯需求，是減少復(fù)雜度的非常重要的原則。
我們前端時間大熱的所謂中臺，核心邏輯其實也是合并同類項，實現(xiàn)共享，用這樣的思想去做系統(tǒng)就好了，不要過分追求概念化。
8、盡一切可能降低耦合度
耦合度的增加會導(dǎo)致產(chǎn)品的可維護(hù)，可擴(kuò)展性變差。
盡一切可能讓產(chǎn)品功能側(cè)，邏輯層的耦合度降低。
C端產(chǎn)品更多面向是點(diǎn)狀的需求，B端產(chǎn)品更多面向的是面狀的需求，需求之間的耦合度極高，在進(jìn)行產(chǎn)品設(shè)計開發(fā)的時候需要遵循降耦的原則，否則耦合度太高之后，后續(xù)的維護(hù)成本會非常高，產(chǎn)品的穩(wěn)定性也會變得比較差。
9、找到業(yè)務(wù)，產(chǎn)品，技術(shù)之間的最佳平衡點(diǎn)
不能完全產(chǎn)品或者需求驅(qū)動。
綜合考慮技術(shù)的實現(xiàn)成本，可擴(kuò)展性，可維護(hù)性，找到最佳的平衡點(diǎn)。
我們的口號一直說業(yè)務(wù)驅(qū)動，產(chǎn)品驅(qū)動。但是作為B端產(chǎn)品來說，沒有考慮技術(shù)角度的輸入，完全業(yè)務(wù)或者產(chǎn)品驅(qū)動會導(dǎo)致災(zāi)難性的后果。需要找到業(yè)務(wù)，產(chǎn)品，技術(shù)之間的最佳平衡點(diǎn)，保證產(chǎn)品的易用性，實現(xiàn)成本，可維護(hù)性，可擴(kuò)展性，實現(xiàn)產(chǎn)品的可持續(xù)發(fā)展，這對于所有SaaS公司來說都是綜合性的挑戰(zhàn)。 作為SaaS，中國最缺的不是產(chǎn)品或者技術(shù)，而是能夠快速理解業(yè)務(wù)，懂產(chǎn)品和技術(shù)類似解決方案架構(gòu)師這樣的復(fù)合性人才。 紅旗能打多久，SaaS能夠走多遠(yuǎn)，除了產(chǎn)品的定位，戰(zhàn)略以外，產(chǎn)品的可持續(xù)發(fā)展指數(shù)是非常非常核心的。
