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

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

• 工作臺上一堆的功能列表，到底是從哪來的？
• 哪個產品大神能突發奇想，設計出這么一大堆功能？
• 這些功能到底解決了用戶的哪些需求？

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

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

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

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

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

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

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

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

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

1. 向客戶（買單人）了解產品定位？

為什么特意把客戶和用戶分開來說？

2B產品的選型過程更長、更復雜，往往是先在企業內部有過多番討論的結果。2B產品的客戶和用戶常常不是同一類人（這里說的客戶指為產品買單的人，用戶指未來產品的使用人）?？蛻舻男枨笠话銈戎仄髽I戰略如何落地，管理制度如何落地，產品能帶來哪些額外價值？

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

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

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

2. 向用戶了解應用需求

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. 提供、確認需求調研報告

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

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

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

這有兩方面原因：

• 一方面，需求調研報告主要就是復述客戶的實際業務和期望解決的問題，并無多少新意，難以引起客戶仔細閱讀的興趣。
• 另一方面，人們對這種幾十頁的正式文本，往往拿起來就有恐懼感，文字閱讀本身是反人性。

建議解決方案：

3.1 向調研對象現場講解主業務流程

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

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

主業務流程圖如下：

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

3.2 將報告化整為零地確認。

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

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

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

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

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

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

小結

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

1. 向客戶（買單人）了解產品定位？
2. 向用戶了解應用需求；
3. 提供、確認需求調研報告。

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

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

題圖來自 Unsplash，基于CC0協議