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

在這個大時代里，所有SaaS公司面臨的一個嚴峻挑戰(zhàn)是公司的可持續(xù)發(fā)展性，大批SaaS公司會從前期三五年的虛假繁榮中慢慢沉寂，被新興的公司所取代，真正可以持續(xù)發(fā)展的SaaS公司會越來越強大，最終笑到最后，這個比例一定是很小的。 今天想跟大家討論的是筆者覺得作為SaaS公司非常非常重要的一個話題，SaaS產(chǎn)品的可持續(xù)發(fā)展性。 不知道大家有沒有發(fā)現(xiàn)發(fā)現(xiàn)一個有趣的現(xiàn)象，2000年前后幾年，實際上在中國大量的管理軟件公司成立，每個賽道都有相對比較優(yōu)秀的幾家公司，人事，CRM,ERP賽道都是如此，在市場上面也有相當?shù)闹取?br/>但是20年過去了，我們看到每個賽道又開始有大量新的創(chuàng)業(yè)公司出現(xiàn)，占據(jù)了頭條以及所有的目光，很多老牌的供應商仿佛從我們的視野里面消失了一般，他們還在嗎？如果他們還在，為什么這么多年的客戶，品牌，產(chǎn)品技術(shù)積累居然干不過新的創(chuàng)業(yè)公司呢？ 實際現(xiàn)實是，這些公司很多還活著，依據(jù)老客戶的維護費以及每年波瀾不驚的新增活著，死不了，也活不好，也很難前進了。這幾年我們很多新成立的SaaS創(chuàng)業(yè)公司實際上也在走他們的老路，正在走入泥潭，只是還需要幾年的時間才能陷得和他們一樣深，才能陷入一樣的狀況。 很多時候我們在評估一家公司的時候，我們看銷售增長率，看續(xù)約率，看銷售投入產(chǎn)出比。 但是在B端產(chǎn)品里面，特別是面向中大型客戶的市場，很多時候銷售是依靠資源驅(qū)動的，不是靠產(chǎn)品力，所以銷售市場能力以及融資能力強的公司是容易拿到客戶的，60分的產(chǎn)品打敗90分的產(chǎn)品是常事（當然也有例外的場景，比如說筆者正在做的菜小秘，產(chǎ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ā)成本以及維護成本越來越高。
3: 產(chǎn)品越來越難用，客戶在忍受了三五年之后，實在受不了，還是轉(zhuǎn)投別人懷抱。

這個時候我們發(fā)現(xiàn)已經(jīng)陷入泥潭，我們發(fā)現(xiàn)產(chǎn)品需要做一些減法，但是已經(jīng)有一些量的客戶在用了，我們做減法比登天還難；產(chǎn)品用戶體驗差，實施周期長，維護成本高，開發(fā)速度越來越慢，用戶口碑越來越差，我們卻也無能為力。
另外我們還不能速死，也很難發(fā)展，經(jīng)過了很多年的掙扎，直到泥潭里面的泥沒過頭頂，也許我們內(nèi)心終于松一口氣，我們終于死了。 在中國，B端這塊，大家都說重視產(chǎn)品，但是實際上一直最重視的都是銷售。這么多年中國B端的產(chǎn)品力實質(zhì)上是沒有多少進步的。除了續(xù)約，增長，銷售投入產(chǎn)出比等指標以外，筆者強烈建議所有的SaaS創(chuàng)業(yè)公司以及投資公司好好的去評估一下自家產(chǎn)品另外一個重要指標，那就是產(chǎn)品的可持續(xù)發(fā)展指數(shù)。
產(chǎn)品的可持續(xù)發(fā)展指數(shù)由很多因素決定，包括產(chǎn)品業(yè)務架構(gòu)，功能架構(gòu)，數(shù)據(jù)庫架構(gòu)，邏輯耦合度，產(chǎn)品易用性等一系列因素決定。
可持續(xù)發(fā)展性好的產(chǎn)品公司，會維持良好的用戶體驗；產(chǎn)品可擴展性，可維護性強；新的開發(fā)效率高以及低以及實施培訓周期短，回款快；另外客戶口碑好，用戶獲客成本不斷降低，會形成一個良好的正向發(fā)展循環(huán)。 怎樣實現(xiàn)產(chǎn)品的可持續(xù)發(fā)展是SaaS產(chǎn)研團隊最核心的課題，筆者最近在崔牛會年會的產(chǎn)品閉門會以及人人年會上面做過一些關(guān)于可持續(xù)發(fā)展的產(chǎn)品原則的分享，再這里再整理分享一下這些原則：

1、整個產(chǎn)品策略先做薄，再做厚，每個迭代做小，做少，做極致
在產(chǎn)品MVP的階段，要圍繞核心痛點，選擇客戶愿意買單并且形成最小閉環(huán)的最小功能組合來進行切入，整個產(chǎn)品路徑先做薄，再做厚，通過厚度來提升客單價以及客戶黏性。
比如說菜小秘剛開始找到的場景就是農(nóng)批商行賒欠管理的痛點，通過開單賒欠管理切入獲取到客戶，通過不斷的驗證迭代，慢慢延展到庫存，結(jié)算以及上游的貨主以及下游的買家的相關(guān)場景以及功能。 B端產(chǎn)品功能一旦被客戶使用之后，做減法和調(diào)整難度是極大的。所以在每個迭代過程中，遵循一個原則，就是做小，做少，做極致，怎樣控制需求以及設(shè)計的范圍是對產(chǎn)品力一個很大的挑戰(zhà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è)務架構(gòu)，數(shù)據(jù)庫架構(gòu)，功能架構(gòu)是地基，地基錯了上面的一切都是錯的。

對于C端，我們有一個很經(jīng)典的怎樣做MVP以及產(chǎn)品驗證的圖，如下：

但是我們在B端產(chǎn)品里面，我們這樣去打造一個產(chǎn)品的MVP以及進行需求驗證的話，你會發(fā)現(xiàn)每一次都要做完全的重構(gòu)，這種思路在B端產(chǎn)品一定是毀滅性的災難。
我曾經(jīng)打過一個比方，C端產(chǎn)品更像是蓋大平房，B端產(chǎn)品更像是蓋小高樓，平房是很容易重構(gòu)的，但是高樓的地基沒有打好，后續(xù)的調(diào)整是毀滅性的，很多時候不得不推倒重來。所以如果我們真的要造一輛汽車，可能首先還是要先造一下發(fā)動機還有四個輪子，然后慢慢補充車窗，轉(zhuǎn)向燈，車蓋等物件。
作為B端產(chǎn)品來說，業(yè)務架構(gòu)，數(shù)據(jù)庫架構(gòu)，功能架構(gòu)極其重要，初創(chuàng)公司如果早期沒有合適的人才，也應該找高手作為顧問來把關(guān)，否則浪費大量時間和金錢不說，后患無窮。關(guān)于怎樣做B端產(chǎn)品的MVP, 我原來寫過一篇專門的文章“關(guān)于如何定義B端產(chǎn)品的MVP”，有興趣的關(guān)注一下SaaS產(chǎn)品說公眾號進去閱讀。

產(chǎn)品是不斷生長的，要找到最好的分類以及架構(gòu)方式，為產(chǎn)品的生長留下空間。

我們需要記住的一點就是產(chǎn)品是不斷生長的，一點業(yè)務或者邏輯的增長，這一點業(yè)務或者邏輯都會不斷的去進行生長，開枝散葉，最后變得非常復雜。
所以在做產(chǎn)品的時候除了需要需求克制以外，保證業(yè)務架構(gòu)，頁面架構(gòu)，數(shù)據(jù)庫架構(gòu)的合理性，實際上就是為了給產(chǎn)品的生長留下最合適的空間。
王興說過一句話，戰(zhàn)略就是分類，在思考產(chǎn)品架構(gòu)的時候，實際上也是找到最好的分類方式。

 3、讓功能和數(shù)據(jù)來找用戶

精確的分發(fā)功能以及數(shù)據(jù)來給到每個場景下面的角色和用戶。

這句話似乎有點像推薦算法，實際上思路確實是類似的，大型復雜的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)首頁以及每個模塊，以及復雜功能的首頁面。
我們要了解的一點就是B端產(chǎn)品可能功能非常多，但是每個角色每天高頻使用的功能一定是很有限的，所以很關(guān)鍵的一點是做好首頁的設(shè)計。
我們要了解每個角色每天最關(guān)心的數(shù)據(jù)，最高頻使用的幾個功能，一些關(guān)鍵的信息通知，以及建議需要做的事情，實際上將首頁設(shè)計好，你會發(fā)現(xiàn)客戶只需要通過幾個首頁就可以完成80%以上的工作，這樣產(chǎn)品才能大幅降低學習成本。
 4、找到真實的需求以及長期的解決方案

客戶說的大多數(shù)都是期望的解決方案，要找到客戶真實的需求。

很多時候我們都有這樣的經(jīng)驗，客戶很多時候提的需求都是他們希望的解決方案，不是真實的需求。
比如筆者最近碰到這樣的一個需求，就是客戶提出創(chuàng)建訂單之后，需要手工去修改訂單的時間，用戶需求很強烈。
如果不做，客戶不愿意繼續(xù)使用系統(tǒng)。我們覺得很奇怪，了解真實的情況之后發(fā)現(xiàn)，原來客戶經(jīng)營的菜品很多，高峰期的時候特別忙碌，搜索菜品開單開不過來，所以都是事后錄入訂單，所以需要修改訂單時間到真實的訂單時間便于統(tǒng)帳。真實的需求實際上是客戶要提升菜品很多的時候，需要提升開單時候選擇菜品的效率。

找到長期的，產(chǎn)品級別的最佳解決方案，否則需求很容易項目制。

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

5、區(qū)分需求的高低頻，普遍程度，價值高低，做好主線，保證極端情況有路可走

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

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

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

不要想把所有case都支持得非常方便，一般來說極端的case很多時候都要打破正常的主體邏輯。系統(tǒng)就要來建立一套規(guī)則的，如果需要打破規(guī)則之后還要把邏輯做圓，復雜度是非常高而且系統(tǒng)非常脆弱。
所以對于極端，低頻case不要想支持得非常友好，保證有路可走即可。你支持得非常好，就一定程度犧牲了高頻case的體驗，也從某種角度上面鼓勵大家去走小路了，對于業(yè)務也是不利的。 這里打一個簡單的比方，比如說休假申請審批過程中，已經(jīng)到了第二級審批人，這個時候申請人突然想修改申請單子，調(diào)整日期之類的，我們是否需要去支持一個審批過程中修改單子的功能呢？
也許是不需要的，針對這個case，可能最合適的解決方案，就是讓申請人跟上級線下說一下，讓上級拒絕申請，然后申請人重新提交就可以了，這樣的話已有系統(tǒng)不需要做任何改變。
這里的一個訣竅就是，對于低頻極端case，很多時候需要產(chǎn)品功能和線下動作配合去解決，不要想所有動作都線上化。 

6、圍繞場景，避免過度設(shè)計

過度設(shè)計是對場景以及業(yè)務把握程度不夠。

過度設(shè)計會導致產(chǎn)品體驗不貼身，實施成本高的問題。

很多時候我們會走入一個誤區(qū)，為了避免定制開發(fā)，我們很多時候?qū)a(chǎn)品做得特別靈活，可配置性做的特別強，但是配置性做得特別強會帶來一些問題，比如說開發(fā)成本高，實施成本高，實施周期長，用戶體驗不貼身。 就像做衣服一樣，有的人胖一點，有些人瘦一點，為了做一件所有人都能穿的衣服，最后做了一件特別寬松的衣服，實際上這種衣服對于所有人都是不貼身的。在面向不同客戶的時候，每個人的需求形狀都是不一樣的，有的是長方形，有的是正方形，有的是圓形，有的不規(guī)則，最簡單的辦法就是畫一個大圓，把所有需求都滿足。但是真正的高手是做一個最小形狀的需求，剛好把所有形狀都能包含，非常貼身，無法做減法的產(chǎn)品才是最高境界的產(chǎn)品設(shè)計。 為了追求靈活度，我們看到有些公司的產(chǎn)品的數(shù)據(jù)庫都可以配置，最后導致的數(shù)據(jù)庫字段意義無法固定，所有邏輯都要可配置化，這種后果是很恐怖的。 所以從長期的角度來看，所有的HR,CRM,ERP市場最終的格局是產(chǎn)品越來越垂直化，基于客戶size有不同的產(chǎn)品線來滿足，另外大的垂直市場的垂直SaaS都會有很大機會，垂直化細分化的產(chǎn)品一定是長期的大勢所趨。
關(guān)于PaaS，在中國我并不看好，原因很多，可以以后單獨寫一篇。 

7、合并同類項，減少復雜度

每一條小的邏輯支線都會隨著業(yè)務的發(fā)展不斷生長，開枝散葉。

由于產(chǎn)品不斷生長，前端設(shè)計也好，后端邏輯也好，盡量抽象合并，減少支線。

做產(chǎn)品，就是和復雜度做斗爭，所有的業(yè)務，邏輯都會開枝散葉，越來越復雜。我們怎樣用簡潔的邏輯支持復雜的case，我們怎樣在業(yè)務以及設(shè)計角度進行抽象，合并同類項，用已有功能或者邏輯組合來滿足新的功能以及邏輯需求，是減少復雜度的非常重要的原則。
我們前端時間大熱的所謂中臺，核心邏輯其實也是合并同類項，實現(xiàn)共享，用這樣的思想去做系統(tǒng)就好了，不要過分追求概念化。 

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

耦合度的增加會導致產(chǎn)品的可維護，可擴展性變差。

盡一切可能讓產(chǎn)品功能側(cè)，邏輯層的耦合度降低。

C端產(chǎn)品更多面向是點狀的需求，B端產(chǎn)品更多面向的是面狀的需求，需求之間的耦合度極高，在進行產(chǎn)品設(shè)計開發(fā)的時候需要遵循降耦的原則，否則耦合度太高之后，后續(xù)的維護成本會非常高，產(chǎn)品的穩(wěn)定性也會變得比較差。
9、找到業(yè)務，產(chǎn)品，技術(shù)之間的最佳平衡點

不能完全產(chǎn)品或者需求驅(qū)動。

綜合考慮技術(shù)的實現(xiàn)成本，可擴展性，可維護性，找到最佳的平衡點。

我們的口號一直說業(yè)務驅(qū)動，產(chǎn)品驅(qū)動。但是作為B端產(chǎn)品來說，沒有考慮技術(shù)角度的輸入，完全業(yè)務或者產(chǎn)品驅(qū)動會導致災難性的后果。需要找到業(yè)務，產(chǎn)品，技術(shù)之間的最佳平衡點，保證產(chǎn)品的易用性，實現(xiàn)成本，可維護性，可擴展性，實現(xiàn)產(chǎn)品的可持續(xù)發(fā)展，這對于所有SaaS公司來說都是綜合性的挑戰(zhàn)。 作為SaaS，中國最缺的不是產(chǎn)品或者技術(shù)，而是能夠快速理解業(yè)務，懂產(chǎn)品和技術(shù)類似解決方案架構(gòu)師這樣的復合性人才。 紅旗能打多久，SaaS能夠走多遠，除了產(chǎn)品的定位，戰(zhàn)略以外，產(chǎn)品的可持續(xù)發(fā)展指數(shù)是非常非常核心的。