B端產品運營：需求管理的避坑指南

B端產品在需求蒐集、分析、迭代上線的方法上與C端大同小異，但由於B端產品使用對象的角色多樣性，跨部門協作的流程複雜性，B端產品的需求管理相比於C端“坑”更多。

作為一名B端產品運營，你是否面對和處理過這類問題：

• 銷售吐槽：新功能客户不買單，真正亟需解決的問題沒解決；
• 客户生氣：某個常用的功能突然下架而中斷使用，某個功能答應了做卻未按期迭代上線；
• 客服怒懟：產品功能佈局分散影響培訓客户的效率；一個功能突然上線，客户問起我們竟然才知道；
• 運營哭了：需求來自客户、銷售、服務、風控、法務等部門，蒐集、分析和管理亂。

以上這些問題我都遇到過，掉在同一個坑裏的場景也不在少數。在這個過程中整理了本文，提醒自己長記性，如有總結的不對的，歡迎大家指出~

B端產品需求管理的“坑”主要分佈在需求採集、分析、迭代上線三個階段：

一、需求採集

避坑指南姿勢一：收攏需求採集渠道，建立共享需求反饋池，根據需求類型及迭代狀態進行分類管理，讓需求採集及時記錄不遺漏，需求規劃及進度一目瞭然

B端的需求來源分為公司內部和公司外部，細分如下：

需求來源角色多，反饋的信息雜，採集需求的效率低，容易出現錯漏。對於以上各渠道反饋的問題和需求，如果完全由運營對接，不免焦頭爛額，如果漏掉重點需求，還將造成客户投訴。基於此：

1）針對各渠道建立統一對接人。比如SMB客户的反饋彙總至客服，KA客户反饋彙總到客户成功，銷售需求彙總至銷售支持；

2）通過各渠道對接人將需求共同維護至共享文檔，建立需求池，及時記錄，在開始新一輪評審時進行需求方的提醒、補充，避免遺漏；

3）對已上線的需求、已提測的需求、掛起的需求、當前迭代已確認的需求，可進行單獨建表管理；

4）經常review以及重新排定需求池的優先級，基於新的變量的出現，重新整體排一下需求的優先級；

各環節進度在表格中的呈現如下，供參考：

該表流程主要為需求側、產品側和運營側，未提及技術側（比如評審時間、UI、各端開發時間、提測時間等）。

避坑指南姿勢二：對業務側宣導需求初篩規則，在需求首次被提及時，需求反饋對象或需求對接人可對需求進行初篩和答覆客户。

對於客户需求，無原則的統一收下並承諾支持，不一定能獲得客户的認可。一方面，客户提出需求時，説的是解決辦法，而我們真正要了解的是客户的痛點，並給出可行的解決方案。

另一方面，某一功能是否當下立刻滿足，不一定是客户為之買單的根本原因。當需求在首次被提出時，業務人員無須像產研側一樣，掌握Y模型、5W2H等需求分析方法，但可提供基本的初篩規則，可幫助在前期過濾掉不少不合理需求。

另外，無論是業務側還是產研側，在拒絕需求時都要注意語言的藝術：

1. 不要直接對對方的想法提出異議，而是站在對方的立場上思考問題，給出解決方案；
2. 如果方案很多，可從最為重要的可以給客户帶來利益的三點着手，引起客户興趣；
3. 表明方案時，要表明確定的信息，簡明扼要，言簡意賅，不要反覆修改，避免讓對方產生厭惡情緒。

二、需求分析

避坑指南姿勢三：對於客户需求，用心聽，但不要照着做，用5W1H1V方法深挖客户需求

需求分析是指從問題到解決方案的轉化，或者説從用户需求到產品功能的轉化。創新工場董事長李開復曾發微博説道：“很多工程師和產品經理不瞭解：顧客要買的其實不是某個產品，而是他們需要運用一個產品來完成某件任務或解決某個問題。”

有句著名的話：“顧客不是要買鑽頭，顧客要買的是洞。”更進一步説，用户要買的不是洞，而是洞背後反應的更深層次的需求。用户需求背後是目標和動機，更深度的是深度價值觀，是人性需求，即馬斯洛需求。

因此，為避免中間人傳達的信息誤差，產品運營在收到需求時，應組織與客户直接交流，以客户提出的解決方案為起點，運用5W1H1V方法分析問題，先將這六個問題列出，得到回答後，再考慮列出一些小問題，並對問題進行綜合分析研究，從而產生更新的創造性設想或決策。

1）What（對象） —— 可以用這個產品或功能能做什麼？解決什麼問題？

2）Where（場所）——在哪會用這個產品或功能？

3）Why（目的） ——為什麼需要這個產品或功能？和其它產品的區別？

4）When（時間） ——在什麼時候會用這個產品或功能？

5）Who（人員） ——產品或功能為誰設計？誰來用?

6）How（方法） ——如何使用這個產品或功能？

7）value（價值） ——產品的價值？

避坑指南姿勢四：在溝通後存在需求變動時，及時留下會議記錄，並更新相關文檔；需求評估階段，相關部門都需參加評審，驗收方案

為避免客户需求反饋片段分散，提升需求溝通效率，需引導客户完整體驗產品，提出不足之處。經過需求溝通後，如有修改，需及時修改文檔，避免因為歷史文檔，導致錯誤開發；為了避免解決方案與用户需求不符，造成資源浪費，在方案原型階段需跟客户進行可用性確定。

另外，B端產品的功能使用角色不僅一個，進行功能設計、評審、上線時，需做到多方信息確認，舉幾個例子：

1）涉及風控和合規的業務，相關功能上線涉及審核機制或敏感詞庫的建立；

2）對於現有客户能感知到的產品變化，需要與客服同步，並做好上線時的客户通知；

3）對於客户的定製化需求，如設計為通用需求，將給業務帶來諮詢與處理壓力…

三、迭代上線避坑指南姿勢五：上線時間避開產品使用高峯時段

不要為了趕上線時間，把需求安排在週五或臨近下班的時間點上線。出現問題時影響客户體驗，且難以召集人員解決，上線時間應儘量固定時間在非週五、非產品高頻使用的時間段。

避坑指南姿勢六：需求方參與上線驗收

除測試、產品對產品進行驗收外，運營、需求方需先對產品進行驗收後，再上線、引導客户使用，避免漏掉上線需求，或有使用問題。

避坑指南姿勢七：上線及效果評估準備

上線前做好相關團隊培訓，準備上線通告、使用指引。如需同步上線推廣，需提前準備好上線推廣的內容和活動素材；通過上線前後的產品數據分析、渠道反饋等，進行效果評估。

需求管理貫穿整個團隊，產品的需求管理不只是需求的記錄，而是需求的策劃、實現、效果評估都需要。每個團隊需求管理方式可能都不盡相同，適合的方法論才是最好的，如果你也踩過什麼坑，歡迎留言分享~

本文由 @產品運營術與道 原創發佈於人人都是產品經理，未經作者許可，禁止轉載。

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