需求調研，是每個產品經理的重要工作之一，而需求調研的質量將直接影響到產品最終的價值。

對於B端產品而言，通常業務複雜度高，我們不僅僅要花大量的時間去學習業務基礎知識，而且需要在有限的時間內，調研多個崗位的業務人員，提煉關鍵信息，做好產品的定位和規劃。

疫情發生後，遠程相關需求也日益增多，相關產品也在和時間賽跑。

老闆說：“咱們客戶要做一個在線培訓系統，要求2個月內上線，你趕緊去調研一下。”

通過遠程會議對客戶單位進行初次需求摸底調研後，發現需求五花八門，無從下手。

客戶老闆：趕上疫情了，咱們現場培訓都沒法做了，我們的業務有培訓的要求，我需要一個遠程培訓系統，必須保證培訓效果，最好能監控培訓……對了，2個月內要上線，否則直接影響我的業務開展。

培訓部領導：每次組織培訓都太難了，總是有人忘記，還得一個一個核對，講師的考覈也得一個一個去問，太麻煩了。

培訓部小夥伴：每次組織培訓難，培訓後的檔案太多了，每次統計存檔更是痛苦了，還得統計課時，發放課時費給講師，太費時了。

講師：每次自帶電腦去投影，有時候半天都調試不對格式，太浪費時間了，上課那麼累，下課後還得自己去閱卷。

學員：這麼多培訓，隔三差五的，地點也不固定，又沒有課表，經常還臨時變動，一不留神就可能錯過培訓。

這麼一看，看似簡單的一場培訓，其實中間的環節並不少。調研信息量那麼大，作爲產品經理要保證產品的規劃儘可能完整，怎麼規劃設計呢？每個用戶的訴求都那麼多，而產品的定位是什麼？核心功能該是哪一個？ 需求那麼多，2個月上線，沒有較大的資源投入，估計是不行了，每個需求聽上去都非常急，那麼優先級又該如何去排呢？基於這些多的信息又如何抓住重點信息，爲客戶及用戶定製一個更爲合理的方案呢？

有限的時間，如何在初次摸底訪談調研的過程中快速的抓住核心信息，不被業務的“訴苦”帶偏，精準定位產品重點。這些信息，我想必不可少。

完整的業務流程

完整的業務流程，可以幫助我們梳理產品的信息流向，更重要的是將直接關係到我們產品的主要功能的提煉，讓我們產品的規劃有完整結構，不會缺胳膊少腿。完整業務流程對產品藍圖的規劃提供重要的信息。

以培訓這一場景爲例，提到培訓我們可能自然想到的就是授課及考試兩大塊功能。

如果我們去調研一下完整的線下流程，通常有這樣一些環節：相關部門發起培訓計劃，講師進行培訓備課，培訓現場簽到，講師現場授課、互動，學員考試，講師閱卷，課堂反饋調查，課程記錄存檔，課時費發放等。（此處舉例爲截取部分環節非完整流程）

調研完完整的信息，如果我們再去規劃這麼一款培訓產品，就自然可以對應到：培訓計劃、課程資料管理、線上簽到、直播授課、在線互動、問卷調查、考試管理、檔案管理、數據報表等這樣的功能。

完整的業務流程，可以一一對應產品藍圖中的功能模塊。而如果不梳理完整的業務流程，在規劃產品藍圖的時候，很有可能會漏掉某一個關鍵功能的規劃，影響產品的價值，甚至可能因無法完整的滿足業務流程的閉環而夭折。

各業務環節優先級以及日常工作花費時長、頻次

我們知道高價值的需求通常有幾個特徵：強烈、普遍、高頻。

強烈：用戶越願意爲之付出成本（經濟、人力等）越高，通常對這一需求的渴望更爲強烈。

人的慾望總是很多的，但是能夠願意讓我們付出成本的，纔是更強烈的需求。比如我們每個人想買的東西是不是很多？那我們最終買回家的，都是經過我們深思熟慮，真的特別想要的，或則買了後能帶給我們強烈滿足感的。這就是強烈的需求。

B端產品不同於C端產品，B端產品的價值直接體現在業務的降本增效。大部分B端產品都是將許多的純人工操作進而由信息產品來替代，達到節省人力成本，提升效率的目的。

因此在調研B端產品需求的時候，往往用戶會提到很多的述求，以希望減輕自己的工作量。每一個述求聽上去都很有價值，也能解決某一類人的痛點，但在產品0-1的過程中並不可能都滿足。只有抓住用戶強烈的需求，才能讓用戶對產品的整體滿意度提升，將產品的價值儘可能最大化。

在調研的過程中，我們可以嘗試與客戶及用戶溝通其預算情況，並引導其在預算及時間的相對情況下，不能涵蓋所有業務，傾聽他們的優先級作爲參考。往往其共同認爲優先級較高的，即其更願意爲之付出成本的需求，其需求也往往越強烈。抓住這些需求，有利於在有限的資源及有限的時間下，讓我們的產品滿意度提升，產品價值最大化。

普遍：某一業務環節所花費時長佔整個業務鏈條時長比例越大，通常該業務具有普遍性。

某個環節的花費時長=∑該環節各個相關角色花費時長，當某一個業務環節在整個業務鏈條裏面花費的時間越長，通常說明投入的時間較長、或則投入的人力相對較多，那也代表其受衆相對廣泛，具有一些共同性，也就是該業務環節的需求，很有可能出現普遍性需求。

在整個業務鏈條上，花費時間佔比較多的環節，那我們就值得倍加註意了。否則可能眉毛鬍子一把抓，核心功能沒調研好，而錦上添花的做了一大推，產品的定位完全偏離。

比如在培訓這一業務場景下，我們可以注意到講師進行培訓備課以及現場授課的業務是花費時間較長的，備課的環節用戶僅爲講師，而授課的環節用戶是講師及廣大的學員，甚至培訓組織者。

那麼整體來說授課的環節的受衆、耗時是更高的，同時授課也是培訓的核心。授課環節需求其價值也可想而知更高。授課環節作爲講師、用戶、管理者的願景期望是什麼，都將是我們需要重點去調研分析的需求。關心教學的質量，也許我們需要對學員的參與情況進行監控；擔心上課的氛圍，也許我們需要對課堂的互動需求花些心思。

高頻：某一業務環節發生的頻次越高，通常則對應高頻這一特徵。

某一業務環節發生的頻次很高，用戶經常使用到，其需求更加被重視，在高頻的場景下，因爲使用的頻次高，用戶的體驗更爲深刻，不合理的設計或則不好的體驗等，則極可能帶來用戶的對產品整體影響的降低，以及使用的牴觸心理，不利於後期產品的使用推廣。同時，高頻的業務也將作爲我們需求優先級的一個重要依據。

在培訓這一場景中，培訓簽到花費的時間很短，也許和課時統計補貼發放花費的累計時長相差不大。簽到是每次培訓必發生的，如果簽到體驗不友好，流程繁瑣，或則極爲不穩定，則會引起用戶反感，甚至放棄使用。課時費發放，未必每次都會發生。

實際情況中，也許是一個月累計發一次，甚至更長時間。那我們的版本規劃時，初期的版本則可以考慮先記錄數據，縮小版本的邊界，降低產品週期過長導致的風險，而隨後的版本快速迭代中再進行優化。

現狀所遇到的問題

業務環節中難免出現一些特殊情況，特殊情況往往對應了產品的邊界。哪些需求是真實存在的，哪些需求又是產品經理自己虛構出來的？

瞭解業務環節中的特殊情況，首先是可以避免因爲信息不全面而導致的產品設計的缺陷，也可以避免因過度追求完美，而使系統過於龐大。同時、業務所遇問題還可能是業務深層次痛點需求所在。

在培訓中，當培訓計劃已發佈通知到全員，有一種特殊情況當臨時出現受到場地限制影響等情況下，培訓需要更改時間或更改地點，同時需要確保通知到所有相關的人員。

那麼我們產品的設計可能就會對應培訓計劃支持變更、支持變更後的信息通知推送、甚至還有可能需要支持信息推送的閱讀統計等。而如果不知道這樣的特殊情況，則很可能忽略通知推送這一功能，影響培訓的參與程度。也許我們想畫蛇添足，加一個消息收到回覆功能，而實際上發現現狀發出去的短信，回覆的寥寥無幾。其價值可想而知。

同時，現有業務現狀最大的問題，疫情發生後，短期內面授培訓不能開展，將影響到業務發展。這就是當前環境下，業務最大的痛點，也是現階段我們產品的核心定位。

業務現狀所遇到的問題，包含現狀有解決方案的那是我們產品的邊界，也包含現狀沒有解決的那是業務的痛點。

B端產品的信息都不脫離業務，那麼業務信息的本身是調研的重點。調研信息那麼多，這些我們不能忽視。這些信息，可以讓我們對產品的定位更加清晰，對產品的價值更加明確，對產品的規劃更加完整，對需求優先級的排序更有理有據。

希望這次的分享能對你有些作用。也歡迎大家一些交流探討一些好的方法，共同成長進步。

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

題圖來自Unsplash，基於CC0協議