深入B端SaaS產品設計核心理念

2021年準備更換一個工作平台，要做一下階段性知識總結，於是便有此文。

照例，先説下視角基礎，筆者近7年一直在做B端大客户定製，方向側重企業信息化和協同，涉及產品數量眾多，單一產品持續深化時長有限；長時間處於傳統軟件定製領域，缺乏SaaS操盤經驗，這是本文的侷限性所在。

本文討論“為什麼採用SaaS模式”、“SaaS產品有哪些”以及“如何做好SaaS產品設計”三個話題，核心是產品設計，主要從需求定義、方案設計和開發交付3方面，共計討論10個問題點。

一、Why

為什麼要用SaaS模式，這個話題我們從面向B端的傳統軟件廠商的痛點來聊。

傳統軟件廠商通常的交付模式是，銷售和售前根據線索參與招投標，中標後項目實施團隊入駐客户現場；根據客户的實際需求開發或改造功能，完成軟件部署交付並經客户業務驗收後，核心團隊離場由維護人員接手更新。

這種模式的侷限性總結來説是“賺錢慢”，具體説來如下：

1）成本高

主要包括三方面：銷售成本、部署人力成本和維護人力成本；有多少項目，就必須配備多少人力。

2）速度慢

主要包括兩方面：交付慢和回款慢；項目週期動輒半年，甚至一年、兩年。

3）可複製性低

主要包括兩方面：人力依賴和定製化；項目的成交依賴售前的行業見解和對客户KP動機的洞察能力；項目的成功依賴於需求分析師對客户真實需求的挖掘和方案設計能力，以及項目經理對人、事的控制能力。

對特定能力人的需求，限制了傳統軟件廠商的擴張能力，同時，頻繁出差也造成這個領域的優秀人才流失嚴重；產品化是降低成本、提高複製性的關鍵，然而，大客户另外30%的個性定製化需求，是無法跨越的鴻溝。

從客户角度，傳統軟件交付模式也存在着侷限性，主要包括：價格貴、交付慢、升級難、失敗風險高等。

如何破解傳統軟件交付模式的難題？

按筆者的思路（只是其中一種角度），科學管理之父泰勒的“標準化”是一條可選路徑，其表現形式即本文討論的主題“SaaS模式”。

B端SaaS的核心是放棄一部分個性化需求，通過對通用功能標準化來滿足企業70%的主要需求；其基本假設是企業即使沒有B端產品也照樣能運行，B端產品的價值在於比原有模式成本低、效率快、質量高，產品只要對原有模式有改善即可。

中小企業對價格敏感，相對容易接受不完美，這樣SaaS模式便講通了；所以，B端SaaS的核心是標準化，標準化之後，成本、速度、可複製性的問題都迎刃而解！理解這點，對B端SaaS產品設計至關重要。

（P.S.但SaaS真的是萬靈藥嗎？這個話題不在本文討論範圍內，留待以後文章。）

二、What

SaaS是一種軟件交付模式，軟件不需要安裝，直接通過網絡在線使用；SaaS雖有ToB與ToC之分，但當下討論SaaS多指B端；本文不討論SaaS本身的形態和特徵，更多從SaaS產品的分類和未來角度來理解。

在SaaS產品分類上，筆者更認同明道創始人任向暉老師的觀點，SaaS產品主要分為3類，行業SaaS、職能SaaS和通用SaaS。

• 行業SaaS着眼於解決特定行業“一條線”的問題，甚至參與到行業交易處理環節，行業Top客户的標杆效應對產品競爭力至關重要，典型如二維火（餐飲）、別樣紅（酒店）；
• 職能SaaS面向企業特定職業人羣解決業務“塊”的問題，需要具備深厚的職業知識，產品競爭力源於對細分市場的選擇、對領域知識的理解和服務耐心，典型如SalesForce（CRM）、金蝶（ERP）、北森（HRM）；
• 通用SaaS不分行業和職能，市場空間巨大但同質化競爭也激烈，產品競爭力源於對特定類型企業的匹配度，典型如Slack、Jira、釘釘（辦公協同），Confluence、有道（知識管理）等。

在SaaS產品未來上，筆者更認同紛享銷客前執行總裁吳昊老師的觀點，SaaS產品的未來發展主要有2個方向，做PaaS平台和轉型商業SaaS。

PaaS平台如釘釘和企業微信，在滿足企業核心需求的同時，通過引進ISV（獨立軟件商）滿足企業個性化定製需求，實現方式包括無代碼、低代碼和全代碼；走PaaS路線核心考慮的3個問題是，用户範圍是否擴大、客單價是否提高、與純定製是否競爭力更強；商業SaaS利用自身數據重度參與企業商業過程，如美團參與商家供應鏈等。

筆者認為，雖然要了解SaaS產品的未來規劃，但更重要的是在當下活下來，打造自己的拳頭產品，找到PMF更重要。

三、How

如何做好B端SaaS產品設計？

首先談談筆者對B端與C端產品區別的理解，核心區別在於C端針對Customer，面向個體；B端針對Business，面向羣體。

由此繼續探索：C端側重生活、講究感性體驗、重視人性與趣味，B端側重工作、講究理性利益平衡、重視邏輯與效率；C端解決個體生活的單點需求，B端解決羣體多角色協同的鏈條需求；C端產品交互設計重視個體操作效率，B端除了個體操作效率，更重視整體業務流程效率；C端產品經理重視把自己變成用户，B端產品經理以為自己能變成用户就完蛋了！

對於B端SaaS產品設計，筆者主要從需求定義、方案設計和開發交付3方面，共計討論10個問題點；以下任意一個問題點，都可以拿出來細化為一篇文章，但限於篇幅，本篇只談核心點不做過多細化（若後面有時間，筆者會花時間總結細化）。

1. 需求定義

1）客户&角色畫像

定位的客户不同，我們產品設計業務流程和功能的完備度、複雜度、側重點等均不同；客户畫像不止是在產品初期有用，它應該貫穿整個產品設計過程，任何一個新業務、新功能，都需要回顧客户畫像、角色畫像。

筆者常提的一個比喻是，“一個小農想噴農藥，不應該給他一架噴霧飛機，更應該給他一台手動噴霧器”，重要的不是我們的產品牛X程度，而應該是方案剛好匹配客户的需求。

客户畫像的維度很多，比如行業、核心痛點、員工規模、員工構成（平均年齡、在崗時長、技能水平、新老比例等）等，其中員工規模是個比較常用的維度，如定義小微企業（50人）、中小企業（500人）、大企業（1000人）。

員工規模這個維度之所以有用，是因為小微企業和大企業的需求點差異性較大，以“協同”為例，小微企業和中小企業最核心的需求是以“最小阻力”實現“線上化”，但大企業則會要求功能完備、多系統貫通、數智化、合規等。

需要注意，員工規模並非完全可定義客户需求，它只是一個參考因素，筆者接觸了很多1000人以上大企業，甚至互聯網新興獨角獸，其協同“線上化”程度之低難以想象！某些大廠主推的協同產品，可能需要考慮下自己是否陷入“知識詛咒”，你對產品的定位是中小企業，但你看下自己產品是適用中小企業，還是你自身所在的大廠！

角色畫像對B端產品設計非常重要，但C端的用户畫像並不適用B端，B端角色畫像在個體層面更看中技能水平、崗位穩定性等，在角色層面看重該角色存在價值、上下游角色、信息的接收處理和輸出等。

2）需求收集

B端產品需求收集與C端差異性很大，筆者總結的需求收集4原則是：真實、全面、驗證、善意，技巧是：被動收集、深入一線、場景還原。

• “被動收集”並非純粹的被動等待需求反饋，而是構建好需求反饋的渠道，與種子客户、意見領袖打好關係，讓用户更多、更快的反饋真實痛點，在B端問卷、主動訪談等手段收效不佳；
• “深入一線”是指我們在需求收集時，容易因轉述造成理解偏差，此時找到需求的最原始提出人非常重要，另外，我們也需要面對面的觀察需求“痛”的全過程，以真實、全面的理解需求；
• “場景還原”是通過理解需求產生的場景來理解需求，B端我們經常會接到“功能需求”；此時，通過5Why、究竟精神“擠牙膏式”探索“功能需求”背後的實際需求非常重要，5W1H是場景還原時常用工具。

3）產品規劃

產品規劃分遠期和近期，遠期規劃更多為了產品架構，主要手段是分組和分層；近期規劃更多是需求優先級排序，核心是衡量需求ROI，這個職責並不一定是產品經理承擔，應該讓最懂ROI的人決定需求排序。

通常來講，B端優先級考量方法包括：權力影響分析、用户量頻分析、拒絕影響分析等；權力影響分析是根據需求關注人的權力和對產品影響力的大小來決定需求優先級，有人調侃ToB的全稱是“ToBoss”，這不無道理；用户量頻分析是根據需求涉及的用户量及發生頻率來決定需求優先級，B端不存在偽需求，只存在性價比不高的需求；拒絕影響分析是對KANO模型的解讀，核心考量的點是，如果我們不做這個需求會產生多大影響，如果影響很小，則優先級就低。

2. 方案設計

1）MVP

MVP本應在開發交付時談，但筆者理解MVP的核心是“驗證”，基於這個理解，在需求收集時就已經開始有MVP了，而方案設計過程更是一個MVP驗證的過程。

作為產品經理，之所以要做方案設計的原因是：思考、驗證與傳達。

思考是通過設計，讓業務過程與軟件設計相互契合，業務方缺乏對軟件的基本理解，而開發團隊出於自身立場容易曲解業務，產品經理則是要站在雙方共同的立場上思考。

驗證是通過不斷與業務方確認設計交付物探索真實需求，以儘量減少開發中、交付後的變更；設計交付物應追求最小成本收集反饋，在能確認需求的最大ROI手段上停止，成本由低到高依次是：口頭核心業務確認、Xmind核心功能確認、Visio核心業務流程確認、紙面線框圖、低保真原型、高保真原型、需求説明書。

傳達是為了確保開發團隊能夠理解需求，交付出能解決業務問題的功能，設計交付物是一種手段，更重要的是頻繁面對面溝通。

2）產品設計原則

對於B端產品設計，筆者總結的4原則是有用、靈活、簡單、美。其中最核心的是有用，即能從整體上能解決業務問題。

但在跟BAT大廠的產品經理交流中衝突較大，筆者聊業務背景、痛點、角色特徵、核心功能，對方認為太虛；對方聊特定功能點的交互設計技巧，筆者基於“好懂”、“少動”的交互設計原則直接找競品抄（借鑑）。

這種衝突可能源於BAT大廠產品經理多、專業化分工細，實際工作更需要專注把自己負責的模塊和功能點做精；筆者不確定誰對誰錯，但這種做法並不適用筆者服務的領域。在此不細談B端產品平面設計、交互設計、簡化設計技巧，留待以後文章討論吧，此處着重強調B端產品設計的第一原則是有用。

3）差異化優勢

有人取笑產品經理的核心能力是“抄襲”，沒頭腦的1:1模仿一個競品確實是抄襲；但如果對比多個競品，甚至從非競品的產品中尋找靈感。

同時，結合自身業務痛點深入思考取捨，作為讀書人，我們姑且稱這種行為是“借鑑”吧；天下產品一大抄，我們該如何確定自身產品的差異化優勢？

首先，要明確自己公司的優勢所在；其次，差異化有3個小技巧：簡單、細分、理念。

拿筆者所在的協同工具領域舉例，工具型產品最大的問題應該是先解決用户使用意願問題，而解決用户使用意願除了對多角色利益的考量，儘量把功能做簡單也同樣重要；因為越簡單的功能，越容易在最短時間讓用户感知到改變帶來的價值。

細分是進入一個特定的細分行業、特定的細分企業類型，因為細分領域有很多特定的業務邏輯，懂這些更容易與客户產生親近感。

理念是基於我們對行業新趨勢的理解，漸進式引領客户做新嘗試，客户容易深陷在舊有的知識體系內；我們由於變不成客户，恰恰更容易接受新理念，比如我們在推廣協同工具“電子看板”時，可以解釋自己的理念是由傳統的自上而下時間資源管理式甘特圖，升級為當下更適用的扁平化網狀溝通協同的看板；再結合精益思想、敏捷交付精神等為客户洗腦，讓客户對我們的定位從“純粹的效率協同工具”轉變為“引領企業變革的新力量”。

4）功能廣與精

有些人傾向於把產品功能做全做廣，拿“端到端全鏈路”當產品競爭力，對於這種想法筆者不太認同；B端產品更適合“搶灘登錄戰略”，通過核心功能建立灘頭陣地，再以此為基礎擴大範圍。

主要原因有3點：增加用户認知負擔、延緩用户體驗滿足感、造成用户對產品定位混亂。

另外，在資源有限的情況下，做精比做廣更容易提升產品競爭力；相比而言，大客户才需要整體解決方案，中小客户更需要有問題時解決問題；即便大廠，也建議在產品組合中集中資源打造拳頭產品，其他相關產品拆分成子產品，各自定位自身亮點，又可相互對接。

3. 開發交付

1）MVP

B端產品做MVP是件很難的事，功能不上，用户不買賬；功能要上，資源精力不夠。

缺乏業務閉環的功能對客户無意義，常規功能組合又很難吸引用户。如果想着先上個功能應付，需要警醒，“B端產品上功能容易，下功能難”。

如何做B端產品MVP？這個問題筆者暫時無解，但提供3種思路：

• 把大業務拆小，基於特定小業務做最小功能組合；
• 產品缺失功能，允許用户通過線下操作彌補；
• 跟可以忍受產品不完美的種子客户建立關係。

2）標準化與靈活

SaaS模式的核心是標準化，但如果你真拿一個絕對標準化的產品，客户可能並不容易買單。

SaaS產品需要靈活，主要有2方面原因，一是不同客户需求有差異性，不靈活無法適應客户的業務；二是同一客户的業務也可能變化，不靈活無法適應客户業務變化；但產品又不能過於靈活，因為靈活度高一方面意味着開發成本高，另一方面意味着功能對所有客户適用性、易用性都差。

如何平衡B端SaaS產品的標準化和靈活？這個問題很難，筆者同樣暫時無解，但提供2種思路：

• 小客户設置、中客户配置、大客户定製；
• 針對不同規模客户，通過權限控制組合不同版本產品。

3）大客户定製之路

SaaS做小微企業賺錢很難，於是想探索做大客户，但大客户真的好做嗎？

回答這個問題首先要想清3個問題：

• 跟傳統軟件廠商比，你做大客户定製的優勢是什麼？
• 大客户定製會出現很多個性化需求，這些需求和產品主版本有衝突時你如何取捨？
• 做大客户定製要建設項目團隊，第一年大概率會賠錢，你願意賠錢做嗎？

大客户最在乎的不是價格便宜、技術牛X，而是服務好、風險低：

• 服務好主要體現在需求響應要及時、個性化需求能滿足、人員隨叫隨到的安全感；
• 風險低主要體現在公司有大客户成功案例、公司無存續風險、與公司項目接口人熟悉且已建立信任、數據安全有保障、公司資質合規等。

做大客户並不容易，但大客户卻能為SaaS公司樹立標杆，引領對業務領域的理解深度。

如果決定做大客户，如何解決大客户的定製化需求是另一個難題。

常見的3類解決方案是：無代碼、低代碼和全代碼。

① 無代碼方案提前考慮定製的各種場景，通過產品強大的配置化能力來滿足定製化需求，對於這種方案筆者並不認同；通過配置滿足中小企業需求勉強可行，但大客户的多樣個性化需求 + 強勢地位，想通過配置實現，要麼產品配置能力極強（開發ROI並不高），要麼關係硬到大客户只能忍。

② 低代碼方案可以通過配置滿足大部分需求，對於個性化需求，支持開發人員採用符合平台要求的程序腳本滿足定製化需求，對於這種方案筆者認同度也不高；因為代價碼是個偽命題，如果開發人員能力不行，即使低代碼也很難滿足定製化需求；如果開發人員能力強，這種受制約的開發方式很難被接受；同時，低代碼的權限控制、數據安全等都存在較大挑戰。

③ 全代碼方案同樣先通過配置滿足大部分需求，對於個性化需求，支持開發人員編寫程序，這種方案是目前筆者較認同的；就筆者目前的認知，有3種實現方式：代碼分支模式、代碼插件模式、微服務模式。

• 代碼分支模式通過對個性化需求代碼分支管理，用主分支與不同的個性化分支打包來滿足不同大客户的定製需求，這種模式偏傳統，當大客户數量多時難以為繼。
• 代碼插件模式通過在主產品指定的插件文件中寫程序，使用類似Filter+Hook的主函數滿足不同大客户的定製需求。
• 微服務模式將個性化需求集合到微服務上實現，內部通過API與主產品互通，這種模式相對比較推薦，因為它同時還能幫客户解決“雲端孤島”的問題，便於與客户當前其他系統低成本集成。

作者：李曉傑；微信ID：ecdoer；微信公眾號：產品曉思（ID：pmxiaosi）。10年以上產品、項目管理實戰經驗，近7年服務大B端客户運營商（移動、聯通），核心產品為企業信息化與協同，包括研發管理、財務管理、辦公自動化OA、數據可視化等。喜歡讀書、分享，希望與同路人共同探索產品經理成長之路。

本文由 @李曉傑 原創發佈於人人都是產品經理，未經作者許可，禁止轉載。

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