做完100+外包項目後，我用4維度提問法搞定產品需求
產品需求溝通你知道怎麽開始嗎？如何快速獲取和了解客戶的真實需求，並確保信息的完整度、準確度是一個非常重要的技能。我在做過100多個項目後，將溝通方法總結如下。
“做了一年的需求，最後產品竟然不是甲方想要的！”今天聽前同事跟我抱怨。他們公司去年接手了某電影院線的網絡產品開發項目，交付時卻鬧得雙方都不愉快。前同事在分享吐槽的同時，也希望我能幫忙找找問題。
現在的我，正在外包大師擔任產品顧問。身處這個崗位，每天都要對接大量的項目需求。對於需求和執行雙方，產品顧問都是一個關鍵位置，如果這一步出了差錯，後面的一切都將沒有意義。
如何快速獲取和了解客戶的真實需求，並確保信息的完整度、準確度是一個非常重要的技能。這個技能中涉及了很多維度的知識，從產品、運營、設計、技術到對各個行業的了解都決定了自己對客戶需求把握的深度和準確度。
在這裏，我將主要分享如何快速準確的了解客戶需求並確保需求的完整度，這是我在做過100多個項目之後總結出來的經驗。
因為對接的客戶人群和專業水平維度相差很大，所以挑戰也很大。從所處行業分，有傳統行業、互聯網、物聯網、人工智能、區塊鏈等；從對接人的專業技能和身份看，有制造車間主任、互聯網產品經理、技術人員、CEO、投資人等等。在與他們溝通外包需求的過程中我主要使用了提問法，這種方法讓我在做前期需求溝通時收到了事半功倍的效果。為了便於理解，在這裏我將其從不同維度細分為以下4個階段：
1、想法到需求
2、需求到功能
3、範圍到業務邏輯
4、業務邏輯到框架
下面，我們就逐個來分析。
1、想法到需求
很多需求發起者最開始只有一個想法，但是由於他們的專業知識不足，表達不出他們的核心需求所在，大多聽到的是：“我要做一個電商，參考淘寶就行”“我要做一個社交產品，跟微博一樣就好。”這就好比小孩子要吃餅幹，媽媽說晚上不能吃餅幹，於是小孩哭鬧著找爸爸，結果爸爸給了片面包，小孩就停止哭鬧了。其實這個事例告訴我們，小朋友的真實需求是從餓到飽，而不是必須要吃餅幹，這在項目溝通中也是一樣的，所以我們要註意傾聽和進行引導式溝通。這裏首先要弄明白的是需求發起者的真實需求是什麽，其目的是了解他對該項目的認識、出發點，以及他對時間、人員配備的基本要求。
舉例來說：
我要做一個XX，參考XXX就行。
一般當遇到這種類型的需求發起者，我的第一個判斷就是他對這件事情的認知度不足，自己還沒有考慮清楚該怎麽做，還沒有找到自己的目標用戶和定位好需求的應用場景。在這種情況下，我會強調“參考是手段，不是目的”，我們做的產品是需要考慮用戶痛點、使用場景和邏輯的，然後讓需求發起者完整的講述自己的需求，隨後發現問題、潛在需求點，以及他的出發點和滿足的方向。
那在溝通時應該怎麽做呢？我通常會問需求發起者這樣幾個問題：
1、目前的業務方向是什麽樣的？為什麽要做這件事情？
2、你的用戶是誰？他們有什麽問題？我們將準備通過什麽樣的方式來解決？
3、你想做什麽類型的產品APP、小程序、H5還是其他？
4、需要我們做哪些事情，產品規劃咨詢設計、技術開發還是其他？
5、對時間上有什麽要求？對人員上有什麽要求？
下面以某高端奢飾品電商客戶（下面簡稱甲方）為例來說：
甲方：我們是做高端奢飾品電商網站的，現在想要委托你們開發一款移動端的產品，有用戶下單購買，加入購物車，在線客服答疑就好了，跟淘寶差不多，參考淘寶就好了。
我：目前公司的業務方向是奢飾品這一領域的嗎？（行業背景）現在是準備做一個移動端產品開拓新的用戶渠道嗎？
甲方：是的。
我：主要是哪個方向的？皮包衣服？首飾珠寶還是名表古典？（業務方向）
甲方：都有。
我：現有的用戶分布在哪裏？購買頻率是什麽呀？（用戶群體）
甲方：這個不好透露。
我：抱歉，那準備做什麽類型的產品，APP，小程序還是公眾號？（產品類型）
甲方：做一個APP。
我：為什麽考慮要做APP而不是小程序或者公眾號呢？（追問需求動機）
甲方：有什麽區別嗎？
我：APP適合用戶群體比較穩定，業務模式得到驗證，且運轉良好的企業；小程序適合新產品或新功能驗證，一般用於收集和沈澱用戶數據；公眾號適合既有粉絲轉化、用戶量級較輕、功能不復雜的產品，且可以更加貼近微信用戶，方便運營增長。
甲方：感覺公眾號比較適合，現在我們公眾號上有幾萬粉絲，這幾萬粉絲可以在線消費，然後再拉動新的消費用戶進來。（核心目的）
我：對時間上有什麽要求或節點？（時間標準）
甲方：越快越好。
我：有沒有具體的節點，趕在什麽時間之前上線或配合某個活動？（時間標準）
甲方：3個月內吧，趕在7月之前。通過溝通我們可以發現，以上每個問題針對的方向都不一樣，需要靈活使用，但是它們都圍繞著一個核心，那就是搞清楚需求發起者對需求認知程度和訴求。
在產品經理實際操盤項目中該階段叫需求收集，實際中需求收集的來源除了以上的方式之外，比較常見的還有4個，分別是：用戶反饋、市場反饋、內部討論和公司發展需要。
2、需求到功能
到了該階段，我們對於需求發起者的需求認知程度和訴求建立起了感知，接下來需要延伸到每個需求對應的解決功能上。有的需求1個小功能就能滿足，但是有的需求可能需要4-5個大功能來進行滿足。
例一——
需求：收集用戶手機號
功能：手機號驗證碼註冊/綁定
實現收集用戶手機號這個功能只需要接入第三方的短信平臺然後連同數據庫進行驗證就可以實現，但是下邊這個需求就需要幾個大功能才能滿足。
例二——
需求：用戶可以進行打賞和提現
功能：打賞規則、在線支付、訂單處理、賬戶中心、消息提醒、財務處理邏輯等等。這種需求，就需要一整套的功能來進行滿足。用戶打賞充值、進行在線支付，在線支付還需要接入第三方支付，接入第三方支付的時候會涉及簽名、數據聯調，支付訂單的狀態處理，可能還會涉及是否可以進行退款，打賞成功之後被打賞對象的消息提醒，賬戶中心顯示余額，以及提現，包括後臺運營人員進行提現審核，審核之後消息提醒等等。
那到了這個階段應該怎麽溝通呢？我們的對話繼續。
我：3個月時間，想做一個好產品難度還是很大的，這個版本需要滿足的核心需求功能點都有哪些？（功能思路）
甲方：可以讓用戶進行註冊購買就好了。
我：註冊購買這個功能比較明確了，註冊登錄功能就能滿足，但是購買這個需求概念有點大需要詳細的說下。（關鍵功能）
甲方：用戶進入首頁之後能查看商品，然後在商品頁進行下單購買，我們接單後安排郵寄或派送。
我：根據這個流程相對應的功能就是首頁、商品列表頁/詳情頁、支付、訂單狀態/處理、郵寄信息錄入對嗎？（完善思路）
甲方：基本就是這樣。
我：那是不是還需要個人中心？記錄用戶的購買行為，訂單追蹤、賬單等。（完善思路）
甲方：肯定需要。
我：關於運營策略本次版本需要考慮嗎？例如推薦商品、客服等。（追問需求）
甲方：肯定需要。
我：這些是需要運營人員做強運營的，我們目前有相關的數據和運營團隊嗎？（風險預警）
甲方：目前還沒有，但是肯定需要的。
我：需要在7月上線，這幾個功能還是比較復雜的，並且我們本次版本的核心目的是把購買主流程跑通，然後轉化既有粉絲和收集數據，所以我建議其他功能優先級可以先降低，放到後續版本進行，你覺得怎麽樣？（聚焦核心需求）
甲方：嗯，也對，那就先做主流程的功能吧，等有了數據和運營團隊再考慮這個。
所以在該階段進行提問的時候就需要盡可能圍繞著這樣幾個點進行：需求發起人對該需求的考慮深度，他是否考慮清楚需求的復雜程度和可實現程度。然後我們需要結合時間、版本目標來進行評估，進行需求優先級排序，定義那些是核心需求，那些是非核心需求，避免由於非核心需求造成的對資源上的占用（時間、金錢、人員等）。
在產品經理實際操盤項目中，該階段叫需求規劃，需要定義需求優先級，在內部評審需求的可實現度、進行版本叠代規劃等，這些一般由產品總監、業務負責人等來制定，因為涉及到公司的運營方向和資源調配程度。
3、功能到業務邏輯（進階）
該階段的問題大多數產品顧問會忽略掉或者因需求發起人的專業度不足而無法進行詳細解答。因為該階段對於產品規劃、技術實現和運營等專業技能要求較高，所以我將其定義為進階階段。在該階段如果需求發起人的專業能力足夠，提問者的主要提問點需要圍繞功能使用流程來進行，把自己假設為一個使用者，根據需求發起人的設計思路進行體驗，並提問。如果需求發起人專業能力不足則引導需求發起者細化業務邏輯，具象化產品的邏輯。所以在該階段溝通時，我們需要關註這樣幾個問題：
1、登錄功能的使用流程是什麽樣的？
2、購買功能的使用流程是什麽樣的？
3、能否進行退款？怎麽退款，原路返回還是退回到賬戶？
4、發布動態的流程是什麽樣的？都有那些操作？
還是以我們的對話為例來說：
我：關於註冊登錄有沒有更加細節的考慮？例如使用的流程。（簡單功能引導）
甲方：就是可以通過手機號進行註冊和登錄，沒別的，跟現在一樣的就行。
我：是手機短信驗證碼登錄對嗎？（核對細節）
甲方：對的。
我：需要加上登錄密碼嗎？因為涉及到大額支付和個人隱私，加上登錄密碼可以提高賬戶的安全性。（完善功能邏輯）
甲方：肯定需要。
我：產品的用戶購買流程是進入首頁-查看商品-選擇商品-支付購買-公司發貨-商家確認收貨對嗎？（確認使用邏輯）
甲方：嗯，基本就這樣。
我：是否能否進行退款？退款的流程是什麽樣的，原路返回還是返回到賬戶？（完善功能邏輯）
甲方：要退款，有什麽區別嗎？
我：原路返回是直接結算到用戶支付的銀行卡或支付寶、微信中，返回賬戶是退款到產品的使用賬戶中。
甲方：都要，到時候看情況使用。
我：初期訂單量不是很大，建議初期人工介入，發生退款的時候進行人工審核，然後原路退回，這樣用戶體驗更好。（完善功能）
甲方：行，這樣也行。
該階段在產品經理實際操盤項目中叫功能規劃，該階段是需要根據需求規劃確認後對應的功能進行實際的規劃產出，需要考慮用戶類型、功能的處理邏輯、功能使用流程、使用規則、信息/狀態變更、數據加載狀態、異常狀態等等。
4、業務邏輯到框架
該階段是最容易進入誤區的，因為很多提問者對整個產品的需求、業務、用戶、核心邏輯都不了解，只提關於交互、頁面展示效果的問題，事實上交互和頁面展示效果是UI設計師來進行把控的，在與需求發起者溝通的時候並不需要考慮這些細節，而提問者最應該關心的是頁面展示內容問題，因此，在該階段提問者只需要圍繞著頁面布局內容來進行提問就可以了。
該階段需要關心的問題有這樣幾個：
1、商品展示的詳情頁都有那些內容？
2、動態列表都要展示那些內容？詳情頁需要展示那些內容？
3、首頁都需要那些板塊？
舉例來說：
我：關於產品的首頁板塊有什麽參考產品或思路？（簡單引導）
甲方：就跟淘寶一樣就行。
我：淘寶的量級比較大，不是我們產品很好的參考對象。我們的用戶群相對來說比較高端，領域比較垂直，所以我建議首頁板塊以快速高效為主，有輪播圖、商品基本分類、熱推商品、搜索等功能就可以滿足用戶快速找到產品的目標了，您覺得呢？（完善框架）
甲方：嗯，基本這些就行。
我：商品列表頁和詳情頁的內容有什麽考慮或者必須要展示的內容？（追問細節）
甲方：有商品的基本信息就好，縮略圖、標題、價格、折扣價這些，詳情頁加上產品介紹、評價就好了。
我：評價？剛剛沒有聽到評價，對評價這個功能是怎麽考慮的？（新功能！）
甲方：很基礎的功能啊，每個購物平臺都需要的啊。
我：評價這個功能的使用邏輯是什麽樣的呢？例如可以對所有的商品進行評分式評價、星星式評價、滑動式評價以及文字、配圖等。（追問細節）
甲方：就按照淘寶就行，照搬淘寶。
我：淘寶的評價是淘寶的生命線，他們背後有一套特別精細的算法控制，和很多個維度相關聯，您是指淘寶的評價使用起來的感覺對吧？（詢問真實需求）
甲方：對的
（以下省略…… ）
其實，這4個階段並不是千篇一律的，而是需要來回穿插使用的，可能在某一個階段需求發起人會說出一個新的需求，圍繞著新的需求就需要進行重復提問，就像最後的評價，在初期雙方都忽視了這個功能，在後邊的聊天過程中突然被提了出來，那麽這就需要圍繞著該功能進行追問，直到雙方對該功能認知清晰為止。
總結這一階段來說，在產品經理實際操盤項目中該階段叫功能設計，也叫產出階段，需 畫原型寫需求文檔，該階段結束之後，產品的整個Demo基本已經完成，然後進入講解評審，評審通過後交付給UI設計師，進入設計階段。
以上就是關於如何快速獲取和了解客戶的真實需求，並確保信息的完整度、準確度的4個階段提問法，每一個階段的問題都是產品經理在實際的工作中需要溝通清楚的，這也是我一直使用的方法，希望對你能有所幫助。
做完100+外包項目後，我用4維度提問法搞定產品需求