在上兩篇文章中，筆者就用戶調研和競品分析這兩個方面提出了自己的一些見解。接下來，就要到產品分析部分了，而需求分析將會是第一步，接下來讓我們看看筆者怎么說的吧：

在各大PM論壇里，C端產品的需求分析指導文章已經很常見了，而B端產品的需求分析也有很多大牛提出了自己有針對性的見解。那么在本文中，筆者結合自己實際的工作經歷，分享一下在B端產品設計前期的需求分析方面所收獲的經驗，以供大家共同學習交流。由于專業及領域限制，難免存在偏差或謬誤的地方，還請各位前輩指點一二，筆者感激不盡。

筆者將從三個步驟展開需求分析的相關論述，其分別為需求收集、需求整理、需求轉化。

一、需求收集

要想設計一款優秀的B端產品，首先就要廣泛的收集需求。B端產品的需求來源要比C端產品的需求來源廣泛，簡要來說大概有以下幾個方面：

針對上述幾個方面，簡要介紹一下每個需求來源方的情況：

• 客戶：這里主要是通過調研客戶時收集需求，包括To B角色鏈中的決策者、運維人員、最終用戶。至于如何有效地調研客戶，可以參考筆者的上一篇文章《B端產品經理進行客戶調研的三個階段》。
• 公司內部：公司內部的來源主要有三個方面：一是與其他產品線合作的需求；二是產品線內其他同事，例如運營、技術服務、定制組等同事提出的需求；三是公司內部對于產品本身合規性的需求，例如軟件銷售許可證、軟件著作權所需要的一些需求點。
• PM本身：這里主要是PM自己通過競品分析或者YY出來的一些需求。
• 技術突破：這是一個值得關注的點，相對于C端產品來說，行業內技術突破往往會在一定程度上影響B端產品的發展方向。舉個例子：筆者曾從事企業數據安全行業，隨著中國大陸HTTPS加密技術的普及，越來越多的網站及應用開始使用HTTPS加密自己的流量；那么筆者在設計數據安全產品時，首要考慮的需求就是如何解密HTTPS流量，如果流量無法解密，那么企業數據安全也就無從談起。
• 外部環境：這里主要是關注國家政策、法律法規的變化，有時候新的法律法規或政策能催生出一個全新的行業。
• 老大/老板：這個就不說了，都是PM，大家心里都懂。

好了，我們在通過多方渠道將需求收集完畢后，面對一大堆需求，你肯定會感到頭疼，別急，下一步要做的事就是將它們進行整理。

二、需求整理

對于需求整理來說，核心就是要從一大堆需求里挑出該做的需求，然后把這些需求按照優先級進行排列。

關于優先級，筆者有一點想法，曾經在一位前輩的文章中看到一個排優先級的做法，即將需求按照百分制進行打分，分數高的優先級就高，后來試行了這一做法，發現被開發同事拿刀追著砍。后來跪地求饒才知道，對于開發同事而言，無論一個需求的優先級高還是低，最終都是要做的。既然都要做，又何來分數高低一言。因此，筆者之后在排需求優先級的時候，都只是排出了每個需求的最晚完成的迭代版本，而不分一個迭代版本里需求的優先級高低。

當然，不同企業有不同企業的做法，各位PM還是按照自己與開發同事最舒服的相處模式進行即可。

回到文章，我們在收集了一堆需求后，如何從一大堆需求里挑出該做的需求呢？

筆者有如下幾點建議：

1. 基于業務場景進行整理

B端產品就關鍵就在于解決業務場景中遇到的問題。那么，我們可以基于真實的業務場景流程，梳理我們所收集的需求。

舉個例子：筆者設計的產品為企業數據安全，那么其針對的最典型的場景就是數據泄密?；跀祿姑艿膱鼍?，我們可以梳理出在【泄密監控】-【關鍵數據外發】-【泄密檢測】-【泄密告警】-【泄密舉證】-【線下處置反饋】-【持續泄密監控】這一泄密流程中所需要的一切功能和需求點，進而整理出該做的需求。

2. 基于決策鏈進行整理

前面幾篇文章也有提到，B端產品的決策鏈冗長而又復雜。我們在整理需求時，也可以從Key Person的角度出發，去整理一些針對決策鏈中關鍵人物的需求。

舉個例子：還是企業數據安全產品，這款產品在企業中涉及到的關鍵人物如下圖：

基于這些關鍵的決策人物，我們就可以去整理產品的需求，例如：針對CTO，我們的產品所使用的技術一定要夠前沿，如使用神經網絡分析等等；針對IT運維主管，產品的部署和實施要盡可能簡單，最好能旁路部署等等。

3. 基于緊急程度進行整理

這里可以采用大名鼎鼎的四象限法則進行整理，舉例如下：

（皮一下不要當真）

4. 基于整體性進行整理

基于整體性進行整理的意思是，我們在整理需求的時候，既要能夠看到產品的細節，也要能夠看到產品的宏觀。你可以想象成隨時放大/縮小一款產品，這樣就不會被局限在某個小細節或者小需求中，能夠跟全面地去考慮多個需求之間的關聯性。

基于上述四點建議，我們挑選出了一堆需求并確認了其優先級。那么，接下來我們可以將它放到一個需求矩陣中去。需求矩陣的內容包括如下：

其中，有幾點需要說明：

1. 需求受益人指的是此需求實現后，最終落實在產品交付層面上的受益人。例如：采用了機器學習技術，那么這里的受益人就是CTO（技術把關者）；采用了旁路部署模式，那么這里的受益人就是運維人員（降低工作量）。
2. 需求實現復雜度和人力估算，最好找個時間和開發經理坐下來，互相溝通一起評估，避免由于對技術不了解而隨意評估導致被砍。
3. 變更說明一般在需求變更后，要詳細的填寫變更原因和直接變更人，避免背鍋。

最后還有一點，相信每一位B端產品經理在職業生涯中都會遇到一個永遠繞不開的問題——定制化。如何找到產品標準化與定制化之間的平衡——有哪些需求在整理時可以放棄，轉而采用定制的方式解決；而又有哪些定制的需求，可以合入通用版本，以降低定制工作量。

這里面有很多坑，而這些坑筆者都踩過，真的是一個都沒有落下。后續筆者會單獨寫一篇文章與各位分享其中的辛酸苦辣，各位可以提前準備好瓜子小板凳。

三、需求轉化

在整理好需求矩陣后，我們就可以開始著手需求的轉化工作了，說白了就是寫文檔、畫原型。其中需要注意的是，與C端PM所需要編寫的PRD不同，在筆者曾就職的企業中，B端PM需要編寫兩份文檔，一份是用戶場景需求文檔，一份是系統需求文檔。

用戶場景需求文檔，顧名思義，就是基于用戶真實的使用場景去編寫一份文檔。文檔的基本編寫邏輯如下：

【什么業務場景】-【什么問題】-【客戶有什么需求】-【期望操作步驟】

需要注意的是，在編寫用戶場景需求文檔是，要將所有的需求點都納入進來，而不是只寫某一個迭代版本中的需求。對于B端產品來說，這一份文檔是最重要的，能不能發掘客戶真實的業務需求就看這一份文檔寫得全不全，有沒有寫透徹。

因此，在用戶場景需求文檔編寫完成后，需要召集市場、運營、開發同事進行一次需求文檔評審會議。怎么開會估計各位PM比我還懂，此處略去會議過程，但是有一點要注意，在用戶場景需求文檔的評審會議中，要盡可能地避免討論技術實現的問題。

評審通過后，就可以拿著需求矩陣和用戶場景需求文檔去找交互設計師了。一般來說，在B端產品企業里，PM都不需要自己動手畫原型。所以筆者也只是負責跟交互設計師對接需求即可，專業的事還是交給專業的人靠譜。

在交互設計師給出基礎的交互設計圖之后，需要組織產品組內同事對交互設計圖進行一次評審，評審主要是為了檢查產品在交互設計中用戶的業務場景流程完不完整，是否存在邏輯不合理的問題。通過后，便可以不斷完善交互圖中的功能細節。

待交互設計圖完善后，還需要寫一份系統需求文檔。這里就和各位C端PM們的PRD工作差不多了，基于交互圖，指出某個功能在某個場景下的操作步驟及結果。但是需要注意的是，系統需求文檔中也需要給出一些基本的技術參數，例如查詢功能的響應時間要求、底層架構穩定性要求等等，這些參數要盡可能量化，如果不好確定，可以與開發經理一同確認。

最終，需求轉化后的結果就是兩份文檔+一份交互設計圖。此時，需要在正式開發前，組織一次外部評審，邀請其他產品線的同事，最后檢驗一次產品的所有設計細節，當然，這里面也會有很多坑，例如會涉及到需求變更、技術實現難度等等。后續，筆者會單獨出一篇文章，講一講在B端PM在各類評審會議中遇到的坑。

至此，一次需求分析的過程結束。由于篇幅原因，其中很多細節并未詳細描述，例如：交互設計、需求變更、評審等。

正常來說，一次B端產品的需求分析少則數周，多則數月。在其中，你可能會無數次推翻你曾確信的需求，你也可能會改無數次文檔，甚至連交互設計小姐姐都改圖改到不想再改了。你可能會很痛苦，團隊也會很痛苦，但要相信，當你經歷過痛苦后，看到自己心心念念的產品一點一點被打磨出來，又被成千上萬家企業所使用后，這種成就感是無與倫比的。那一刻，你會覺得這一切都值得。所以，保持強大的內心，才能堅定的走在To B的道路上。

B端產品不易，且行且珍惜。

本文由 @魔力貓 原創發布于人人都是產品經理，未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議