編輯導語：對於產品經理來說，客戶需求是必須詳細地記錄與分析的，只有掌握了客戶需求，才能瞭解存在的問題，從而根據客戶的需求場景去製作出客戶滿意的產品。那麼，應該如何對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協議