作為藍海市場的SaaS行業，盡管大廠們投入了大量的人力和資金，依舊沒能獲得很好的盈利。很大部分原因在于，公司提供标準化的産品，但客戶總有各種個性化需求，為了滿足客戶，隻能增加成本做定制化産品。面對這樣的困局，應該如何突破？一起來看看作者的觀點。

晚上10點多，一位SaaS公司CEO發了一篇文章給我，裡面講述了某市值近萬億的大公司，經過2年的孵化，推出了一款HR SaaS産品。但是在商業化3年以後，于今年6月宣布終止，并解散産品團隊。

其實這個消息我幾個月前就知道了，因為我的一位粉絲就是該團隊的核心成員。他在6月中旬給我發過一篇自己的總結，文中寫道：

三年同行，今日一别，後會無期。

這款SaaS産品的起點頗高，号稱融合了母公司30餘年成功管理經驗，是“CEO為CEO設計的經營系統”。由于母公司名氣很大，銷售渠道也頗為完善，産品一上線，就吸引了衆多潛在客戶前來問詢。

除了母公司的渠道支持，團隊建設也是高舉高打，員工按照大廠标準招聘。以我的這位粉絲為例，他就曾經在“四大”咨詢公司擔任Workday解決方案專家。

那麼，為什麼不缺資源、不缺客戶、不缺人才的SaaS産品，最終卻以解散團隊的方式黯然退場呢？

根據多方來源的信息，最直接的原因，還是産品标準化能力不足，由此導緻的定制化開發讓幾乎每個項目都無法盈利。

在商務談判階段，對于需要一定程度的定制化開發，甲乙雙方肯定都是心知肚明的。但定制化項目最可怕的地方在于：由于在售前階段主要依靠PPT進行交流，對定制開發的程度容易預估不足。結果最後一方面客戶抱怨産品太差，另一方面項目方也陷入苦苦掙紮。

實際上，做标準化SaaS産品，拼的并不是名氣，也不是資源，而是科學的産品方法論。不尊重産品标準化的規律，即便是市值萬億的大廠，也難逃失敗的結果。

01 标準化的窘境

我曾經在文章《SaaS行業2023年十大預測》中寫道：

在做大做強國有企業的大背景下，中國SaaS公司不得不主動适應傳統企業、國有企業或者政府的需求。

但是，一方面，SaaS規模化盈利的前提就是标準化；另一方面，傳統大企業又更喜歡本地化部署、個性化交付的傳統模式。這就使得在2023年，标準化和定制化的矛盾将愈加突出。

實際上，大部分SaaS公司的CEO都意識到了标準化的重要性。但是，在推行标準化的過程中，卻很容易陷入以下危險的陷阱：

1. 被項目拉扯的标準化

很多粉絲告訴我，公司本來想做标準化的産品，但是客戶總有個性化的需求，而如果不滿足這些需求，客戶就會拒絕購買。

最終，為了生存，公司隻能接受定制，同時為了控制成本，又拼命壓迫産品經理加班。結果就是：員工怨聲載道、公司賺不到錢，也構建不出有競争力的産品。而缺乏好的産品，公司又隻能繼續做定制項目，從而陷入惡性循環。

這和文章開頭的故事，如出一轍。

2. 變了味的标準化

有的SaaS公司由于具備大型軟件的經驗，一開始就很注重産品的标準化。他們會建立專門的産品部，甚至打造PaaS平台，用于滿足客戶的個性化需求。

但是，标準化的目标并非簡單的“降低軟件交付成本”，實際上，标準化還有以下兩個核心目标：

1）打造極緻産品

标準化最大的魅力在于“複用”。哪怕一個功能投入再多資源，隻要有足夠的客戶使用，成本就可以被無限攤薄。

“複用”定律可以支撐我們極緻化打造每一個功能，從而顯著提升産品的競争力。

2）沉澱最佳實踐

标準化的另一個核心目标是沉澱最佳實踐。

為什麼客戶願意購買SaaS，而不是選擇讓PaaS公司定制？其中一個重要的原因就在于，客戶在購買前可以試用已經成熟的産品，從而更加确定産品與需求的匹配度。

标準化的功能，也有利于SaaS公司将曆史經驗進行沉澱，從而在項目售前、交付和服務的過程中，減少對員工個人能力的依賴。

但是，在實踐中，SaaS公司往往更關注對當下問題的解決，而忽略标準化的長期價值。結果匆忙上線的所謂标準化功能“複用能力”不強，或者用戶體驗糟糕，不足以形成有競争力的産品。

02 标準化的解答

面對以上問題，SaaS公司正确的做法應該是怎樣的呢？

首先，我們必須意識到：标準化表面上是産品設計的問題，但本質上是公司戰略的問題。如果産品的定位不恰當，标準化就很難實現。

比如，在本文開頭的案例中，該大廠産品的定位就幾乎注定了它的失敗。

中國管理型HR軟件領域，其實是一個成熟、競争充分的市場。而該SaaS軟件商業化的第一批客戶就是追求精細化管理的大型企業。這樣的客戶，在B端軟件的應用上已經有非常成熟的經驗，而且往往有較為複雜的個性化需求。即便是世界領先的HR軟件，也不可避免一定程度的二次開發，何況是一款剛開始商業化不久的SaaS軟件呢？

同時，這款SaaS軟件非常強調自己的咨詢屬性，售賣的是一整套“從咨詢到落地”的解決方案，這也極大的提高了客戶的期望，以及項目交付的難度。

說白了，這是一次非常外行的失敗：高估了管理咨詢的效果，低估了軟件研發的難度。

除了正确的定位，我們還需要有實現标準化的智慧。

事實上，并非每一個領域都适合創業公司切入，我們要善于從市場中發現标準化的機會，并且用正确的策略去抓住它。

切記：産品策略決定了标準化的成敗。

1. 從大到小，還是從小到大？

曾經和一位投資人朋友讨論：SaaS公司到底應該先從小企業做起，還是先從大企業做起？

從小企業做起，我們容易掌控主動權，但是要實現規模化盈利，SaaS公司就必須攻克大企業市場。而小企業市場的經驗，往往不足以應對大企業的需求。

從大企業做起，更容易做大收入規模，但是大企業的個性化需求很多，會帶來很大的産品和服務壓力。

而我的建議是：在能力積累上，從大企業出發；在産品實現上，從小企業出發。

1）在能力積累上，從大企業出發

小企業的需求往往很簡單，管理也非常靈活、易于變通。如果一個産品經理隻有面向小企業的SaaS産品經驗，他的架構能力實際上非常薄弱，也很難承擔起服務大企業的重任。

實際上，不管是Salesforce還是Workday，他們的核心團隊都有豐富的大企業B端産品經驗。

比如，Salesforce的創始人和部分早期高管都來自于Oracle公司，而Workday的創始人曾經研發出了大名鼎鼎的Peoplesoft。

因此，一家有遠大理想的SaaS公司，一定會從大企業身上汲取寶貴經驗，用來提升産品的行業深度，以及産品團隊的架構能力。

從這個角度來說，即便是做定制化，拿下行業标杆企業的訂單，仍然有着非常深遠的意義。

2）在産品實現上，從小企業出發

每個人對小企業的定義不太一樣。我對小企業的定義是：規模較小，但能夠為SaaS産品持續付費的企業客戶。

比如，在快消品行業，經銷商的年銷售規模在2000萬以上，制造廠商的年銷售額在2億以上，這樣的企業除了具備一定的持續付費能力，數量也較多，适合打造标準化的SaaS産品。

如果在産品的MVP版本，我們直接根據大企業的需求研發——除非産品團隊的架構能力足夠強大、産品研發的資源足夠豐富——那麼産品團隊很容易疲于滿足客戶的各種細緻、個性化的需求，無力打磨标準化的産品。

反之，如果在産品的MVP版本，我們根據小企業的需求研發。那麼不但産品團隊的壓力較小，而且可以具有很強的主動性：我們可以按照自己的規劃，在雕琢用戶體驗、沉澱行業經驗的基礎上，做好每一個功能的标準化。

說白了，讓一個小孩直接去挑戰世界拳王是不妥當的。最佳的路徑應該是：用最好的方法去培訓小孩，但在實戰的時候，還是應該挑選一個合适的挑戰對象。

2. 聚焦：成敗的關鍵

在标準化産品的構建上，選擇從小企業入手，除了免受強勢客戶的幹擾，也能夠讓我們聚焦核心資源。

我曾經做過簡單估算：做好同一個功能，“标準化”所耗費的資源，是“定制化”的7倍。

這也是很多從傳統軟件轉型SaaS的創業公司，常犯的一個錯誤：他們一開始就低估了研發标準化産品所需的投入，結果構建了一個大而全，但是在可配置性、用戶體驗方面都比較粗糙的SaaS産品。

當然了，有朋友會說：隻有大而全的産品，客戶才會買單。

其實這是一個失敗的隐喻：客戶說，隻要你有了XX功能我就買單——這往往說明，我們一開始的定位，就沒有抓住企業的一個普遍痛點。

質量不夠，數量來湊——但是全面鋪開的結果，往往就是全面失控。

隻有聚焦于核心功能，我們才可能在資源有限的情況下，同時實現标準化的三個核心目的：

3. 架構：标準化的底層邏輯

很多CEO忽略了一點：不同的産品經理，會塑造出不同的SaaS産品。

一個隻有小企業服務經驗的産品經理，他的産品設計往往也比較短視，也很難與大企業管理層進行高效的溝通。

這就是我常說的：缺乏産品架構能力。

在産品設計上，從抽象到具體、從複雜到簡單總是相對容易的——如果你掌握了複雜、抽象的産品設計框架，再去設計一款簡單、針對小範圍客群的SaaS産品，那麼難度其實是很小的。你隻需要解決好用戶體驗問題就可以了。

但是如果你隻有簡單、針對小範圍客群的産品經驗，要去設計一款複雜、抽象的SaaS産品，那難度其實是相當大的。

雖然很多CEO的說辭是：根據多個項目的經驗進行歸納和抽象。但是這樣的效率其實非常低。而且我也很懷疑能否找到業務歸納和抽象能力如此強大的産品經理。

其實，最簡單的做法，就是去研究那些已經經過世界500強企業驗證過的B端産品。雖然他們不是SaaS模式，但是也面對和SaaS産品一樣的客戶、以及更加複雜的客戶需求。

我的一位Oracle課程學員告訴我，學習Oracle之後，他對Salesforce的理解加深了（他們公司實施了Salesforce）。這也許能夠說明，世界頂級B端軟件在一定程度上都遵循了類似的架構設計。

這就是我們常說的“最佳實踐”。

4. SaaS為主，PaaS為輔

最後，我要提醒大家，不要過于依賴PaaS，因為PaaS有其難以克服的局限性。

首先，它高度依賴于實施人員的素質；其次，高度的抽象往往是以犧牲用戶體驗為代價的，特别是一些高頻功能，用戶體驗其實非常重要。

再次，PaaS搭建應用的成本較低，但是并非沒有成本。反複搭建類似功能，也是嚴重的資源浪費。

最後，也是最重要的一點，過于依賴PaaS，會導緻SaaS産品停止進化。

企業購買SaaS産品，不僅僅是購買應用搭建的能力，更重要的是購買SaaS公司的行業經驗，以及固化在SaaS産品中的成功實踐。

PaaS能力雖然重要，但是切莫搞錯了主次關系。

專欄作家#

王戴明，To B老人家，人人都是産品經理專欄作家，多年互聯網産品與信息化管理經驗。

本文原創發布于人人都是産品經理，未經許可，禁止轉載。

題圖來自 Unsplash，基于 CC0 協議。

該文觀點僅代表作者本人，人人都是産品經理平台僅提供信息存儲空間服務。

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部