1樓：GXA好體驗獎
拿餐飲行業舉例
餐飲屬於剛性消費，消費預期的不確定性較低。根據對人們需求滿足的層次劃分，消費結構可分為生存型消費、發展型消費和享受型消費。日常飲食消費屬於生存型消費，可樂等飲品屬於發展型消費，高階品牌店（牛排、甜品）等屬於享受型消費。
2樓：浪裡大肥蟲
作為產品經理基本上都會遇到各種需求堆積的情況，那麼怎麼將堆積的需求有序的整理是非常重要的。
只有將所有需求梳理叫，並且做好優先順序劃分，這樣我們的工作才能有條不紊得開展。
那麼優先順序又應該如何分呢？遵循哪些原則呢？
一、根據Kano模型進行需求排序
Kano模型是對使用者需求分類和優先排序的工具，分析使用者需求對使用者滿意的影響為基礎，體現了產品效能和使用者滿意之間的非線性關係。
根據需求對使用者的影響將其劃分成五種需求：
1.必備型需求：
必備型需求可以說是產品的基本功能，不能沒有。在使用者眼中有這個功能是正常，沒有就對產品產生不滿的情緒。
必備型功能是必須要實現的功能點，無法帶來滿意，但會消除不滿。
2.期望型需求
期望型需求一般就是使用者在使用產品過程中提出來的功能點，可能是新功能，可能是優化點。有這樣的功能後會讓客戶覺得不錯，但是並不會有更多情緒。
3.興奮型需求
興奮型需求是亮點功能，使用者沒想到，結果產品做到了，會給使用者帶來驚喜，才有可能自主自發傳播，從而產生使用者裂變，達到拉新引流的目的。
這是取決於產品經理對產品客戶的理解以及對行業的洞察力。
4.無差別需求
無差別需求是做不做對使用者沒有任何影響，這類功能無關痛癢，在某種程度上反而增加了系統的複雜性。
在面對這樣的需求時要注意做減法，遇到此類需求最好不做。
5.反向需求
反向需求是使用者根本不需要此需求，提供後使用者滿意度反而會下降。
最常見的就是廣告。出於商業利益的考量，這類需求必然會存在，就需要產品經理在客戶體驗和商業需求中找到合適的點。
根據Kano模型對需求的優先順序排序為：必備型需求》期望型需求》興奮型需求》無差別需求》反向需求。
二、關於需求的重要性以及緊急性
我們還可以根據四象限法，進行排序。
三、關於開發量和效率
我們在進行需求排序的時候最好是優先見效快且開發量不大的，快速迭代。而那些開發量比較大而且見效慢的需求可以放在後面。
3樓：口水龍
可以換個思路，從產品的角度去回答這個問題。
1.優先考慮產品當前最重要的問題是什麼？是轉化率太低，還是存留的問題。如果你的產品轉化率很高，那麼就可以專注啟用使用者的功能。可以按重要程度由高到低，找出三個問題。
2.將需求歸屬到你排定的問題當中去。解決完全不同型別的需求之間無法排定優先順序的問題。
3.考慮成本，優先完成價效比最高的需求。
這樣的思路的好處是
1.你會優先去分析產品當前最重要問題是什麼？而不是羅列一堆需求2.從根本上解決了不同型別的需求的優先順序的問題。
3.對每乙個需求都有所預估，然後在對比結果，從而培養了產品的核心的預判的能力。
4樓：巍巍崑崙中華龍
銷售的過程，其實是產品與客戶需求結合的過程。結合的越緊密，締結的可能性和速度就越高！因此也在一定程度上可以說，銷售是乙個做分析的工作～細緻分析產品特性、分析客戶真實需求，然後當媒婆，把二者聯絡起來！
5樓：雷明燦
分享一下明道的使用者需求排序方法：我們是一家B2B的網際網路公司，做的是團隊協作工具明道
，我們的產品需求主要來自兩個方面：
產品內部提案
1.符合產品價值觀的優先開發
2.投入產出比高的優先開發
銷售從客戶那裡得到的反饋
1.符合產品未來發展方向的優先開發
2.嚴重影響客戶完整體驗產品的優先開發
需求管理工具用的是就是明道，如圖：
此圖顯示的是來自客戶的需求排序，運營流程為：銷售填寫需求-產品經理甄別-採納or不採納
此圖顯示如何處理來自產品內部的需求，評審後直接進入開發階段了。
6樓：
大部分創業公司，需求排序優先順序：老闆最急》總監最急》使用者需求緊急程度。
其實需求排序也得分需求，分後台PM和前台PM。有的需求是來自業務部門的後台需求，如果需求不加緊解決，會影響業務部門的相關操作；有的需求來自運營，基本上都是專題活動的需求；有的需求來自甲方；有的需求則真正是使用者所需的功能。對於後台PM解決業務部門的需求就是最緊急的任務，對於前台PM，解決使用者的需求則排在第一
7樓：
我認為根據產品的核心功能和產品的資料分析報告來確定最終的需求優先順序排序
使用者的需求只是產品迭代的部分依據，並不是產品的最終走向
8樓：蘇杰
先按我的思路改一下問題，不是「使用者需求的排序」，而是「產品功能的排序」，即先做什麼後做什麼的問題。基本思路如下，展開得幾千字，先不了...：
0. 前置任務，確認產品原則（可展開）
1. 確認需求價值
1-1. 確認階段產品目標，講直白點就是KPI：使用者數？收入？……（如有多指標，給指標加權，可展開）
1-2. 評估每個功能（背後滿足的需求）對指標的貢獻，可以簡單用1~5分級，這是價值的半定量結果
2. 確認功能成本
2-1. 用各種方法確認相對成本（如Team Estimation Game、Planning Poker，可展開），注意，這裡是要各個功能的成本比例和排序，並不用評估到具體的「人天」
3. 確認價效比= 價值/成本，得到初步排序
4. 識別功能類別，個人比較習慣用KANO模型（可展開）
4-1. 分類-基礎、期望、亮點、無差別、反向
4-2. 分別對待：基本功能必做、實現個別低成本的亮點（大公司做法不同，可展開）、期望功能按價效比排序、無差別功能別做（無差別功能的低成本判斷方法，可展開）、反向功能權衡利弊（往往是多目標的衝突處理，可展開）
4-3. 得到優化過的排序
5. 其他實際情況的考慮
5-1. 內外部依賴關係：合作部門？公司？某功能必須要誰做？……
5-2. 功能組合的完整性，模組依賴什麼的
5-3. 其他朋友說到的老闆需求什麼的
6. 如太極，把招式忘掉，追求「如何拿到結果」
差不多了吧...
9樓：
回答問題能不能有點良心？
沒有幫助就算了，至少不要誤導大家。
在公司裡打工，啥需求讓領導開心就做哪個。
自己創業，啥需求能幫忙拉投資就做哪個。
想成為高手，記得為以上行為找一套邏輯：參見其他回答。
作為產品經理如何有效的將使用者需求轉換為產品需求？
優途UI教育 如何把使用者需求轉化為產品需求呢？分四個步驟，首先是要篩選掉明顯不合理的需求，比如說當前的技術不能實現，投入產出比低的，還有沒有適合場景的，這些就是明顯的不合理的需求。第二步就是挖掘使用者的真實需求，從表象看本質，通過競品分析做到別人有的我也有，別人不好的我們來優化它。第三步，就是分析...
產品經理如何驗證所想到的是真正的使用者需求的
資料萬有引力 這個問題不可證明，但可證偽 1 使用者證偽 多問使用者，可以證偽 2 同行證偽 多問同行，可以證偽 3 事實證偽 做好上線，可以證偽 PS 90 的網際網路專案都會失敗，所以證偽容易，證明很難！ 冠一 就比如在滴滴未上線之前，使用者打車難的需求解決方法只能是提前等車 114預約，不知道...
產品經理小需求如何提？
二毛 不同的公司有不同的專案管理制度，但你這麼問了可能你們公司沒有對應這部分的制度。如果是當前開發版本過程中出現了極其重要的需求點，可以直接合併進去，做好過程記錄，如果不影響工期的話就最好了。如果需求的優先順序不需要太高，就可以慢慢積累形成需求池，再從中選擇合適難度，合適數量，合適優先順序的需求組合...