2B產品的需求調研，還真不是人人都是產品經理

2B產品經理要深入瞭解、挖掘出客户/用户的真實需求，需要先具備一定的企業業務常識+良好的溝通引導技巧。本文作者給大家提供了三個步驟，來做用户訪談，希望能夠對你有所幫助。

當你打開一款2B產品的工作台時，是不是會有個困惑：

上一篇文章《2B產品經理如何快速準確瞭解一家企業業務》，我們講了如何對一家企業有個基本的瞭解，現在我們就可以開始對客户（買單的人）、用户（實際操作系統的人）做需求調研了。

小白可能會問，為什麼要大費周章地先對企業業務做一番瞭解？直接做需求調研不就好了嗎？

如果一名2B產品經理真的這麼做，大概率會在調研過程中，被調研對象在心中貼上：外行領導內行的標籤。

一個2B產品經理不懂業務，卻要去做一款2B產品，如果你是用户，是不是會心裏發毛？

所以，2B產品經理在需求調研前，一定要對調研內容做到心中有數。這完全不同於2C產品是為了滿足個人日常生活相關的需求，只要你有點生活常識，人人都是產品經理，張口就能和用户聊需求。

今天我們繼續2B產品設計的第二個環節：需求調研。

2B產品的需求調研方式，我個人首推通過用户訪談。就像之前我們説的2B產品注重流程，2B產品經理要了解企業業務需求，最好的方式就是通過客户/用户訪談，面對面地和用户溝通、傾聽、交流。

魔鬼藏在細節裏。2B產品經理要深入瞭解、挖掘出客户/用户的真實需求，需要先具備一定的企業業務常識 良好的溝通引導技巧。

你可以參考下面的步驟來做客户/用户訪談：

為什麼特意把客户和用户分開來説？

2B產品的選型過程更長、更復雜，往往是先在企業內部有過多番討論的結果。2B產品的客户和用户常常不是同一類人（這裏説的客户指為產品買單的人，用户指未來產品的使用人）。客户的需求一般側重企業戰略如何落地，管理制度如何落地，產品能帶來哪些額外價值？

因此，2B產品經理在與客户溝通時，要有CEO思維，多從商業（通俗點就是：做生意，你關注什麼）的視角去理解對方的意圖。

與客户訪談，有利於產品經理站在更宏觀視角去理解未來產品的定位。

郝志忠在《用户力》一書中提出，產品設計要先回答產品定位的問題，而產品定位從通俗上來説，要回答：做什麼？做給哪些人用？做成啥樣？這3個問題。

與客户（買單人）瞭解清楚產品定義後，就可以帶上準備好的調研問卷，結合上一個環節瞭解的企業業務信息，找到企業通訊錄上的核心用户，來和用户溝通具體的應用需求了。

注意：事先準備好調研問卷，能讓你更從容、有針對性地進行用户訪談。

調研問卷，可參照下面的思維導圖作為框架：

調研對象、業務角色：相當於我們在招聘網站上看到的招聘崗位、崗位職責。

背景説明：讓調研對象先熱熱身，可以讓TA先比較寬泛地聊聊自己當前工作中遇到了什麼問題？哪些問題希望通過產品來解決？之前是不是有使用其他產品？對新產品有什麼期望？

需求描述、業務過程：引導調研對象結合自己的實際工作場景，描述具體工作細節。產品經理可以初步判斷哪些是產品能解決的問題？一般來説，現有單據（如在用的出差申請單）、審批流程（如根據申請人崗位判斷需哪些領導審批）、業務規則（如根據申請人崗位對應差旅標準）這類可明確、有邏輯、可結構化的的內容都是產品要解決的範疇。這些都屬於功能性需求。

非功能性需求：2B產品用於企業生產經營活動，那麼產品經理就需要多一步考慮：除了滿足用户的功能性需求，是不是有哪些非功能性需求同樣非常重要？

上圖我提到了幾個常見的：

（1）安全性：有的2B產品的數據就是企業的血液。對於數據泄露、丟失等問題，有的企業是零容忍。產品經理就要重視數據安全的相關方案。

（2）易用性：可參考之前寫的2B產品經理的用户體驗，都值得再做一遍

（3）穩定性：2B產品在設計時一定要儘量做到全面規劃。前面説到產品定位要回答產品做什麼？做給哪些人用？做成啥樣？回答清楚這3個問題，2B產品的設計就不會隨波逐流。

這裏插一句：我們日常的2C產品比較喜歡刷存在感，時不時喜歡更新個版本，很多改版只是做些小調整，比如做個頁面改版。目的是讓用户有新鮮感。相反，2B產品因更注重用户的操作習慣，所以應更注重穩定性，能不改則不改。

白鴉之前在內部分享會上説，有讚的產品自從推出第一個版本後，就沒對導航、頁面佈局、交互做過調整。

個人認同：2B產品的每一個設計都要想清楚，不要來來回回不斷調整。每一個大調整，都增加了用户的學習成本，穩定性是衡量一款2B產品設計好壞的關鍵指標。

（4）性能：這個對一般用户比較抽象，用户一般直觀感受是操作時，產品反應速度怎麼樣（比如打開一個頁面不能超過3秒）？翻譯成專業術語就是響應時間、吞吐量、併發數這些指標。

（5）可擴展性：這個可理解為產品的靈活性。比如，產品是否需要為管理員提供參數配置、業務建模等高階功能，滿足業務變動、發展的需求，而不需要額外增加開發工作量。

需求優先級：訪談到最後，用户可能洋洋灑灑和產品經理講了一大堆需求，這時產品經理應要先對用户的需求做一輪概括複述（目的是確認自己是不是有抓住用户需求的核心），然後可以適當引導用户説出其中哪些需求的優先級最高（這是在為後續的產品需求優先級做準備），適當地收斂、聚焦核心需求。

前面我們和客户/用户鬥智鬥勇地展開了一場場的用户訪談，最終還要通過一個產出物-需求調研報告，讓客户/用户瞭解我們對其需求的理解程度。大家互相做到知己知彼，才能在未來的產品設計、開發中不會出現需求理解錯誤的尷尬局面。

需求調研報告的內容需包含前面的2類需求調研內容，需求調研報告的模板可以參照上面的思維導圖。

需求調研報告這類動則幾十、上百頁的文檔，如果直接發給客户確認，往往會石沉大海。

這有兩方面原因：

建議解決方案：

儘量用一幅流程圖講清楚被調用對象的主業務流程，個別需要特別説明的子流程，可以補充説明。

建議通過會議的方式，現場向用户演示、確認，因為這個過程可能會有不少思想碰撞，現場的效果最好。

主業務流程圖如下：

主業務流程是後續產品設計的主軸，我們可以把它視為未來產品的框架，一旦理解有誤，直接影響後續的產品設計、開發。

在工作中，我們會遇到一個棘手問題：文檔到底應該按用户為對象來劃分，還是應該按業務流程為對象來劃分。我的看法是：按業務流程來劃分。

因為任何一個用户在一條業務流程中，都只參與其中一部分。以業務流程為對象來劃分，一方面可保持業務流程完整性。所有與該業務流程相關的人，可看到整條業務流程的完整信息，不會出現疏漏。

另一方面可減少文檔內容的冗餘。如果以用户為對象，不同用户在一條業務流程中存在上、下游關係，描述業務時既得先説明TA的上游用户需做完什麼（類似前置條件），又得説明TA做完後的後續流程是什麼？導致描述不同用户的流程內容時，會出現很多重複內容。

舉例，一條業務流程有A,B 2個用户按順序來一起完成。在描述A用户負責的業務內容時，需要説明A用户的後續流程內容。這個剛好就是B用户負責內容的前置條件。

通過分開確認不同的業務流程，可以降低確認難度。

做完上面的3步，2B產品的需求調研就算完成了。到這裏，我們已經理解了調研對象的詳細需求，接下來，我們就可以進入需求分析環節了。

今天我們講了需求調研時，要做的3件事：

你也可以上手去試試，希望可以幫到你。

本文由 @追夢人 原創發佈於人人都是產品經理，未經許可，禁止轉載。

題圖來自 Unsplash，基於CC0協議