編輯導語：對於產品經理來説，客户需求是必須詳細地記錄與分析的，只有掌握了客户需求，才能瞭解存在的問題，從而根據客户的需求場景去製作出客户滿意的產品。那麼，應該如何對B端客户的需求記錄進行分析呢？本文作者三方面為我們做出瞭解答。
隨着中國互聯網行業從消費互聯向產業互聯轉型，企業服務市場進入快速增長期。
根據艾瑞諮詢的報告，雖然新冠疫情影響了宏觀經濟增速，但線下轉線上、遠程辦公等需求反而助推了SaaS發展，預計2020年企業級SaaS市場仍將保持可觀的增速，到2022年市場規模將突破千億元。
風口上，不只是資本紛紛湧入To B領域，許多產品人也在謀劃着從C端轉型到B端。
本文作者針對以SaaS產品為典型代表的B端客户需求分析，提出“一二三”的方法論，即一條公式、兩個維度、三種分析，希望能給有意從C端跨界到B端的產品人提供參考。
本文的主要內容用思維導圖呈現如下：
在進入本文的正題前，先通過回顧產品大牛的論述，對B端和C端產品做個簡要的區分。
產品人Frank在《三大方面，分析 to B和 to C產品的區別》中，從三個角度對這兩個產品做了區分：
- 面向對象：2B產品面向偏理性的客户，2C產品面向偏感性的用户；
- 產品特點：B端賣工具，強調性價比；C端賣玩具，突出好玩；
- 商業模式：B端“賣身”，實打實地一手交錢一手交貨；C端“賣藝”，主要通過廣告、排名等方式間接變現。
在《何謂B端產品》一文中，產品糙叔把B端產品定義為：為組織提供商業價值的產品或服務。
他提出，B端產品經理在日常工作中，要做到“一個明確，兩個基於”，即先明確目標客户，再基於價值決策、基於場景設計。
概括而言，C端用户更重體驗，要求用得爽、玩得嗨，因此，在做產品設計時要輕流程、重體驗。而B端客户更重效率，在做決策時更符合理性經濟人假設。
所以，在設計產品時，要帶着幫忙客户降本增效的目標，對企業業務流程進行重構、優化。
二、一條公式產品大神俞軍曾把他百度工作時總結的12條產品方法論，簡化為一個公式：用户價值=新體驗-舊體驗-替換成本。類似地，本文作者認為，在B端市場也適用這樣一個公式：
作者認為，這個公式是預判需求是否有商業價值和客户是否購買後續做出來的產品的根本標準。
為什麼這麼説呢？
來源：《艾瑞諮詢：2020年中國企業級SaaS行業研究報告》
在當前的國內環境中，一個SaaS產品只有在需求分析階段就瞄準客户痛點、在產品設計階段就幫客户把賬算清楚，才能為走通商業模式、實現產品盈利奠定基礎，國內的SaaS市場環境目前是落後於發達國家的。
艾瑞諮詢的數據顯示，2019年中國GDP佔全球的比例達到16.4%，但企業IT支出佔全球比重僅為5.5%，總體而言，中國企業信息化水平相對經濟發展程度仍比較落後。
具體而言，國內目前願意付費訂閲SaaS的客户多為國企與政府，且偏向定製化開發。而小微企業由於競爭環境相對惡劣、對於用人力來經營有路徑依賴等原因，所以對軟件工具的付費能力普遍不強。
這種情況下，B端產品經理只有在做頂層設計時，就幫目標客羣把SaaS產品價值的ROI測算清楚，才能保證做出來的產品既切中客户真實需求，又在目標客羣的付費能力之內，進而支撐銷售和客服團隊把SaaS產品賣出去。
然後，這條公式要怎樣使用呢？
參考用法是：先從市面上選擇合適的解決方案作為參照物，跟擬開發的新解決方案、客户正在使用的舊解決方案作比較，引入參照物是為了比較客觀地做出分數評估。
然後，按選定的統一標準從不同維度給這些方案打分。經標準化處理後，取綜合得分並進一步計算、比較不同方案之間的優劣。
關於新舊方案評估的維度，以及每個維度的權重，建議根據行業經驗和產品特性來確定，可以包括但不限於技術先進性、價格、功效、安全性、方案完備性等等。
計算不同解決方案的價值得分
計算不同解決方案的成本得分
舉例：假設我要做一套客服系統，我選擇了從技術、價格、服務和功效這4個維度來評估我們公司打算做的客服系統、市面上的參照方案和目標客户正在用的舊方案。
假設經計算得到，新解決方案的價值得分為70分，成本為65分，而舊解決方案的價值得分為30分，成本得分為45分。
那麼，根據客户價值公式，產品價值=(新解決方案-舊解決方案)-替換成本=(70-30)-(65-45)=20分。產品價值為正數，表明這個新解決方案可以給客户帶來價值，也就是説這個B端產品的價值模型有較高的可能性成立。
其中，在根據行業和產品特點選擇具體維度來比較不同方案的替換成本時，建議考慮“功能專注度”和“功能豐富度”，為什麼呢？
因為這兩個維度分別對應了把功能做強和把集成做廣的SaaS產品競爭策略。
具體如下：
1. 功能專注度：把功能做強相比於通用型SaaS產品，有些SaaS廠商會專注於某一垂直領域做專用產品切入，打磨好符合該領域需求的細節功能，從而構建起自己的競爭壁壘。
這樣當競爭對手嘗試以低價搶走客户時，客户可能會考慮到某些細節功能更符合自己在特定場景中的業務需求，而拒絕競爭對手的誘惑。
2. 功能豐富度：把集成做廣相比於專注做強功能，有的SaaS產品會面向B端客户多樣化的管理需求，把可以共生的多種軟硬件服務集成在一起，為客户提供一體化的解決方案。
這樣既通過一站式幫助客户解決全部相關問題，在銷售時贏得客户的青睞，又使得已經在用的客户在面對友商提供的替換方案時，考慮到要投入額外資源把幾套系統割接在一起，很可能會慎重考慮要不要更換。
把“功能專注度”和“功能豐富度”納入到替換成本的測算中，可以幫助我們構建起產品的競爭壁壘。
總而言之，B端產品經理要有一把秤來衡量做出來能否給目標客羣帶來正的商業價值，要提前幫目標客户把新解決方案的價值計算清楚。上面這條客户價值公式供參考。
三、兩個維度明確了產品價值的衡量方式後，接下來從商業和技術兩個維度，來摸清B端客户對於SaaS產品的需求。其中，商業維度的分析是技術分析的基礎。
商業分析如果錯了，那麼後續搭建出來的產品技術模型很可能是沒用的。
商業維度的分析可以從以下角度展開：
1. 目標客羣C端產品有用户研究，類似地，B端需求也可以建立目標客户模型，只是考慮的維度不一樣。
C端一般從年齡、職業、性別等維度來勾畫目標用户的個性特徵，而B端產品則會從行業、地域、企業規模等角度來明確目標客羣。
2. 需求背景B端產品一定是立足於某個具體的環境和（或）發展階段來為目標企業創造價值的，這個價值可大可小。企業對軟件工具的需求，一定是客觀環境或者發展問題映射到決策層的主觀意志上，再回饋出來的痛點。
產品經理一定要理解這個需求產生的背景，例如：同樣是對自助建站的需求，一個企業在50人左右的階段，可能只願意購買模板和基礎的數據庫服務來展示自己的業務，而當它擴張到500人的階段，就可能比較看重平台開發/製作能力了。
自助建站SaaS產品經理就需要明確自己面向哪個發展階段的企業客户。
3. 商業模式在理解需求背景後，B端產品經理要弄清楚目標企業的商業模式，商業模式決定了產品規劃和設計的框架。
只有梳理清楚了企業的商業模式，準確把握目標客户經營什麼產品或者服務、怎樣銷售、怎樣盈利，才能避免B端產品的系統設計出現嚴重的偏差。
對商業模式的理解，可以結合下文介紹的場景分析來展開。
4. 付費能力B端產品只是通過用技術輔助企業降低成本或者增加收入，來改變B端客户的支付對象，但並不能增強客户的付費能力。產品經理需要確保自己在用產品來幫助客户時，所採用的技術和成本沒有超出目標客户的購買能力範圍。
同理地，產品在完成商業角度的分析後，可以從開發目標、系統架構、功能模塊和參數要求等維度來分析目標客羣對於SaaS產品的技術要求。
四、三種分析具體到怎樣從商業和技術兩個維度做好、做充分對B端客户的需求分析，我認為有三種手段可以輔助實現，分別是：相關方分析、場景分析和業務邏輯分析。
首先，我們需要確定這個需求涉及到的相關方有哪些。與C端需求主體只有用户一個人不同，B端需求會涉及到更多主體。
一般來説，B端需求中，決策者（老闆）、購買者（採購部、財務部）和使用者（業務人員）是分離的。
相關方是產品需求的來源。一定是在某個特定的場景中，幾個相關方在他們的現狀和想達到的目標之間有差距，這些差距集合在一起才形成了一個痛點，進而形成了B端客户對一個新的解決方案的需求。作者認為，全面的相關方分析是首要的。
例如：假設收銀員人均處理500單流水，而要達成人均1000單才能應對業務擴張，這種差距反饋到老闆那裏，他可能就會有控制成本、提高效率的想法，然後授意採購部去詢價能輔助實現這個目標的收銀解決方案。
產品經理一定要把一個業務場景中涉及到的相關方都捕捉到了，然後分析他們在特定場景中的互動，才能確保在做需求分析時沒有遺漏。
這裏特別提出，在做相關方分析時，建議把合作伙伴也考慮進來，然後整體分析他們在特定的行業生態中，是怎樣圍繞特定主題合作實現價值創造、流動的，為什麼這麼説呢？
前文提到，目前國內企業的信息化程度還相對落後，中小企業的SaaS付費意願沒有美國的強。這種情況下，SaaS產品如果想盈利，就不能只是做一個軟件，而是要以降本/增收為目標導向，為B端客户提供一體化的解決方案。
再次拿收銀系統來舉例：如果某SaaS產品只是給到客户一個IT系統，那麼，企業是不會買單的。
因為企業在買了這個系統後，還需要去採購電腦、連接網絡、部署軟件等，在售後問題上需要額外投入很多資源。客户會覺得不划算；而現實中，國內大部分廠商現在都是提供一整套的移動支付解決方案，包括收銀機、掃碼槍和收銀系統等在內。
也就是説，B端產品在做相關方分析和場景分析時，需要充分捕捉到涉及到的角色，然後思考信息流、資金流和（或）物流是怎樣在這幾個主體之間流動的，他們是怎樣形成一個小型生態的，然後才能針對性地為這個場景設計出一體化的解決方案。
另外，在做場景分析時，還需要考慮物理場景。雖然都屬於線上場景，企業對於網頁端自助建站和小程序自助建站的需求是不一樣的。
網頁端建站時，對於功能模塊的要求會更齊全；而在小程序建站時，由於它倡導用完就走、不適合做留存，所以對於功能模塊的需求就會聚焦在商品上架和訂單交易。
同樣地，雖然都是做線下支付，商鋪掃碼支付和公交掃碼支付對於產品的功能要求是不一樣的。
因為跟便利店裏信號穩定不一樣，公交是一個網絡波動的場景，可能這個車站信號滿格，下個站點卻沒有信號了。不同物理場景中，對於產品的功能參數要求是不一樣的。
在做完相關方分析和場景分析，對目標客户的商業需求有個完整的理解後，才開始着手業務邏輯分析。而不是一上來，就開始畫流程圖。在做業務邏輯分析時，可以調用一些比較成熟的工具模型。
如下：
- 範圍模型：生態系統圖、系統交互圖、功能模型等；
- 流程模型：過程流、用例、用例故事等；
- 規則模型：商業規則目錄、決策樹、決策表等；
- 數據模型：數據流圖、數據字典、狀態表、狀態圖和實體關係圖等；
- 接口模型：報告表、系統接口表、用户界面流、線框圖和顯示-操作響應表等。
這方面其他專業人士已有比較詳細的論述，這裏就不展開了。
五、總結概括來説，本文提供了“一二三”的B端需求分析方法論作為參考：B端產品經理要有一杆秤（客户價值公式），作為預判產品能否給目標客户增加商業價值的根本標準。
在做需求分析和產品設計時，可以從商業和技術兩個維度，通過相關方分析、場景分析和業務邏輯分析，去梳理清楚目標客羣的具體需求以及他們的真實需求程度，為做出一個成功的B端產品奠定基礎。
本文由 @小明筒鞋 原創發佈於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議