只有做好需求調研，才能在立項時從容的應對各種疑問。

比如該需求要為誰解決什么問題？為什么你的需求比別人重要？需求要達到什么目的？……需求調研不足將導致產品脫離實際業(yè)務需求，造成開發(fā)資源的浪費和產品方向的偏差。

本人將需求調研整理為三階段，即需求搜集-需求挖掘-需求評估，并說明每個階段的工作思路。

注：公司產品為c2m服裝定制平臺，以下將結合實際工作經(jīng)驗及對產品的理解整理，僅供參考。

需求搜集

定義：無論是全新業(yè)務的探索還是已有業(yè)務的優(yōu)化方案，都存在業(yè)務述求，因此需求搜集可以理解為向用戶搜集業(yè)務述求。

渠道：用戶主動通過某個渠道表達對產品使用的不滿及建議。像微博吐槽，APP評價，在線客服，產品反饋入口等方式會更適合C端用戶。而B端用戶（或公司內部用戶），會直接向上級或產品經(jīng)理反饋業(yè)務述求。

原則：

• 接近業(yè)務。產品經(jīng)理未收到業(yè)務反饋往往不是意味著產品沒有缺點并滿足用戶的所有需求，而是產品未同用戶建立良好的需求溝通機制導致。用戶由于思維慣性，不會主動提出業(yè)務述求。其原因可能包括：不認為當下的操作行為有何不妥；認為即使提出業(yè)務述求也得不到有效解決。此時需要產品經(jīng)理去接近用戶，比如說業(yè)務輪崗，種子用戶訪談，數(shù)據(jù)漏斗分析等。
• 傾聽和理解。理論上所有的業(yè)務抱怨都可能提煉成一個需求，不要以自己對產品的熟悉程度去質疑用戶的各種操作失誤；既然這是你的用戶，用戶會犯錯，用戶會抱怨，這即使產品需優(yōu)化的點。因此首先要端正自己的態(tài)度，正視業(yè)務問題，才會有去改進的動力。
• 及時反饋。為了提高業(yè)務部門反饋的積極性，對于述求方給出回復時間點及回復結果：轉化成需求/大致完成時間，需求拒絕/拒絕理由。
• 有針對性。往往用戶在描述問題時容易發(fā)散，沒有方向，導致搜集了很多問題，但同需調研的需求本身有偏差。因此，針對有目的性的需求，產品經(jīng)理對產品的框架有事先的認知，帶有問題去咨詢用戶。比如，要做進銷存的功能，產品經(jīng)理要事先對進銷存有基本的產品框架，集中同用戶討論采購入庫，調撥，盤點等業(yè)務場景。

需求挖掘

定義

將業(yè)務述求整理成需求池，即場景-用戶-問題點（目標）-建議解決方案。

• 場景：所有的用戶行為都必須具化到場景，需求場景描述要盡可能的詳細，這樣才有利于產品設計。曾經(jīng)看到地鐵廣告，公眾號二維碼置于海報中下區(qū)域，也就是用戶要蹲下來才能掃到二維碼。如果需求挖掘時有考慮到用戶掃描二維碼的場景，產品設計就會考慮二維碼的位置。
• 用戶：你要清楚你為誰設計產品，不同的用戶產品設計思路是不一樣的。工廠操作員害怕出錯，因此產品設計可以側重強提示，二次復核，傻瓜式操作等避免出錯；女生害怕計算，因此產品設計可以將口算的部分轉為系統(tǒng)自動計算；特別是C端產品更要考慮用戶畫像，本文就不再展開。
• 問題點：所有的需求是為了解決業(yè)務問題。功能上線后未解決業(yè)務問題，等于資源的浪費。解決業(yè)務問題即等同于需求目標，有利于確認需求的優(yōu)先級。因此羅列出問題點，作為產品設計依據(jù)。確認需求目標，可作為上線跟蹤的依據(jù)。
• 建議解決方案：在同業(yè)務端溝通時，可能會得出初步的建議解決方案。參考該信息有利于產品設計是符合用戶需求的。

原則

別把解決方案當需求

很多時候，用戶給我們講出來的想法和要求，根本不是他們的“需求”，而是他們的一種“想要”?！靶枨蟆笔怯脩糇罡镜拇鉀Q的問題，而“想要”只是用戶已經(jīng)幫我們想好的一些解決“需求”的辦法而已，在需求調研過程中，務必要挖掘到用戶的“需求”，通過我們的設計去實現(xiàn)用戶的“需求”，而不是盲目的跟從用戶的“想要”，結果被用戶帶到了溝里出不來。

不斷問為什么

需求挖掘比較考驗產品經(jīng)理專業(yè)業(yè)務能力和事物抽象化，比如工廠的說想喝可樂，其用戶需求1是解渴，需求2表達我很酷。在用戶所在環(huán)境，喝可樂是財力和酷的表現(xiàn)，而水卻被打上廉價標簽。挖掘更直觀的表達方式是不斷的問為什么，為什么想喝可樂；為什么是可樂；每個業(yè)務點去問到最后的為什么，也能收集你想挖掘的點。

需求評估

定義：在判斷是真實需求的前提下，需求優(yōu)先級如何。

一般的偽需求在需求挖掘環(huán)節(jié)不斷問為什么，能得到答案。在認定是真實需求時，一般采用重要性和緊急性兩個維度考慮。

• 重要：公司戰(zhàn)略；增加營收；降低成本；信息泄露；產品基礎模塊，比如電商的支付，訂單，商品，庫存，發(fā)貨等模塊等。
• 緊急：投訴風險；資金結算；大面積影響用戶等。

注：不同階段，公司對重要和緊急的領域可能會有差異，要視情況而定。比如說，公司初期增加營收，拉新等是重要的，而公司中期，降低成本，隱私泄露又開始被重視。

兩個維度組合如下：

• 重要&緊急：如果這類需求多，需反思是否產品框架有問題，產品基礎建設欠缺。
• 重要&不緊急：要聚焦于這類需求，代表產品的未來，拆分版本逐步迭代，穩(wěn)扎穩(wěn)打。
• 不重要&緊急：往往是臨時解決方案，往往對產品沒有質的提升。需要反思是過去產品迭代的問題。
• 不重要&不緊急：盡可能的不做

在大部分情況下，需求和開發(fā)資源是呈現(xiàn)狼多肉少的局面。

因此做好需求的優(yōu)先級，合理利用有限的開發(fā)資源，是考驗產品經(jīng)理能力的一大指標。

本文由 @小余同學 原創(chuàng)發(fā)布于人人都是產品經(jīng)理，未經(jīng)許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協(xié)議