被動獲取資料的行業，一般市場上已經有這樣的產品，客戶有了明確的要求，產品經理只要根據這些描述，基本上能還原業務場景，然后做需求分析。

但這樣的需求分析是有缺陷的，因為這里面一些需求是客戶定制化的，不能代表同行業其他客戶的需求，這就需要產品經理收集更多的資料，從中抽離出共性。

主動獲取合作的客戶，需要依賴公司的長期積累的資源，通過市場銷售人員的反饋尋找標桿客戶。

不是這個行業的軟件公司想做這個行業的軟件產品，最高效，最便捷的方法就是尋找標桿客戶。

4. 標桿客戶的標準

你要尋找這個行業規模做的比較大，組織機構健全的客戶，因為大家都會相互學習，相互模仿，誰做的好，他的管理方法逐漸被其他客戶了解，并效仿，你做的產品才能迎合這些潛在客戶的需求，才能獲得更好的口碑。

在這個尋找標桿客戶的策略上，我們就走了彎路，選擇了一個規模不大的客戶，重管理不重運營，導致產品目標跑偏了，系統耦合嚴重，操作繁瑣，不僅沒有獲得市場認可，反而還讓競爭對手反超了，就因為標桿客戶選擇的比我們的更精準。我們花了一年的時間進行修正，終于回到正軌上，很多研發資源都投入到這個系統上，這個代價是很大的。

做產品背景分析是讓我們對產品做到“心中有數”，接下來的需求分析是我們產品設計的重點。

03 需求分類

在做C端產品時，最重要的步驟是需求梳理，也就是思考什么類型的用戶在什么場景下遇到了什么問題。

那么在做B端產品時，什么是B端產品的需求分析呢？

這個看似簡單的問題并不那么好回答，很多人認為的B端需求就是幫助用戶完成業務流程所需要做的事情。但這樣的理解并不完整，

需求分析并不是在分析系統如何實現用戶的需求，而是選擇一種業務導向的指引將零散的需求串聯起來，形成一個體系完整、內容清晰的框架，為下一階段的產品設計工作做準備

真正接觸了客戶你會發現B端的需求包含三種：

1. 表面需求（用戶想要的）

用戶經常從自身角度出發得出問題的解決方案。因為對產品定位、設計的依據等情況不了解，他們的建議很多時候并不是該功能的最好實現方式，也就不足以直接作為產品規劃的直接依據。如果根據表面需求來設計產品的話，很可能會出現“頭痛醫頭，腳痛醫腳”的情況。

2. 本質需求（用戶需要的）

用戶想解決的根本問題。獲得用戶的本質需求更可能找出更合理的方案來解決用戶的問題。

3. 產品需求（我們能給的）

依據用戶想解決的根本問題，得出的更好的問題解決方案。解決方案可以理解為一個產品，一個功能或服務，一個活動。

這里重點分析一下需求轉化的過程，叫需求透視，即透過現象看本質，我相信這是每個產品經理必須具有的產品能力。

我們們要做的事情就是挖掘本質需求。

主要任務是梳理清楚目標客戶所有的業務類型。為不同的業務類型劃分界限。并梳理出每個業務類型中所有的需求，也就是需求透視的過程。

04 業務流程分析

做好需求透視第一步就是要做業務流程分析，就是針對每一項業務事件，分析業務活動的特點，并確定業務活動之間的關系。具體要做的事情是：

1. 記錄這些業務活動需要接收哪些信息；
2. 記錄這些業務活動將產生哪些數據（報表），并確定數據傳輸的路線；
3. 標識出這些業務活動是由哪些部門、崗位在負責；

B端客戶的核心價值就是對外部用戶的訴求進行處理，在為用戶創造價值的同時，為B端客戶創造價值。

因此由業務事件觸發的流程是分析需求時的核心線索。

在進行流程分析的時候有兩個關鍵要點，一是理解流程的層次性，二是了解流程的類型。

1. 流程的層次性

為了方便大家理解，這里我以親身實踐的一個客戶培訓來舉例：某省農業農村局委托某高校承辦全省鄉村第一書記參加某線上直播培訓。

流程有組織級、部門級與崗位級三個層次；

1. 其中組織級是指經過抽象、提煉后的業務事件，如上圖中受訓方、組織方、承辦方；
2. 部門級是指具體每個崗位負責什么活動，以及這些活動之間的關系。它是需求分析的主要線索，也是流程分析的主要輸出，如上圖中的省農業農村局、項目管理部等；
3. 崗位級是指每個業務活動具體的操作步驟，屬于需求細節，如上圖中負責人B，班主任C等。

整個報名流程，在我們平臺如何實現報名需求：

第一種方案：市場部告知項目管理部有某個培訓要組織，項目管理部在平臺創建培訓班，有組織方分享給受訓方自己線上報名，班主任直接看后臺數據就可以了。

第二種方案：有組織方上報報名名單給項目管理部，項目管理部在平臺創建培訓班，導入用戶名單，生產用戶賬號，發送報名成功的信息給用戶就可以了。

2. 流程的類型

在B端客戶實際業務中，根據業務流程的目標可以將其分成不同的類型，一般我們可以分為生產流程、管理流程以及支撐流程三類。

1. 生產流程是流程中最重要的部分，也是體現B端客戶價值的業務環節，通常最容易識別；
2. 管理流程是對生產流程的管控，通常是對流程效率與質量的監督控制；
3. 支持流程是對生產流程的補充，通常是對主流程起支撐作用的環節，非必須但容易忽略。

在本次培訓過程中，高校培訓部作為承辦方，在進行項目申報、培訓方案制定、培訓班創建等這類環節都屬于生產流程。

在這個主流程以外，每一個環節都有相應的審核操作，以及培訓過程中進行學員簽到、考核等這種流程屬于管理流程。

在培訓過程中，需要合同審批，項目備案、后勤管理等這些流程屬于支持流程，有這些功能更好，沒有功能能實現，客戶自己線下也能實現。

在產品設計的過程中，我們優先設計生產流程，也就是B端客戶的核心產品模塊；

在生產流程走通的情況下適當做一些管理流程，以保證客戶滿意度，這是產品亮點，也是產品的目標；

在后期的迭代過程中，根據客戶的要求上線一些支持流程功能。

05 角色與使用場景分析

做好需求透視第二步就是要做角色與使用場景分析，這個是很重要的分析過程，一個功能脫離了用戶使用場景，用戶就會感到很不爽，甚至直接放棄使用。

上面講的企業故事，這里講一個用戶故事來幫助大家做角色與使用場景分析。

作為某某使用者/參與者，通過某項操作，以便能夠達到特定的目標。

用戶故事是指某種類型的用戶為了完成某特定目標所執行的一系列操作。在描述層面我們可以暫時忽略業務目標，因此一條用戶故事包含兩個元素：參與者、做什么事。

例如，班主任要求學生完成簽到，就會遇到很多應用場景：有學員在現場報名時簽到，有每次線下上課前進行簽到，有每次線上上課前進行簽到等等。

于是我們平臺有了數字簽到、雷達簽到、動態驗證碼簽到、靜態二維碼簽到，這個四種簽到方式。

可有了這些簽到方式，常常還是有客戶抱怨太難用，很難理解系統的意思，也不知道從哪里去找需要的功能。

因為在傳統的結構化分析與設計方法中，對事物的分析視角都是站在解決方案層面思考的，即這個系統需要有什么，從系統的角度出發做功能規劃。

而以“用戶故事”驅動的需求分析方法，是一種更側重于“從用戶的角度出發，將系統當做一個黑盒子”的視角，這種方法能夠有效解決上述問題。

以線上學習每次班主任發起數字簽到為例，因為每次培訓正式開始前，班主任都會創建微信群，方便總要信息及時通知學員。這個場景下班主任和學員特別依賴微信群。如果班主任發起簽到能直接分享簽到鏈接到微信群，學員在微信群里直接打開完成簽到操作。學員不用在平臺之間直接跳來跳去，切換操作。

這樣一個分享的操作，即減輕了班主任給學員反復解釋操作流程的工作量，也簡化了學員的操作流程。這樣用戶就會感覺很爽，班主任也沒有負擔。

從另外一個角度來說，用戶故事的關鍵點在于發現使用系統的用戶，了解并梳理這些用戶如何使用系統，從而達到“以人為本”的需求分析。

面對一個陌生的領域，一個經歷了多年發展變化的業務流程，要在短時間內弄清楚的確是一個不小的挑戰。用戶場景分析的意義在于幫助產品經理在短時間內從結構、整體上了解業務構成。產品不斷迭代的前提就是建立在用戶場景不斷優化、不斷調整的過程中。

06 獲取用戶需求

在客戶調研的時候，經?？吹疆a品經理傻里傻氣地問客戶：你對這個產品有什么需求或者有想法嗎？

但不管用戶怎么回答，似乎都很難讓我們滿意?？蛻籼岵怀鲂枨?，你會覺得我們的客戶對這事好像也沒那么上心；更多的時候是客戶提的需求都是不痛不癢，或者你感覺極具個性化，讓你感覺做也不也是不做也不是；

和C端場景一樣，B端場景中的用戶需求也像是一個冰山，有很大一部分信息是埋藏在海平面之下，這就對需求調研工作帶來很大的困擾。

調研的客戶畢竟不是技術專家，只是普通的業務人員，因此他們沒有辦法對其工作提出產生變革的解決方案。因此需要產品經理對問題充分理解的前提下，選擇合適的實現方式以創造出用戶未想到的功能；

我在本次產品改造過程這些場景，也經常遇到，其中一個經費審批表導出就改了無數回，最終還是不滿意。

例：客戶提出需要導出PDF格式，防止業務人員隨意篡改。

我們照客戶的要求實現，我們滿心歡喜地給到客戶時，客戶說這功能還是不實用，發現在實際工作中，有的文字內容過多，表格顯示不全，導致分頁顯示，客戶表示不滿意，我們后來改回了word格式。

客戶反饋他們需要導出每個審批步驟和審批結果，我們照客戶的要求實現，發現在實際工作中，他們增加了審批步驟，還是導致分頁顯示。我們后來我們改成了審批流程自定義導出。

反反復復修修改，最終的方案，就是按照客戶模板回填數據即可。

這樣一個很小的功能，導致我們投入很多的開發資源，深挖客戶需求原來是：客戶從線下審批到線上審批需要過渡，需要平臺 數據導出數據以備年度領導審查，備案需要。

這個例子就是我們只發現意識到的需求，而沒有深究以及進一步分析的后果。

實際上B端產品的需求獲取并不難，難的是與用戶交流溝通的過程。因為我們的用戶僅僅作為一個使用者，他只是站在自身使用的視角，想讓自己的工作方便一些或是在利益分配上對自己更有利，很難站在系統規劃的角度考慮全面整體的東西。

遇到這種情況，最有效的應對策略是需求分析從流程入手，搞清楚業務活動在平時是如何開展的，再逐步過渡到存在什么樣的障礙，有什么困難等等。在這個過程中，多問幾個為什么，多思考客戶訴求背后代表的心里狀態與利益沖突。

所以這一階段，我們主要做的工作是收集針對業務活動的問題點、需求點。這時候我們獲取到的是原始的用戶需求。

實際上，在整個業務分類、需求梳理的大環節中，業務流程分析、角色與使用場景分析、以及獲取用戶需求都是伴隨著用戶調研進行的。

用戶調研是一個有計劃、循序漸進的過程。具體來說，在針對不用的訪談對象時，訪談的要點也不盡相同，具體的要點參考以下表格：

除了用戶訪談和問卷調查以外，有機會到業務工作中實際現場觀摩也是一種很好的需求獲取手段，有助于產品經理對業務場景建立更加感性的認識。在對關鍵任務理解不清晰、很多東西用文字沒辦法表述時，現場觀摩都是一種很好的方式。

到了這一步，我們已經收集到足夠多的業務信息供我們進行后續的需求分析工作。

07 需求細節確認

首先，我們按照需求列表按照職責、部門、崗位整理歸納，這樣我們能把產品劃分成不同的業務板塊，在這個層面看哪些系統需求是針對業務事件，確保業務流程正常進行的；哪些系統需求是針對報表的要求，確保流轉過程中的數據傳遞；

接下來再往更細顆粒的維度整理，梳理哪些系統需求是支持業務步驟的，基于這些業務步驟需要設計什么樣的功能點。這樣一來所有的系統需求都按照清晰的脈絡，層層遞進展現在我們面前。

在這些需求梳理的過程中要明確哪些是前置條件，哪些后置條件。

所謂前置條件是指在用戶操作某個功能的時候，用戶與系統應處于什么狀態。這個狀態是系統能夠檢測并且是有意義的。而后置條件是指在操作結束時，系統應處于什么狀態。同樣這個狀態也是系統能檢測到并且有意義的。

再通過上面組織培訓的例子來加深理解：

受訓方有培訓需求：這不是一個前置條件，因為這是系統無法檢測的；

當市場部和組織方達成合作意向，甚至簽訂協議或合同：這也不是一個好的前置條件，雖然系統可以檢測，但是只是一個支持流程，不是主要流程，客戶可以選擇不用，這個事情所表現出來的意義不大，對我們來說沒有幫助；

在項目申報審核通過：這是一個好的后置條件，當然也要根據客戶實際使用情況，但是系統可以檢測并且事件對流程有影響；

項目申報通過后，項目管理部或市場部進行培訓班的創建，復用項目申報的一些基礎數據，添加培訓簡介之后對外發布展示。

一般來說，前置條件通常是一種狀態，后置條件可能是一種狀態，也可能是一種后續行為。并非所有的業務流程都必須在平臺上存在前置條件與后置條件。

明確哪些是前置條件，哪些后置條件，能減少甚至避免在功能設計中流程耦合。

這種結構是以業務流程為整理的主線索，也就是按“事”的角度進行分解。這種方法對于工作流系統以及信息管理系統來說都是非常適用的方法。

08 消除需求間的矛盾

以上整理需求的方式，是按照業務流程進行整理的。在這個分析過程中，因為我們的需求來自不同的部門不同的崗位，難免會發現有些需求是互相矛盾、互相沖突的。

因此我們在整理后的列表中需要將這些矛盾的需求全部圈出來，然后快速地找到相關人員，通過進一步的溝通協調來消除矛盾的需求。

很多時候，需求沖突的真正原因是使用者與管理者之間的沖突。作為使用者，他的核心訴求是方便高效、省事，最好還能在某些方面獲得一定的利益；作為管理者，他的訴求是流程規范、過程可追蹤，杜絕損害公司利益的事情發生。

例如，項目管理人員/市場部因為委托方有很多不確定因素，自然希望在項目申報的時候能夠更彈性，有一些自由度。但是作為主管部門領導，他們需要嚴格執行審批制度、財務報表審批制度等，導致系統上有很多信息是必填項，操作者感覺很繁瑣。

從這個例子可以看出來，不同角色由于崗位不同，核心訴求也不一樣。

在發生沖突的時候，我的建議是以客戶的生產經營為核心，首先確保經營活動的規范化、流程化進行，在這個基礎上增加為普通使用者考慮的易用性設計與情感化設計，讓他們感受到產品不單單是一個反感排斥的工作系統，而是真正幫助他們提高工作效率的產品。

完成這一步后，才算是將整個產品的系統需求全部整理出來。以后每次迭代就是在業務需求與用戶需求的基礎上，創建新的系統需求，不斷完善、豐富產品。

09 最后

大多數C端產品的設計邏輯會把用戶體驗與效率放在首位，追求極致的簡單好用于高效。在整個產品設計上比較側重用戶的感受，精心打磨頁面與交互，盡量少讓用戶做選擇，保持產品的易用性與流暢性，都是做C端產品設計的不二法門。

但是做B端產品時，所有的產品設計都是為“流程”服務的。體驗和效率未必是設計的重心。

很簡單的一個例子就能明白：我們按照客戶的需求上線CRM模塊，不是為了讓市場人員更輕松，做業務的時候更“省事”，而是為了將整個客戶跟進的流程管理起來，做標準化的流程，為管理者提供更準確科學的決策。

又比如上面提到的，班主任和學員之間的互動基本都是靠微信群進行，這就要求我們產品增加微信一鍵登錄，微信分享機制，來減少學員的操作路徑。

B端產品更多是通過計算機技術實現B端客戶的信息化管理，對業務流程進行優化升級，從而達到降本增效的目的。

由此可以看出來，做C端產品更注重對“人”的理解，要求產品經理具備同理心，感知用戶的能力。而做B端產品更注重對“業務”的理解，要求產品經理具有系統性的邏輯思維，富有理性地對客戶業務進行全面梳理與診斷，給出合理有效的解決方案。

作者：時光；公眾號：時光遇見生活

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

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