在《如何成為一頭優(yōu)秀的服（產）務（品）員（汪）》中，以餐廳點菜為切入點贯钩，講解了產品經理對需求的來源管理募狂，在充分了解需求本質——用戶動機的情況下，接下來面臨的問題便是角雷，如何實（做）現(xiàn)（菜）祸穷？
需求的實現(xiàn)管理
我們已經了解到了客戶的需求：客戶想吃腐竹，帶茄丁不帶肉的宮保雞丁勺三，那么如何操作雷滚，先做哪個？
理論先行吗坚。
1祈远、KANO模型分析法
需求的優(yōu)先級首先應該根據需求對用戶的價值來判斷呆万。
日本教授狩野紀昭在1984年提出構了KANO模型，用來對客戶需求的滿意度進行分類车份，一共分為五類影響因素（引自維基百科）：
必備因素：滿足基礎需求時谋减，用戶才會使用產品，不會對用戶滿意度產生影響扫沼。當不提供此需求出爹，用戶滿意度會大幅降低；
期望因素（線性因素）：KANO模型是從線性需求模型演變而來缎除，線性需求在產品中實現(xiàn)的越多严就，用戶就越滿意，當不提供此需求伴找，用戶滿意度會降低盈蛮；
興奮因素：用戶意想不到的，如果不提供此需求技矮，用戶滿意度不會降低抖誉，但當提供此需求，用戶滿意度會有很大提升衰倦；
無差異因素：無論提供或不提供此需求袒炉，用戶根本不在意；
反向因素：用戶根本都沒有此需求樊零，提供后用戶滿意度反而會下降我磁。
毫無疑問，產品經理應該避免去實現(xiàn)無差異因素和反向因素驻襟。
有兩個反向因素的例子夺艰，豆瓣把自己的消息系統(tǒng)的名字由豆郵改成私信，僅僅是改個名字沉衣，結果遭到豆瓣用戶集體反對郁副，不得不重新改回來。支付寶的六一運營活動豌习，也是改名字存谎，給大家的名字后面都加了個寶寶，不少在意安全的用戶肥隆，也把矛頭指向了產品經理既荚。這些站在用戶對面的反向需求，用戶必然會不滿意栋艳。
無差異因素則更加悲涼恰聘，這種需求很少出現(xiàn)，你費力做出個功能，結果用戶一點感知都沒有憨琳，某種意義上來說诫钓，比反向因素更加不值得浪費資源去做。
可以看到其中的三條曲線basic needs（基本型需求）菌湃，performance needs（期望型需求），Delighters（興奮型需求）的實現(xiàn)過程遍略。
基本型需求：產品的基本需求往往屬于此類惧所。對于這類需求，必須滿足绪杏，可以做的按部就班下愈，少量創(chuàng)新。
期望型需求：用戶蕾久、競爭對手和產品自身都需要關注的需求势似，平時工作中需要重點關注的需求。
興奮型需求：用戶自身都沒有想到的需求僧著，滿足此類需求很容易引起產品的爆點履因。之前的臉萌，朋友印象都是滿足這種興奮型需求盹愚。
做一份宮保雞丁屬于基本需求栅迄，想吃到腐竹是期望需求，而興奮型需求皆怕，則是類似海底撈的做法毅舆，等待的過程中給你提供刷鞋，美甲等更多的服務愈腾，給用戶帶來驚喜憋活。
實現(xiàn)優(yōu)先級上，首先滿足基本需求虱黄，其次是期望型需求余掖，然后根據產品的生命周期和市場情況，調整興奮型需求的優(yōu)先級礁鲁。
比如在產品成長期，可以恰當做些爆點需求赁豆，增加曝光度仅醇，來快速拉升產品注冊人數。
2魔种、分段交付產品功能析二，MVP實現(xiàn)核心需求
MVP最小可行產品
互聯(lián)網迭代越來越快，爆發(fā)出來的很多需求需要快速驗證，這個時候做一個快速的可行性產品是成本最低的試錯方法叶摄。
一般來說属韧，MVP產品可以從以下幾個緯度確定功能范圍：
用戶緯度：MVP集中滿足核心用戶/種子用戶的需求；
功能緯度：找出最核心蛤吓、與痛點最相關宵喂、最小的功能組合。減少需求永遠比增加需求更難会傲。這里可以用反向分析法锅棕，如果去掉某個功能，會不會影響主體流程淌山。某個需求如果上不了線裸燎，用戶會不會流失，如果回答是會泼疑，則放入mvp中實現(xiàn)德绿，如果不會大膽的放到后續(xù)的迭代中做；
產品原型：現(xiàn)在更多的產品會通過微信公眾號的形式驗證退渗，比如知乎的付費問答值乎移稳，最開始的mvp產品形態(tài)主要是知乎服務號的自定義菜單或者朋友圈的分享，如果一開始就放在App端氓辣，如果用戶沒有來得及更新秒裕，就錯失了市場機會（同一時間，分答已經在市場上跑馬圈地了）钞啸。
現(xiàn)在很多的硬件創(chuàng)業(yè)團隊mvp做法則是設計好了方案几蜻，到眾籌網站進行展示，收集產品反饋体斩，獲得早期用戶梭稚，快速判斷產品是否符合市場需要。
按照產品需求的優(yōu)先級分段交付：
現(xiàn)在的互聯(lián)網產品思維都要求快速迭代絮吵，并不像傳統(tǒng)的軟件產品弧烤，需要所有功能完備才能推向市場。
分段交付可以理解為后續(xù)每一個迭代都是一個mvp蹬敲，只不過跟從0啟動的產品mvp判斷標準不同暇昂，按照需求優(yōu)先級來定義每一次分段交付的內容。
分段交付的優(yōu)點有很多伴嗡，也是scrum開發(fā)模式推薦的做法：
新功能能夠快速發(fā)布急波；
能夠迅速應對業(yè)務需求，擁抱變化瘪校；
迭代周期縮短澄暮，同時獲得迅速反饋名段；
從需求分析開始交互 設計 開發(fā) 測試等角色密切協(xié)作，相比于傳統(tǒng)的瀑布式開發(fā)泣懊，效率跟高伸辟，更少浪費。
評估產品優(yōu)先級除了上面提到的用戶價值模型還可以從一下幾個方面評估：
需求價值：用戶價值即上面KANO模型評估結果馍刮，基本需求優(yōu)先做信夫，期望型需求盡量做，興奮型需求要有一兩個渠退，作為產品亮點和差異化競爭策略需要忙迁。商業(yè)價值，是否對公司有利碎乃；
需求主體：是哪一類用戶的需求姊扔，是否是核心用戶，新用戶梅誓，還是留存用戶恰梢。受眾面是不是足夠大；
需求成本：需求實現(xiàn)的需要投入的技術資源和時間資源梗掰，以及是否依賴內部外部的一些資源嵌言；
需求強度：用戶對該需求有多強烈，需求的頻率如何及穗。
假設我們仍然接受了客戶的需求摧茴，不考慮商業(yè)價值虧損的情況下，需要做一份加腐竹的宮保雞丁埂陆，滿足的只是個別用戶的單次需求苛白，而且實現(xiàn)成本又很高，所以這個需求從優(yōu)先級上是非常低的焚虱。所以不如先上個涼拌腐竹购裙，再做個宮保茄丁：
本文作者：胡瑩（點融黑幫）鹃栽，現(xiàn)任點融網高級產品經理躏率，畢業(yè)于復旦大學，喜歡推理民鼓，殺人游戲薇芝，德州撲克。
