編輯導語：随着如今傳統企業數字化的轉型逐漸加速，轉型SaaS也在不斷進行中，本篇文章作者分享了轉型SaaS的幾個關鍵要點以及具體的方法思路等，一起來學習一下，希望對你有幫助。

一、中國B端産品的曆史

中國B端産品的曆史可以追溯到20世紀80年代。1981年，沈陽第一機床廠引進了中國第一套企業應用MRP軟件，這是中國最早使用大型B端軟件的案例之一。

1995年，SAP中國分公司成立，并在1998年成功簽下聯想集團的ERP合同。

而另一巨頭Oracle也不遑多讓，在1996拿下了華為的ERP訂單。中國當時最頂尖的企業開始應用ERP商業套件，标志着中國B端軟件行業開始進入黃金期。

不過，在傳統軟件時代，B端産品經理并不屬于熱門崗位。首先是因為，傳統B端産品更多用于内部管理，企業對産品體驗要求不高，産品創造的價值也相對有限。

其次，傳統B端産品的疊代相對緩慢，更依賴二次開發來滿足新的需求。因此，相對于産品經理，配置系統和設計個性化功能的實施顧問是一個更熱門的崗位。

實施顧問又分為内部顧問和外部顧問。所謂内部顧問，即企業内部負責軟件推廣的員工。他們熟悉ERP功能，又了解企業内部情況，可以對标今天的内部B端産品經理。

而外部顧問，即咨詢公司負責軟件實施的員工，他們精通ERP軟件功能，也熟悉一個甚至多個行業的管理流程，可以對标今天的SaaS産品經理。

由于傳統軟件時代有大量新項目，而外部顧問薪資相對高很多，因此内部顧問跳槽成為外部顧問的情況非常普遍。

不過，随着互聯網時代的到來，傳統軟件已經無法滿足互聯網業務的要求，互聯網公司開始自研中台甚至後台系統，内部B端産品經理開始崛起。

2010年以後，随着Salesforce的大獲成功，特别是傳統企業數字化轉型的加速，中國SaaS時代終于到來，SaaS産品經理也随之成為熱門崗位。

Boss直聘-SaaS産品經理職位數

和傳統軟件依賴二次開發不同，為了實現低成本規模化，SaaS非常強調産品本身的能力。而為了兼顧産品功能、用戶體驗和标準化，SaaS産品往往需要深耕一個或少數幾個垂直領域，這就導緻在較長時間内，市場上會出現越來越多的SaaS産品，也就需要越來越多的SaaS産品經理。

其實，從實施顧問到SaaS産品經理的變遷史，也是互聯網對企業的改造史。未來沒有傳統企業，隻有數字化企業，B端産品經理的前景還很廣闊。

二、從内部産品到SaaS産品

1. 内部産品與SaaS産品的差異

即便是在同一垂直領域，内部産品與SaaS産品的差異也非常明顯。

内部産品隻服務于一家企業，強調貼身定制以及快速響應需求，因此不需要考慮太多配置能力，相對更強調疊代速度。

SaaS産品則服務于多家企業。因此，對不同企業的包容性需要很強。為了實現這種包容性，每一次疊代都需要考慮多個客戶的需求，因此更強調配置能力，對疊代速度的要求相對較低。

比如，在設計CRM系統的“銷售訂單-商品價格”字段的功能時，如果你設計的是内部産品，可能你隻需要規定“商品價格默認為價目表價格，且不可修改”即可。

但如果你設計的是SaaS産品，則可能需要考慮不同企業有不同的價格管理策略：有些企業會允許銷售人員自由定價，而有些企業則希望默認該客戶上一次銷售價格，并給予銷售人員一定範圍的價格調整權限。

2. 内部産品轉SaaS産品

由于我既管理過内部産品部門，也負責過SaaS産品，我深刻的明白，内部産品和SaaS産品的管理，是完全不同的邏輯。

内部産品部門是成本中心，并不直接為企業的經營結果負責，考核指标更多是需求滿足度和團隊規模等。

SaaS公司則是利潤中心，需要為自身的經營結果負責，考核指标是銷售收入和客戶規模等。

内部産品由于基于内部需求開發産品，風險小但天花闆低，相對更關注中短期ROI；SaaS産品則因為面向高度不确定的市場，風險大但天花闆高，需要更關注中長期發展，甚至可以接受中短期虧損。如果管理内部産品需要的是管理者，管理SaaS産品則必須是創業者。

對于打算将内部産品轉化為SaaS産品的企業，我有以下幾點建議：

1）從0開始

一些公司出于控制開發成本的考慮，會将内部系統作為SaaS産品向客戶銷售。如果出于試錯目的，這樣做無可厚非。但如果已經正式踏上商業化這條路，我建議抛棄原有系統，從0開始重新開發SaaS産品。

原因在于，為了提高需求響應速度和降低開發成本，内部産品在架構設計方面考慮較少，對不同業務包容性較差。一旦這樣的産品面向市場，原有的功能勢必成為後續疊代的絆腳石，除了延緩産品疊代的速度，還會增加産品疊代的成本。

“從0開始”更深層次的含義，是抛棄“根據産品找市場”的思路，重新審視目标市場和競争對手，從客戶的痛點出發，尋找産品與市場的契合點。

隻有這樣，内部産品的商業化之路才有更大勝算。

2）獨立運作

内部産品商業化其實就是創業。

創業具有巨大不确定性，甚至要經過多次方向調整才能成功。在這種情況下，指望在母公司的官僚體制下，通過頻繁給高層彙報的方式來推動項目正常發展，基本是不可能的。

實際上，因為SaaS業務和母公司主營業務往往差異較大，母公司如果管得太細，隻會增加創業失敗的概率。因此，創業團隊獨立運作，避免母公司不必要的幹擾，其實非常重要。

除了團隊獨立，激活團隊主觀能動性也很關鍵。這方面我比較認可一位互聯網大佬的做法，他将内部創業團隊視為一家創業公司，集團注入一部分資金作為支持，但内部創業團隊會占有相當大一部分股權。在經營過程中，集團隻保留一票否決權，不過問具體經營細節。

3）把母公司變成助力

母公司是内部創業團隊的巨大優勢。

首先，母公司起到了種子客戶的作用。有母公司的案例作背書，可以大大提升客戶的信任度，幫助創業團隊順利啟動市場。

其次，母公司是創業團隊智慧的源泉。SaaS本質上是為業務服務的，雖然母公司業務和客戶業務可能存在差異，但是其背後邏輯是一緻的。

吃透母公司的業務，将極大提升SaaS團隊的洞察力。很多時候，一個産品能不能夠征服客戶，靠的就是對行業和業務的理解。

三、從内部産品經理到SaaS産品經理

1. 兩種産品經理的差異

由于面向不同客戶群體，内部産品經理和SaaS産品經理的核心能力模型，差異還是比較大的。

首先，由于需要用一套标準化産品滿足不同客戶的需求，SaaS産品經理需要具備更強的産品架構能力。否則，即便最終産品能夠勉強使用，所浪費的資源也是驚人的。

因為同樣一個功能，SaaS的研發時間可能是内部産品的好幾倍。

• 這一方面是由于SaaS産品的配置性很強，導緻了更長的開發和測試周期；
• 另一方面也是由于SaaS産品需要考慮多種類型客戶的需求，甚至預判未來可能出現的需求，以盡量避免功能被“推翻重來”。否則就會浪費寶貴的研發資源，延緩産品價值的提升。而在這方面，内部産品的風險則相對小很多。

其次，SaaS産品經理還需要具備更強的交互設計能力。B端産品很重視可用性和操作效率。

曾經一家客戶棄用耗費數百萬元的國際知名CRM系統，轉而采購我們的SaaS系統，原因就在于該CRM系統的可用性和操作效率太差：這意味着要讓一線員工學會和接受系統的成本太高了。

另外，SaaS産品往往需要同時面對多個細分行業的客戶，這也加大了交互設計的難度。比如，對于面向便利店銷售低溫奶的經銷商，他們希望在移動端訂單直接選擇X箱X瓶，從而提高銷售人員操作效率：為了在不缺貨的前提下盡可能降低庫存，便利店可能會多購買幾瓶。

而對于銷售礦泉水的經銷商，他們希望一個SKU隻有一個單位：畢竟便利店都是成箱購買。在這種情況下，除非我們放棄某一類客戶，否則産品經理可能就需要在交互設計上煞費一番苦心。

但是，SaaS産品經理在與用戶協調方面——和内部産品經理相比——就輕松了許多。

曾經一位SaaS公司創始人說：“在産品設計方面，是以我們為主：客戶要求的不一定做，我們認為應該做的才做”。

他的觀點其實具有一定代表性：SaaS産品為了追求标準化，普遍做法都是讓産品經理“挑選需求”來實現。但是，内部産品經理則往往沒有挑選需求的權力，甚至經常因為臨時插入的緊急需求，被迫調整上線計劃。在産品上線後，内部産品經理往往也需要負責培訓用戶，并且跟蹤使用的反饋。SaaS産品經理也會做類似工作，但是客戶成功部門會負責與一線用戶對接，這就大大減輕了他們的壓力和責任。

2. 轉型SaaS産品經理

内部産品經理轉型SaaS，其實具有很大的優勢。

首先，SaaS産品經理最核心的能力，還是對業務的深刻理解。在這方面——如果是一位優秀的内部産品經理——他對業務的洞察比“一畢業就做SaaS”的産品經理要深刻得多。畢竟，深入度而不是廣度，才是提升洞察力的關鍵。

其次，在研發流程上，内部産品和SaaS産品是類似的。因此，内部産品經理可以快速融入到SaaS産品研發流程中來。

最後，内部産品經理往往也具備良好的互聯網思維。這一點上，傳統軟件出身的實施顧問就會遇到更大的挑戰。

真正會給内部産品經理帶來挑戰的，還是“如何應對衆多企業差異化的需求”。

破解這一難題的關鍵，是培養産品架構能力。而培養産品架構能力的最佳途徑，則是研究經典系統。關于這方面更多的建議，你可以參考文章《我的實踐：如何提升B端産品架構能力》。

四、像CEO一樣思考

從内部産品到SaaS，不管是團隊負責人還是産品經理，都需要像CEO一樣思考：

• 我們的客戶是誰？
• 他們最大的痛點是什麼？
• 我們的解決方案是什麼？
• 為什麼是我們來解決？
• 客戶願意持續付費嗎？

大道至簡，好的商業模式都很簡單。隻有首先從客戶視角出發，找到産品與市場的契合點，轉型SaaS才有可能成功。

#專欄作家#

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

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

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

,

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

查看全部