產(chǎn)品經(jīng)理在平時的工作中有一大部分工作都是在“為客人點菜”——需求管理。

一個流傳較廣的段子，形象地描述了產(chǎn)品經(jīng)理的角色：

你去飯店，坐下來。

你：服務(wù)員，給我來份宮保雞?。?/p>

服務(wù)員：好嘞！

【這叫原始需求?！?/p>

 

大廚做到一半。

你：服務(wù)員，菜里不要放肉。

服務(wù)員：不放肉怎么做?。?/p>

你：不放肉就行了，其它按正常程序做，不就行了，難嗎？

服務(wù)員：好的，您稍等。

【這叫中途需求變更?！?/p>

 

大廚：你大爺，我肉都回鍋了。

服務(wù)員：顧客非要要求的嘛，你把肉挑出來不就行了嗎？

大廚：行，你大爺~

然而還是一點點挑出來了。

【改動太大，部分重構(gòu)?！?/p>

 

你：服務(wù)員，菜里能給我加點腐竹嗎？

服務(wù)員：行，這個應(yīng)該簡單。

【低估改動成本】

 

大廚：不知道腐竹得提前泡水？炒到一半才說？跟他說，想吃腐竹就多等半天。

服務(wù)員：啊，你怎么不早說？

大廚：我怎么知道他要往宮保雞丁里放腐竹。

然而還是去泡腐竹了。

【新需求引入了新研發(fā)成本】

 

你：服務(wù)員，菜里加茄丁了沒有？我去其它飯店吃可都是有茄丁的。

服務(wù)員：好好好，您稍等，您稍等……

【奇葩需求】

 

大廚：宮保雞丁里放茄??？？

服務(wù)員：茄丁抄好了扔里邊不就行了嗎”

大廚：那TM還能叫菜嗎？哪個系的？

服務(wù)員：客戶要，你就給炒了吧。

大廚：你順道問問他腐竹還要不要，我這盆腐竹還占著地方呢！不要我就扔了。

【奇葩需求也得實現(xiàn)】

 

10分鐘后

你：咦，我上次吃的不是這個味??？

從廚房殺出來的大廚：我*****

【最終決戰(zhàn)】

 

以上的人物：

• 你 = 客戶
• 服務(wù)員 = 客戶經(jīng)理 + 產(chǎn)品經(jīng)理
• 大廚 = 碼農(nóng)

產(chǎn)品經(jīng)理在平時的工作中有一大部分工作都是在“為客人點菜”——需求管理。

為了避免發(fā)生上述的災(zāi)難性案例，作為一個合格的產(chǎn)品經(jīng)理，需要分析客戶需求并根據(jù)團隊的能力給出恰當(dāng)?shù)漠a(chǎn)品解決方案。這就需要產(chǎn)品經(jīng)理做好需求的管理。

需求管理分為兩個方面：需求從哪里來，需求到哪里去了。

1. 需求的來源管理：如何挖掘需求，哪些需求值得去做，需求有哪些分類
2. 需求的實現(xiàn)管理：mvp內(nèi)容如何規(guī)劃，如何做好優(yōu)先級排期，臨時需求怎么處理等

需求的來源管理

在上述案例中，原始需求就有很大的問題，原始需求直接作為開發(fā)需求來做，必然會導(dǎo)致項目失敗。

合格的產(chǎn)品經(jīng)理對話應(yīng)該是這樣的：

你去飯店，坐下來。

你：服務(wù)員，給我來份宮保雞??！

服務(wù)員：好的，請問有什么忌口嗎？

 

你：有，最近在減肥，不要放肉。

服務(wù)員：這宮保雞丁不放肉的話可就不是宮保雞丁了。

 

你：但我喜歡吃宮保雞丁，所以請你們給我炒一道沒有肉的宮保雞丁。

服務(wù)員：你看這樣行不行，我們可以用茄丁來代替雞丁，味道差別不大，并且更健康。

 

你：這樣也行。

服務(wù)員：還有其他想吃的嗎？

 

你：我還喜歡吃腐竹。

服務(wù)員：好的，我們這有涼拌腐竹，上菜速度快，可以先給您先上一份。

 

你：好，那快點上菜吧。

可以看到，分析清楚客戶的真實需求，再進入開發(fā)階段，客戶吃到了腐竹，茄丁，和宮保雞丁的味道，廚房也能正常的干活，是個雙贏的結(jié)果。

1、馬斯洛需求理論

任何一個產(chǎn)品需求都是基于人類本身的訴求產(chǎn)生的，回答需求從哪里來的問題，不得不提到馬斯洛需求理論。

馬斯洛于1943年在《人類動機的理論》論文中將需求分為五類（引自維基百科）：

• 生理上的需求：級別最低、最急迫的需要，如：食物、水、空氣
• 安全上的需求：低級別的需要 ?如：對人身安全、生活穩(wěn)定以及免遭痛苦、威脅、擁有財產(chǎn)等
• 情感和歸屬的需求：社交需求，對友誼、愛情以及隸屬關(guān)系的需求
• 尊重的需求：較高層次的需要，如：成就、名聲、地位和晉升機會
• 自我實現(xiàn)的需求：最高層次的需要，初級表現(xiàn)形式是認(rèn)知和審美的需求 如：自我實現(xiàn)，發(fā)揮潛能

五類需求是以層次的形式出現(xiàn)的，由低級的需要開始，逐級向上發(fā)展到高級層次的需要。當(dāng)?shù)蛯哟涡枨蟮貌坏綕M足時，高層次需求也會處于不穩(wěn)定的狀態(tài)，比如食物缺乏時，會不顧一切手段搶奪食物。

（圖片來源：維基百科）

一般而言，越是底層的需求，用戶量越大，比如滿足生理需求的美食類app，外賣app, 滴滴打車。越是高層的需求，新鮮感越多。比如滿足歸屬感的社交app，自我實現(xiàn)需求的音樂類App等。當(dāng)然在互聯(lián)網(wǎng)時代，需求的分類界限也越來越模糊，wifi萬能鑰匙可以說滿足了多數(shù)人基礎(chǔ)的生理需求。

回到上面的案例，滿足生理需求是給一碗飯，滿足安全需求是保證食品安全，滿足歸屬需求是老客戶8折，滿足尊重需求是盡力滿足沒有肉還能吃出宮保雞丁的味道。自我實現(xiàn)的需求？對不起，飯店這個產(chǎn)品難以滿足，想做出一個優(yōu)秀的產(chǎn)品，一定是深諳人性，需要區(qū)分清楚人類表面需求及潛在需求，并且能夠持續(xù)穩(wěn)定的產(chǎn)生用戶粘性。

2、需求的來源

一個產(chǎn)品需求，必然是滿足人性的某一個訴求才值得去做，也就是產(chǎn)品必須有價值才有存在的意義。

獲得有價值的需求來源，也可以大致分為兩類：

外部來源

前期對用戶的研究，調(diào)查問卷，訪談發(fā)現(xiàn)新的產(chǎn)品需求。來飯店吃飯，肯定是餓了，需求是填飽肚子，這里的用戶問卷就是問你要吃什么。

用戶反饋的收集，提取和優(yōu)化策略。用戶說菜太咸，上菜太慢，提前做好備菜。

對競品的跟蹤分析，行業(yè)分析等等。 隔壁家開發(fā)出不要肉的宮保雞丁，派人學(xué)習(xí)一下。

內(nèi)部來源

老板的需求，一個公司的內(nèi)部或多或少都會有來自上級的需求，靠譜的老板掌握的資源和市場信息能夠做出正確的判斷，決定產(chǎn)品的方向。比如老板覺得中餐太麻煩競爭激烈，我們需要開發(fā)標(biāo)準(zhǔn)化的西餐，做蛋糕。

數(shù)據(jù)分析產(chǎn)生的需求，根據(jù)前期數(shù)據(jù)埋點獲得數(shù)據(jù)做產(chǎn)品的優(yōu)化。大部分客戶都喜歡吃宮保茄丁，菜單上就增加一個宮保茄丁。

業(yè)務(wù)部門需求。簡單的比如需要市場部門需要更換品牌，改個圖標(biāo)。收銀臺發(fā)現(xiàn)宮保茄丁利潤率更高，我們要主推宮保茄丁。

技術(shù)部門的需求，某個方案現(xiàn)有技術(shù)來實現(xiàn)比較復(fù)雜，需要更改需求。大廚發(fā)現(xiàn)茄子切丁太費事，改成宮保茄條。

3、用戶需要的并不全是產(chǎn)品需求，用戶的動機才是需求的本質(zhì)

任何一個需求來源的用戶提出的需求都可能是偽需求，討論需求來源時我們直接默認(rèn)了需求是合理的并且真實的。

舉個例子：宮保雞丁這個菜本來就是要肉的，如果要吃茄子，就是另外一道菜了。

區(qū)別偽需求和表面需求

關(guān)于偽需求被引用最多的一個例子，便是福特汽車創(chuàng)始人說的一句話：

如果聽用戶的，我們根本造不出汽車來，用戶就是需要一匹快馬。

用戶基于自己的環(huán)境和使用習(xí)慣很難跳出原有的思維方式，當(dāng)用戶直接提出解決方案的時候，往往意味著誕生了又一個“偽需求”。因為他們所指的方向并不一定能到他們所想去的地方。還有一類需求，用戶會用某種行為來代替真實的需求，比如開房去學(xué)習(xí)，如果把賓館都改成自習(xí)室，也就沒有人去學(xué)習(xí)了。再比如用戶說需要一個錐子和釘子，其實他只是要把畫掛起來。

問個問題

去偽存真的一個簡單方法就是問個問題，你是誰？你想做什么？需要達成目的？即一個需求的用戶角色定義是什么，基于什么樣的用戶場景，能夠帶來什么樣的價值。

一個餓了的客戶，只想吃飽肚子，給他一份宮保雞丁滿足需求。另外一個特別喜歡吃宮保雞丁的客戶，最近在減肥，處理的方法就完全不一樣了。再有上面的福特汽車?yán)?，如果客戶是個賽馬選手，他當(dāng)然是需要更快的馬。如果是個普通用戶想更快更安全的到達另外一個地方，汽車是個很好的解決方案。

實際上，這個問法也是scrum團隊中用戶故事的寫法，作為一個角色，我想要活動,，以便于商業(yè)價值，基于這些分析出場景中用戶的動機，然后轉(zhuǎn)換為產(chǎn)品語言，接下來就是需求的實現(xiàn)過程了。

需求的實現(xiàn)管理

我們已經(jīng)了解到了客戶的需求：客戶想吃腐竹，帶茄丁不帶肉的宮保雞丁，那么如何操作，先做哪個？

理論先行。

1、KANO模型分析法

需求的優(yōu)先級首先應(yīng)該根據(jù)需求對用戶的價值來判斷。

日本教授狩野紀(jì)昭在1984年提出構(gòu)了KANO模型，用來對客戶需求的滿意度進行分類，一共分為五類影響因素（引自維基百科）：

• 必備因素：滿足基礎(chǔ)需求時，用戶才會使用產(chǎn)品，不會對用戶滿意度產(chǎn)生影響。當(dāng)不提供此需求，用戶滿意度會大幅降低；
• 期望因素（線性因素）：KANO模型是從線性需求模型演變而來，線性需求在產(chǎn)品中實現(xiàn)的越多，用戶就越滿意，當(dāng)不提供此需求，用戶滿意度會降低；
• 興奮因素：用戶意想不到的，如果不提供此需求，用戶滿意度不會降低，但當(dāng)提供此需求，用戶滿意度會有很大提升；
• 無差異因素：無論提供或不提供此需求，用戶根本不在意；
• 反向因素：用戶根本都沒有此需求，提供后用戶滿意度反而會下降。

毫無疑問，產(chǎn)品經(jīng)理應(yīng)該避免去實現(xiàn)無差異因素和反向因素。

有兩個反向因素的例子，豆瓣把自己的消息系統(tǒng)的名字由豆郵改成私信，僅僅是改個名字，結(jié)果遭到豆瓣用戶集體反對，不得不重新改回來。支付寶的六一運營活動，也是改名字，給大家的名字后面都加了個寶寶，不少在意安全的用戶，也把矛頭指向了產(chǎn)品經(jīng)理。這些站在用戶對面的反向需求，用戶必然會不滿意。

無差異因素則更加悲涼，這種需求很少出現(xiàn)，你費力做出個功能，結(jié)果用戶一點感知都沒有，某種意義上來說，比反向因素更加不值得浪費資源去做。

（需求進展和用戶滿意度的關(guān)系圖，來源：維基百科）

可以看到其中的三條曲線basic needs（基本型需求），performance needs（期望型需求），Delighters（興奮型需求）的實現(xiàn)過程。

• 基本型需求：產(chǎn)品的基本需求往往屬于此類。對于這類需求，必須滿足，可以做的按部就班，少量創(chuàng)新。
• 期望型需求：用戶、競爭對手和產(chǎn)品自身都需要關(guān)注的需求，平時工作中需要重點關(guān)注的需求。
• 興奮型需求：用戶自身都沒有想到的需求，滿足此類需求很容易引起產(chǎn)品的爆點。之前的臉萌，朋友印象都是滿足這種興奮型需求。

做一份宮保雞丁屬于基本需求，想吃到腐竹是期望需求。而興奮型需求，則是類似海底撈的做法；等待的過程中給你提供刷鞋，美甲等更多的服務(wù)，給用戶帶來驚喜。

實現(xiàn)優(yōu)先級上，首先滿足基本需求，其次是期望型需求，然后根據(jù)產(chǎn)品的生命周期和市場情況，調(diào)整興奮型需求的優(yōu)先級。

比如，在產(chǎn)品成長期，可以恰當(dāng)做些爆點需求，增加曝光度，來快速拉升產(chǎn)品注冊人數(shù)。

2、分段交付產(chǎn)品功能，MVP實現(xiàn)核心需求

MVP最小可行產(chǎn)品

互聯(lián)網(wǎng)迭代越來越快，爆發(fā)出來的很多需求需要快速驗證，這個時候做一個快速的可行性產(chǎn)品是成本最低的試錯方法。

一般來說，MVP產(chǎn)品可以從以下幾個緯度確定功能范圍：

1. 用戶緯度：MVP集中滿足核心用戶/種子用戶的需求；
2. 功能緯度：找出最核心、與痛點最相關(guān)、最小的功能組合。減少需求永遠比增加需求更難。這里可以用反向分析法，如果去掉某個功能，會不會影響主體流程。某個需求如果上不了線，用戶會不會流失，如果回答是會，則放入mvp中實現(xiàn)，如果不會大膽的放到后續(xù)的迭代中做；
3. 產(chǎn)品原型：現(xiàn)在更多的產(chǎn)品會通過微信公眾號的形式驗證，比如知乎的付費問答值乎，最開始的mvp產(chǎn)品形態(tài)主要是知乎服務(wù)號的自定義菜單或者朋友圈的分享，如果一開始就放在App端，如果用戶沒有來得及更新，就錯失了市場機會（同一時間，分答已經(jīng)在市場上跑馬圈地了）。

現(xiàn)在，很多的硬件創(chuàng)業(yè)團隊mvp做法則是設(shè)計好了方案，到眾籌網(wǎng)站進行展示，收集產(chǎn)品反饋，獲得早期用戶，快速判斷產(chǎn)品是否符合市場需要。

按照產(chǎn)品需求的優(yōu)先級分段交付：

現(xiàn)在的互聯(lián)網(wǎng)產(chǎn)品思維都要求快速迭代，并不像傳統(tǒng)的軟件產(chǎn)品，需要所有功能完備才能推向市場。

分段交付可以理解為后續(xù)每一個迭代都是一個mvp，只不過跟從0啟動的產(chǎn)品mvp判斷標(biāo)準(zhǔn)不同，按照需求優(yōu)先級來定義每一次分段交付的內(nèi)容。

分段交付的優(yōu)點有很多，也是scrum開發(fā)模式推薦的做法：

• 新功能能夠快速發(fā)布；
• 能夠迅速應(yīng)對業(yè)務(wù)需求，擁抱變化；
• 迭代周期縮短，同時獲得迅速反饋；
• 從需求分析開始交互 設(shè)計 開發(fā) 測試等角色密切協(xié)作，相比于傳統(tǒng)的瀑布式開發(fā)，效率跟高，更少浪費。

評估產(chǎn)品優(yōu)先級除了上面提到的用戶價值模型還可以從一下幾個方面評估：

• 需求價值：用戶價值即上面KANO模型評估結(jié)果，基本需求優(yōu)先做，期望型需求盡量做，興奮型需求要有一兩個，作為產(chǎn)品亮點和差異化競爭策略需要。商業(yè)價值，是否對公司有利；
• 需求主體：是哪一類用戶的需求，是否是核心用戶，新用戶，還是留存用戶。受眾面是不是足夠大；
• 需求成本：需求實現(xiàn)的需要投入的技術(shù)資源和時間資源，以及是否依賴內(nèi)部外部的一些資源；
• 需求強度：用戶對該需求有多強烈，需求的頻率如何。

假設(shè)我們?nèi)匀唤邮芰丝蛻舻男枨?，不考慮商業(yè)價值虧損的情況下，需要做一份加腐竹的宮保雞丁，滿足的只是個別用戶的單次需求。而且實現(xiàn)成本又很高，所以這個需求從優(yōu)先級上是非常低的。所以，不如先上個涼拌腐竹，再做個宮保茄丁。

作者：胡瑩（點融黑幫），現(xiàn)任點融網(wǎng)高級產(chǎn)品經(jīng)理，畢業(yè)于復(fù)旦大學(xué)，喜歡推理，殺人游戲，德州撲克。

本文由@點融黑幫（ID：DianrongMafia）原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載。