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

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

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

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

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

但是在B端產品裡面，特別是面向中大型客戶的市場，很多時候銷售是依靠資源驅動的，不是靠產品力，所以銷售市場能力以及融資能力強的公司是容易拿到客戶的，60分的產品打敗90分的產品是常事。

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

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

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

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

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

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

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

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

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

可持續發展性好的產品公司，會維持良好的使用者體驗；產品可擴充套件性，可維護性強；新的開發效率高以及低以及實施培訓週期短，回款快；另外客戶口碑好，使用者獲客成本不斷降低，會形成一個良好的正向發展迴圈。

怎樣實現產品的可持續發展？

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

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

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

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

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

業務架構，資料庫架構，功能架構是地基，地基錯了上面的一切都是錯的。

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

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

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

作為B端產品來說，業務架構，資料庫架構，功能架構極其重要，初創公司如果早期沒有合適的人才，也應該找高手作為顧問來把關，否則浪費大量時間和金錢不說，後患無窮。

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

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

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

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

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公司來說都是綜合性的挑戰。