很多產品同學在創(chuàng)業(yè)公司，可能因為話語權不夠，所以導致可能開發(fā)直接對接需求。但需要明確的是，產品一定是對接需求的。產品經理這個崗位存在的意義就是因為需求的存在。用戶需求不等同于系統(tǒng)需求，相信自己介入需求到開發(fā)中的價值。

一、好需求的定義

1.1 好需求的摸樣

調研需求之前，我們需要在內心有一個好需求的摸樣，可以遵循GPSPAC原則。

• Goal目標：為什么要去做這個事情？
• Process流程：達成目標所需要的組織協(xié)調方式；
• Scene場景：流程中所有可能出現(xiàn)的狀況（正常、異常）；
• Person人員：特定場景中涉及到的人/部門；
• Action行動：特定場景下的人進行的判斷和動作；
• Check檢查：對于人員所需要采取行動的檢查（非必選）；

有了一個“標準”的答案在心里了，那么你在紛繁復雜的業(yè)務中調研需求的時候，就不會被業(yè)務牽著鼻子走，你會順著你的標準來引導業(yè)務向你娓娓道來你想要的，去抓住GPSPAC。

二、獲取B端需求

獲取需求之前先明確需求的背景，明確需求的價值和厘清目前現(xiàn)在業(yè)務的現(xiàn)狀。更重要的是識別需求的真?zhèn)涡?，不要被用戶牽著鼻子走。不要只聽一面之詞，兼聽則明。

2.1 獲取需求

明確需求背景

需求背景是整個產品設計的前提，只有深刻了解背景里所存在的問題、及對應的用戶痛點，才能把握好產品的設計方向。同時只有大家都認可這個背景的真實、有效和價值，才能夠更好推進產品方案的落地。

一款产品无到有，产品经理需要做些什么？

在一个产品从无到有的过程中，要做好产品经理这个角色实在是不容易，除了大家都知道的写需求、写需求、写需求，要做的事多着呢。产品经理不是你眼中的只会找你麻烦，提要求..

查看详情 >

完整需求背景的一般包含三個部分：用戶、場景和需求。即用戶在什么樣的場景下，遇到什么樣的問題/或者對于當前的產品產生了怎樣的需要或者訴求。或者更深入一點，何人在何地，因為什么原因，用什么方法做了什么事情，做到什么程度/取得了什么結果。

5W1H具體指的是：

• 何因（Why）：原因
• 何事（What）：對象或什么事情
• 何地（Where）：地點
• 何時（When）：時間
• 何人（Who）：人員或責任人
• 何法（How）：方法或程序

此外，有的時候也會加入”多少”（How Many），用以進一步明確數(shù)量級和規(guī)模。這種方法鼓勵從原因、對象、地點、時間、人員和方法這六個方面對選定的項目、工序或操作提出問題進行深入思考。例如，公司生產什么產品？這個產品在哪里生產？為什么要生產這個產品？這些產品是什么時候生產的？這些產品是由誰來生產的？以及這些產品是如何生產的？等等。這種多角度的思考方式可以幫助我們更全面地理解一個問題或者情況，從而做出更加明智的決策。

在產品設計的時候，應該就用“用戶+場景+需求”的句式來反復確認，產品背景是否把握準確未偏離方向；向開發(fā)介紹的時候也應利用這種句式，邏輯清晰地向他們傳達出功能背后的價值。

厘清現(xiàn)狀

• 不解決誰會難受？
• 有多難受（最好有量化指標，比如：不做就要有多少人線下花費多少時間成本去做？錯誤率，風險等等）
• 多久難受一次（頻次)
• 目前的方案是怎么做的

明確需求價值

• 這個需求從哪產生的？
• 解決了什么問題？
• 我們目前的資源足以完成這個嗎？
• 這一塊業(yè)務中最痛的痛點是什么？
• 為什么過去沒做，未來不做，而是現(xiàn)在做？

注意：對于用戶我們只挖掘問題，不挖掘方案；

2.2 需求的價值

生產效率的思考角度

• 整體協(xié)同鏈路的效率提升 。(如報銷到放款時間降低，退款時間降低等，管理痛點）
• 單位生產資料的產出提升或單位產出的成本降低 。(如銷售訪客數(shù)的上升，一個客服接電話數(shù)的上升，操作痛點）
• 規(guī)?；聸Q策難度降低或準確率提升。(如數(shù)據報表，業(yè)務診斷，智能化工具等，決策痛點）

不同解決方案的不同價值定義

• 數(shù)字化：定性為主（定性如跑通流程，全鏈路可視）, 定量為捕（如反饋時效提升等）。
• 自動化：定性+定量，以定量為主。
• 智能化：必須定量。

定性：以完成特定的任務或動作為考核方式，如流程跑通，能夠看到數(shù)據等，主觀性強。

定量：以達成特定的數(shù)值為考核方式，如100萬gm,獲得100個新客等，客觀性強。

2.3 識破偽需求

真需求還是偽需求，want or need？

用英文就可以清晰地區(qū)分：偽需求叫 Want，真需求叫 Need。Want的東西用戶不一定會掏錢，Need 的東西用戶一定愿意掏錢。所以識別出 Need 的需求是需要優(yōu)先實現(xiàn)和滿足的，減少或者不做What需求。

要想獲得真需求，就要搞清楚用戶要通過產品達到什么樣的目的，產品經理需要跳脫既有的思維和主觀的判定，同時也不能輕信用戶直接反饋的解決方案，要不斷地問為什么，去挖掘背后真正的原因。對單個需求通?？梢詥栆韵聠栴}，識別出需求的不同，進而進行優(yōu)先級排序：

• 需求強度：用戶是否痛？有多痛？
• 需求頻次：多久痛一次？
• 持續(xù)時間：是否持續(xù)地痛？
• 廣度：有多少用戶有類似的痛點？
• 付費意愿：用戶為此痛點付費的意愿如何。

挖掘真需求的理論方法

• 挖掘需求的理論方法有很多，比如用戶調研、數(shù)據分析、競品分析等等。其中用戶調研包含核心用戶反饋、問卷法、訪談法、實地調研。
• 在分析客戶的需求的時候，要懂得無視他們想要的東西，去探究其內心真正的渴望，如此才能給出更好的解決方案，或者說是用戶真正需要的東西。

總結：

什么是“偽需求”？

• 缺乏充分的使用場景，看似有用實則沒有相應的適應場景；
• 可有可無，并不解決核心痛點的“增量需求”；

如何識別偽需求？

• 需求收集階段，不光聽用戶的說辭，要找到真實的使用場景、說辭背后的動機；
• 從動機入手設計解決方案，而不是拿用戶提出的“設計”直接作為解決方案；
• 原型階段，做用戶測試，傾聽用戶的使用感受；
• 重要功能，灰度上線/試點上線，避免集體翻車；

三、如何管理B端需求

3.1 需求優(yōu)先級的判斷

1.如何判斷項目的緊急程度？ 短期不做會不會死？

2.如何判斷項目的重要程度？”長期不做會不會死？

3.優(yōu)先級=(重要程度+緊急程度)/研發(fā)成本

4.是否影響到主流程的繼續(xù)運轉？如果沒有，那就可以有相對充裕的時間進行調研；

5.是否必須修復功能才能滿足業(yè)務需求？例如頁面的數(shù)據導出功能出問題，用戶無法導出數(shù)據，那么可以直接從數(shù)據庫中導出數(shù)據并提供給用戶，在這種情況下，主流程不受影響。

3.2 優(yōu)先級準則

1.高優(yōu)高價值：需求價值為先，即高價值的需求優(yōu)先做;

2.領導很關注：高層級及”大噪門”酌情考慮,即老板需求和高壓力的需求適度提高優(yōu)先級;

3.分配要合理：小中大需求合理調配，即保證資源充分利用的基礎下小中大需求齊頭并進（建議235或226的比例分配）；通常需求的價值與需求大小成正比；

4.各方要對齊：充分溝通，分配透明，即優(yōu)先級的安排需要與各方充分溝通，盡量達成一致，并且及時將進度與優(yōu)先級同步所有關聯(lián)方；

總之，需求優(yōu)先級的排布是一門藝術而不僅僅是技術。

3.3 需求池的管理

需求四象限時間管理法

P0重要緊急；

a.處理方法：立即去做；

b.飽和后果：壓力無限增大、危機；

c.原則：越少越好，很多第一象限的事情是因為他們在第二象限時沒有被很好的利用；

P1重要不緊急；

a.處理方法：有計劃去做；

b.飽和后果：忙碌但不盲目；

c.原則：集中精力處理，投資于第二象限，做好計劃，先緊后松；

P2不重要緊急；

a.處理方法：交給別人去做；

b.飽和后果：忙碌且盲目；

c.原則：放權給別人去做；

P3不重要不緊急;

a.處理方法：盡量不做；

b.飽和后果：浪費生命；

c原則：可當做調節(jié)身心，但是不能沉溺于這個象限；

P0需求量控制在不超過25%；

P1保持長期投入，每個迭代預留一定的資源（建議小于20%）；

注意：需求的優(yōu)先級不是一成不變的，每當有新需求的加入，或者業(yè)務的變化，同時伴隨著需求池的更新，更是對業(yè)務的再思考。

需求池需求的類型

1.功能改進類需求

2.體驗提升類需求

3.BUG修復類需求

4.新增功能類需求

5.其他需求

秉持寬進嚴出的準則

四、如何分析B端需求

第一步：業(yè)務部門、崗位及職責梳理。

第二步：業(yè)務流程梳理。

第三步：業(yè)務流程確認。

第四步：3W1H法則，系統(tǒng)功能點拆解。

第五步：系統(tǒng)流程圖的出具。

五、需求的交付和落地

理清邏輯并將邏輯準確無誤地同步到開發(fā)，是產品的基本工作,越復雜的需求越需要這樣。如果因為產品自身的局限性，擔心產品邏輯不是最理想方案或者可行性問題，那可以在方案完成前提前與開發(fā)leader/核心開發(fā)溝通。否則，讓開發(fā)對產品邏輯自由發(fā)揮，就是在為后面迭代或者后人埋坑。