需求管理的兩個維度:需求來源管理和需求實現管理

產品經理在平時的工作中有一大部分工作都是在「為客人點菜」——需求管理。

一個流傳較廣的段子，形象地描述了產品經理的角色：

你去飯店，坐下來。

你：服務員，給我來份宮保雞丁！

服務員：好嘞！

【這叫原始需求。】

 

大廚做到一半。

你：服務員，菜裡不要放肉。

服務員：不放肉怎麼做啊？

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

服務員：好的，您稍等。

【這叫中途需求變更。】

 

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

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

大廚：行，你大爺~

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

【改動太大，部分重構。】

 

你：服務員，菜裡能給我加點腐竹嗎？

服務員：行，這個應該簡單。

【低估改動成本】

 

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

服務員：啊，你怎麼不早說？

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

然而還是去泡腐竹了。

【新需求引入了新研發成本】

 

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

服務員：好好好，您稍等，您稍等……

【奇葩需求】

 

大廚：宮保雞丁裡放茄丁？？

服務員：茄丁抄好了扔裡邊不就行了嗎」

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

服務員：客戶要，你就給炒了吧。

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

【奇葩需求也得實現】

 

10分鐘後

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

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

【最終決戰】

 

以上的人物：

• 你 = 客戶
• 服務員 = 客戶經理 + 產品經理
• 大廚 = 碼農

產品經理在平時的工作中有一大部分工作都是在「為客人點菜」——需求管理。

為了避免發生上述的災難性案例，作為一個合格的產品經理，需要分析客戶需求並根據團隊的能力給出恰當的產品解決方案。這就需要產品經理做好需求的管理。

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

1. 需求的來源管理：如何挖掘需求，哪些需求值得去做，需求有哪些分類
2. 需求的實現管理：mvp內容如何規劃，如何做好優先級排期，臨時需求怎麼處理等

需求的來源管理

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

合格的產品經理對話應該是這樣的：

你去飯店，坐下來。

你：服務員，給我來份宮保雞丁！

服務員：好的，請問有什麼忌口嗎？

 

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

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

 

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

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

 

你：這樣也行。

服務員：還有其他想吃的嗎？

 

你：我還喜歡吃腐竹。

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

 

你：好，那快點上菜吧。

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

1、馬斯洛需求理論

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

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

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

五類需求是以層次的形式出現的，由低級的需要開始，逐級向上發展到高級層次的需要。當低層次需求得不到滿足時，高層次需求也會處於不穩定的狀態，比如食物缺乏時，會不顧一切手段搶奪食物。

（圖片來源：維基百科）

一般而言，越是底層的需求，用戶量越大，比如滿足生理需求的美食類app，外賣app, 滴滴打車。越是高層的需求，新鮮感越多。比如滿足歸屬感的社交app，自我實現需求的音樂類App等。當然在網際網路時代，需求的分類界限也越來越模糊，wifi萬能鑰匙可以說滿足了多數人基礎的生理需求。

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

2、需求的來源

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

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

外部來源

前期對用戶的研究，調查問卷，訪談發現新的產品需求。來飯店吃飯，肯定是餓了，需求是填飽肚子，這裡的用戶問卷就是問你要吃什麼。

用戶反饋的收集，提取和優化策略。用戶說菜太鹹，上菜太慢，提前做好備菜。

對競品的跟蹤分析，行業分析等等。 隔壁家開發出不要肉的宮保雞丁，派人學習一下。

內部來源

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

數據分析產生的需求，根據前期數據埋點獲得數據做產品的優化。大部分客戶都喜歡吃宮保茄丁，菜單上就增加一個宮保茄丁。

業務部門需求。簡單的比如需要市場部門需要更換品牌，改個圖標。收銀臺發現宮保茄丁利潤率更高，我們要主推宮保茄丁。

技術部門的需求，某個方案現有技術來實現比較複雜，需要更改需求。大廚發現茄子切丁太費事，改成宮保茄條。

3、用戶需要的並不全是產品需求，用戶的動機才是需求的本質

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

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

區別偽需求和表面需求

關於偽需求被引用最多的一個例子，便是福特汽車創始人說的一句話：

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

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

問個問題

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

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

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

需求的實現管理

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

理論先行。

1、KANO模型分析法

需求的優先級首先應該根據需求對用戶的價值來判斷。

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

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

毫無疑問，產品經理應該避免去實現無差異因素和反向因素。

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

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

（需求進展和用戶滿意度的關係圖，來源：維基百科）

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

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

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

實現優先級上，首先滿足基本需求，其次是期望型需求，然後根據產品的生命周期和市場情況，調整興奮型需求的優先級。

比如，在產品成長期，可以恰當做些爆點需求，增加曝光度，來快速拉升產品註冊人數。

2、分段交付產品功能，MVP實現核心需求

MVP最小可行產品

網際網路迭代越來越快，爆發出來的很多需求需要快速驗證，這個時候做一個快速的可行性產品是成本最低的試錯方法。

一般來說，MVP產品可以從以下幾個緯度確定功能範圍：

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

現在，很多的硬體創業團隊mvp做法則是設計好了方案，到眾籌網站進行展示，收集產品反饋，獲得早期用戶，快速判斷產品是否符合市場需要。

按照產品需求的優先級分段交付：

現在的網際網路產品思維都要求快速迭代，並不像傳統的軟體產品，需要所有功能完備才能推向市場。

分段交付可以理解為後續每一個迭代都是一個mvp，只不過跟從0啟動的產品mvp判斷標準不同，按照需求優先級來定義每一次分段交付的內容。

分段交付的優點有很多，也是scrum開發模式推薦的做法：

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

評估產品優先級除了上面提到的用戶價值模型還可以從一下幾個方面評估：

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

假設我們仍然接受了客戶的需求，不考慮商業價值虧損的情況下，需要做一份加腐竹的宮保雞丁，滿足的只是個別用戶的單次需求。而且實現成本又很高，所以這個需求從優先級上是非常低的。所以，不如先上個涼拌腐竹，再做個宮保茄丁。

 

作者：胡瑩（點融黑幫），現任點融網高級產品經理，畢業於復旦大學，喜歡推理，殺人遊戲，德州撲克。

本文由@點融黑幫（ID：DianrongMafia）原創發布於人人都是產品經理，未經許可，禁止轉載。