如何做好B端產品需求收集

產品曉說

+ 關注

2022-11-08 13:20

961次閱讀

一個優秀的B端產品，必然契合了客戶的場景需求，為客戶創造了價值。而想保持產品持續優秀，則必然需要持續不斷的有高價值需求輸入。所謂“問渠哪得清如許，為有源頭活水來”，所謂“Garbage in，Garbage out”。

高價值需求是從需求池中對比篩選出來的，做好需求池則必然需要做好需求收集。所以，有了這個話題，“如何做好B端產品需求收集”。

商業化、自研、純定制等不同類型B端產品需求收集渠道不太相同，本文主要基于商業化B端產品展開。全文分5大部分：

WHY，為什么要做好需求收集？WHO，應該由誰來收集需求？WHERE，從哪些渠道收集需求？WHAT，需求收集什么信息？HOW，用什么工具收集需求？

WHY•為什么要做好需求收集？

首先，需求收集是產品打造的第一步，是產品價值的源頭和根基， 想做出對客戶有價值、商業上成功的B端產品必須重視。

其次，客戶在產品使用過程中，難免會提一些需求。是否有人能及時響應，響應是否夠專業，對客戶服務感知非常重要，影響到 項目滾動續簽 。

再次，一旦研發規模過百，很多公司會投入數百上千萬來做研發效能改進。但是，如果我們方向不對，工程效率、協作效率再高， 對客戶有什么價值，對市場有什么幫助？想追求研發效能改進的整體ROI，就需要從源頭一起抓。

研發效能提升的方法論很多，敏捷、精益、看板、TOC、DevOps、平臺工程等，這些方法論確實可以讓研發更快的開發、更快的響應、更快的發布。但對于B端產品，如果讓客戶頻繁升級，升級的功能客戶無感知或增加了認知復雜度，那可能還不如瀑布慢跑。

百科上對價值的定義是“價值是指客體能夠滿足主體需要的效益關系，是表示客體的屬性和功能與主體需要間的一種效用、效益或效應關系的哲學范疇”。所以，產品價值即客戶需要，想增加產品價值就要更好、更多的滿足客戶需要，滿足客戶需要就要盡可能多的收集到客戶需要。

WHO•應該由誰來收集需求？

收集需求要走近客戶，要接觸大量客戶，有大量的時間跟客戶在一起，能跟客戶建立起一定的信任關系。

可以接觸到客戶需求的角色有很多，比如銷售、售前工程師、解決方案工程師、行業拓展工程師、POC測試工程師、大客戶交付經理、項目經理、產品經理、售后客戶響應中心、老板等。

承擔需求收集角色的人，應該具備 “以客戶場景為中心” 的觀念，應該 對產品定位、邊界、功能很熟悉 ，有基本的產品化思維。

產品經理在技能上最適合做需求收集，但產品經理能接觸到的客戶數量有限，能用于客戶交流的時間精力不足。若讓產品經理來承擔這個職責，則會限制需求收集到的數量。

售前階段的項目，解決方案工程師是需求收集相對更合適的角色，他們可以大量接觸客戶 ，但又不會深度參與項目招投標文件等事務性工作中，跟產品經理溝通機會也多。但很多中小公司職能劃分可能不會太細致，由一個能連接客戶和產品經理的角色來承擔這個職責即可。

售后階段的項目，項目經理是需求收集相對更合適的角色 ，他們可以將客戶、POC測試工程師、交付工程師等角色反饋的需求統一歸口收集，反饋給產品經理，幫助產品經理減少多角色對接的時間精力。

但是，解決方案工程師、項目經理有可能缺乏業務背景知識、需求溝通挖掘的經驗，所以產品經理需要沉淀出賦能指導的材料。歸根到底，其他角色都是幫助產品經理分擔壓力的， 產品經理自身不可脫離需求收集的職能 。

另外，雖然解決方案工程師、項目經理是相對合適的需求收集角色，但由于需求有多種不同渠道反饋，以及需求收集的重要性， 企業需要建立起全員需求收集的文化氛圍 ，把“以客戶為中心”的企業文化落到行動上。

WHERE•從哪些渠道收集需求？

B端產品可以通過訪談、觀察、問卷、工作坊、競品分析、招標文件分析、在線系統等多種方式收集需求， 對于商業化B端產品最常用、最有用的是訪談，其次是招標文件分析、工作坊、競品分析 和在線系統（SaaS比本地部署軟件更適用）。

在售前交流時，由于還未和客戶建立信任關系，不太容易讓客戶說出真實需求。這個階段客戶也會接觸大量的友商，想法天馬行空，又多又雜，很難判斷需求的真實性和價值度。所以， 售前項目不太適合收集需求（但適合驗證需求規劃） ，更適合根據產品能力引導客戶期望。但如果已經建立信任關系，客戶可以提出業務真實痛點，或基于POC操作演示提出明確期望，就可以作為有效需求收集渠道。

客戶的招標文件通常是將多個產品的功能參數拼在一起，其中有客戶真實需要的功能，也有友商引導控標的功能。無論從防止被控標還是發掘潛在需求角度，招投標文件都是不錯的需求收集渠道。 我們需要建立招標文件集中存儲庫，作為需求收集的一種渠道。 同時，也可以通過招標文件看到友商產品進化的方向。通常來講，售前人員是更適合維護招標文件庫的角色。

項目交付時，隨著不斷有新的干系人加入，客戶可能會產生一些新的需求。這些需求可能源于真實的使用場景，有業務價值。但考慮到產品需求排期通常不會隨項目調整，為避免影響驗收時間節點， 交付中項目一般不適合主動向客戶收集需求 。

已驗收售后項目，客戶通常已經在實際業務中使用產品，基于實際使用體驗會產生一些需求。這些需求相對來說更真實、價值更高，不會有嚴苛的交付時間要求。同時，客戶也更愿意安排實際使用用戶深度參與訪談調研溝通，反饋真實的業務痛點。而且，售后需求收集有助于提高客戶滿意度，增加項目擴容續簽概率，一舉多得！售后需求可以由項目經理統一收集反饋給產品經理，產品經理根據實際情況安排線上/線下會議訪談溝通，更全面、深入的了解需求。綜上， 售后項目最適合收集需求 。

B端產品競品分析并不容易做，因為競品的線上體驗環境很難拿到，詳細介紹材料也不易獲取。若能拿到友商詳細材料或線上環境，則可以通過對比分析找出一些值得參考的功能。 競品已實現的功能，通常意味著客戶有真實的需要，是不錯的需求收集渠道 。但是，在競品分析或招標文件分析中拿到的需求，也不要著急納入開發，最好先跟幾個客戶溝通驗證一下，真正了解功能背后的業務需求后再動手。同時，需要意識到，抄競品只能避免產品的競爭劣勢，無法保證產品可以超越友商贏得客戶。 做好B端產品不是跟隨友商，而是跟隨客戶。

工作坊通常是基于特定目的，拉通多種角色通過頭腦風暴來尋找需求。這種方式可以獲取到解決特定問題的大量需求，有助于問題解決，但獲取的需求中也可能存在大量非客戶真實存在的需求。

在線系統（如QQ群、微信釘釘群、論壇、在線表單等）更適合SaaS或自研產品；觀察法更適合自研或純定制產品；問卷很難收集到有效需求；開發團隊或老板的需求，容易偏離用戶實際場景。

若多種渠道收集到相似需求，是不是一種人力資源浪費？我認為不是，恰恰多渠道收到相似需求，更容易證明該需求的通用性和價值，促進產品經理做出正確的決策。

WHAT•需求收集什么信息？

需求收集不是僅僅將客戶的原始需求描述傳遞給開發團隊，它需要通過不斷的提問全面了解需求背后的業務目的。

在需求收集時，不建議以產品功能為中心，而應以角色使用場景為中心，避免過早陷入技術實現、交互設計細節中。

需求收集的信息越完整，對需求分析的幫助越大。我目前提供給售前、交付等職能的是5W3H結構化需求收集法。它比較適用于客戶已有某個明確的“一句話需求”，需要我們詳細的了解、評估該需求。若客戶尚沒有明確需求，則更適宜先做一次全面的業務調研溝通。通過將整個業務劃分成若干的環節，每個環節中放一系列問題，來全面了解客戶業務中可能存在的問題，然后再用5W3H細化了解特定某個需求。全面業務調研更適合用于項目售前、擴容續簽等場景中，而5W3H則更適合于挖掘“一句話需求”，5W3H具體包括：

who，誰提的這個需求？最終影響的角色是誰？解決問題的第一步是先明確這個問題涉及哪些人，誰造成的、影響了誰、誰有能力解決、該誰解決、能否讓其他角色解決等。
why，需求的業務背景是什么？由于什么原因產生了這個需求？了解需求的業務動機有助于判斷需求背后的業務價值，找到正確的問題。
when，發生了什么事，造成了什么問題，所以有了這個需求？這個需求未實現時，客戶是怎么解決這個需求的？過程中有什么痛點（不便的地方）？需求的直接誘因、后果有助于判斷需求價值，以及判斷需求的個性化程度；客戶原有解決方案、方案不足之處，可以為功能設計提供參考。
what，原始需求描述是什么？業務過程有哪些主任務、分支任務？業務過程有哪些異常場景？為了避免需求傳遞過程出現信息偏差，需要記錄原始需求。業務過程主任務是將整個業務過程劃分成若干個環節，分析每個環節中需要的信息、操作及結果；若涉及多個角色，則還需要從每一個角色的視角去分析他要參與的所有環節及步驟，確保主任務過程順暢；分支任務是那些本身完成并不會推動業務目的達成，但可輔助主任務更好完成的任務，比如在運維資源納管這個主任務中，添加一個訪問參數模板是一個分支任務；業務過程中的異常場景、規則約束對B端產品很重要，可以讓功能設計更完善，更貼合客戶需要。
where，客戶期望這個功能做在哪里？使用頻率有多高？客戶對功能使用場景、期望模塊的描述，有助于確定該功能定位，是否在本產品中做，具體做在哪個頁面；使用頻率有助于判斷需求價值度。
how，客戶期望功能怎么做？友商功能怎么做的？有些客戶喜歡直接給功能方案，此時，我們需要追問為什么想這么做功能，以挖掘客戶可能未表達出來的業務目的。客戶對功能的期望以及友商的功能設計，可以給后續功能設計提供參考。同時，客戶對功能的期望及友商是否實現，也可以輔助判斷該需求的個性化程度。
how much 1，需求實現后對用戶有什么好處？業務價值有多大？需求實現帶來的好處是判斷需求是否接納、優先級及排期的關鍵因素，比如實現后可以每次減少30分鐘人工操作，可以縮短業務中斷時長等。
how much 2，需求是否具備全行業或特定行業通用性？是不是個性化需求？個性化需求不適合在產品中實現，ROI不高，還會增加產品復雜度，通常產品不接納，交由定制開發來實現。

在需求收集溝通之前，如果已經知道客戶大概需求方向（一句話需求），盡量提前對業務背景和問題做準備。根據經驗大致推理業務主任務過程、角色主任務過程，提前考慮可能存在的問題。采用業務主任務的模式準備訪談問題清單，可以有效的避免產品功能設計偏離用戶實際使用場景。

最后，我想強調的是， 我們做產品，不能基于功能開發角度思考，而應該從用戶使用角度考慮。客戶要的從來不是功能，而是在特定場景下能解決問題。

HOW•用什么工具記錄需求？

國內外有很多需求管理工具，我也曾給多個運營商做過需求管理系統。這些工具通常大而全，可以實現整個研發過程管理，但我用的最順手的依然還是在線文檔和在線表格。

在線文檔用于跟用戶線上溝通需求 ，在溝通之前我會梳理出業務主任務過程及每個環節中的疑問。在溝通過程中通過在線會議演示文檔，讓用戶能直接看到問題和會議中記錄的筆記。同時，文檔也會給所有參會人授權，每個人都可以在文檔中寫下自己對需求的理解。會議結束后，該文檔可以直接當作會議紀要，也會作為后續需求分析時的主要信息輸入。在線文檔的主要缺點是統一存儲查看不便、文檔缺少結構化屬性標識、跟后續需求分析及開發過程脫節等。

在線表格用于原始需求池管理 ，每一個產品單獨做一個sheet，主要記錄需求描述、反饋人、客戶名、提出時間、期望完成時間、優先級、當前狀態等信息。在產品規劃、需求分析、迭代排期、產品匯報、大客戶交流等場景下，這個文檔是重要輸入。在線表格的主要缺點是無法可視化自動呈現、調整需求排序不便、需求狀態維護不便、數據統計不便、跟后續需求分析及開發過程脫節等。

我期待中的需求管理工具，應該 既具備在線表格的基本優點，又能提供產品路線圖、用戶故事地圖看板、迭代排期看板等可視化呈現 。

在線表格的基本優點包括：增刪改查的便利性，自動保存的安全感，受限分享的自由度，按需調整模板的靈活性。

產品路線圖 是通過時間軸可視化的呈現產品每個大版本中（如季度版本）已完成或規劃中的關鍵特性，它可以 幫助產品經理、高管、售前、開發團隊等角色整體、清晰的看到產品規劃，統一產品認知 。另外，它還可以在大版本規劃(平衡工作量、優先級和規劃容量)、向上匯報、產品品牌宣傳、版本發布宣傳等場景中提供幫助。如何做好B端產品需求收集

用戶故事地圖看板 是敏捷方法論中工具，它主要 用于同開發團隊溝通需求，幫開發團隊建立“以用戶為中心”的思維。 在使用時從左至右按用戶業務過程、操作步驟的先后順序組織需求分類框架，然后將需求按用戶操作步驟填入每一個列中。同時，也可以根據版本規劃創建多個泳道，將需求池中已明確的需求移入版本規劃。故事地圖跟產品路線圖的區別在于，它更關注規劃中未完成的需求，更多以用戶使用過程為視角組織需求。在使用時，可以采用產品級的視角，也可以基于某個大業務過程特性視角組織需求。如何做好B端產品需求收集

迭代排期看板主要用于給特定開發團隊制定近一兩個月明確的開發計劃 ，除了明確已經納入產品規劃中的需求，需求池中還會有一些小需求，以及通過多種渠道不斷收集到的備選新需求。產品經理需要根據團隊容量、需求工作量、需求ROI、迭代目標、項目緊急度等綜合評估迭代中具體排入的需求。需求排入后，通過迭代排期看板可以很直觀的看到每個迭代中的具體需求、開發狀態、計劃完成時間、當前完成度度等信息。