總的來說，定義需求優先級暫時有這七個方法：

KANO模型法：基本型需求>期望型需求>興奮型需求

矩陣分析法：重要且緊急>重要不緊急>緊急不重要>不重要也不緊急

經濟收益法：經濟收益高且緊迫的功能需求??＞ 經濟收益高但不緊迫的功能需求??＞ 緊迫但經濟收益不高的功能需求??＞ 不緊迫且經濟收益不高的功能需求

前/后置需求分析法：前置需求的優先級??＞ 后置需求的優先級；前置需求的重要性和緊迫性??＞ 后置需求的重要性和緊迫性

滿足核心用戶需求的優先（二八原則）

滿足核心業務的需求優先（資源最大化利用）

滿足核心業務的投入產出比最大的需求優先（ROI最大化）

下面為你一一道來。

方法一：KANO模型法：基本型需求>期望型需求>興奮型需求

KANO模型是東京理工大學教授狩野紀昭(Noriaki Kano)發明的對用戶需求分類和優先排序的一種工具。

通俗地講，人的需求可以分為三種，包括基本型需求，期望型需求和興奮型需求。

以我們平時坐車上班為例，坐公交坐地鐵是基本型需求，打的是期望型需求，每天有人接送上下班則是興奮型需求。很容易理解吧。

所以，顯而易見，基本型需求的優先級應當排在第一位，期望型需求排在第二位，而興奮型需求則排在最后。在互聯網產品的設計研發過程中，我們可以按照這個順序來排定需求優先級。

方法二：矩陣分析法：重要且緊急>重要不緊急>緊急不重要>不重要也不緊急

矩陣分析法，也叫四象限法則，把一個二維的橫豎坐標分成四個象限，橫坐標是重要性，縱坐標是緊急性。第一象限為重要且緊急，第二象限為緊急不重要，第三象限為不重要也不緊急，第四象限為重要不緊急。

在工作當中，我們可以根據當前實際情況，把手頭上的所有工作根據四象限法則進行重要性與緊急性的分析定義，然后把這些工作一一放進相應的象限當中，最后再按照矩陣分析法的順序來完成工作。

舉個例子，你現在手頭有四件事情需要處理。第一件事情是你女朋友明天生日，而你還沒準備好禮物。第二件事情是運營部本月15號要做一個活動，今天是3號，運營部期望最晚14號要完成內測，確保能夠在15號按時上線。第三件事是開發說需求文檔里有個地方表述有點問題，怕理解錯誤，希望你在下班前跟他講解一下。第四件事是周末有個聚會，大家讓你推薦個地兒。

根據矩陣分析法，你應該按照事情一>事情二>事情三>事情四的順序來依次完成。

方法三：經濟收益法：經濟收益高且緊迫的功能需求??＞ 經濟收益高但不緊迫的功能需求??＞ 緊迫但經濟收益不高的功能需求??＞ 不緊迫且經濟收益不高的功能需求

這個方法其實跟矩陣分析法道理是一樣的。同樣是把一個二維坐標軸分成一個矩陣（四個象限），橫坐標是經濟收益，縱坐標是緊迫度。第一象限是經濟收益高且緊迫度高，第二象限是緊迫度高但經濟收益不高，第三象限是緊迫度低且經濟收益不高，第四象限是經濟收益高但緊迫度低。

那么同理可得，我們在進行用戶需求分析，排需求優先級的時候，也可以按照這個方法來處理。對于經濟收益高且緊迫的需求，我們就應當列在 P1 優先級里。而對于經濟收益低又不緊迫的需求，我們就應當列在?P3 優先級里。（注：P1，P2表示優先級的高低，P1>P2>P3）

方法四：前/后置需求分析法：前置需求的優先級??＞ 后置需求的優先級；前置需求的重要性和緊迫性??＞ 后置需求的重要性和緊迫性

所謂前/后置需求分析法，是指在一款產品的開發過程中，有的需求是必須要提前開發的，而有些需求是可以放在項目后期開發的。

比如電商網站中，注冊登錄、選品加購、下單結算和支付這些是必須要優先開發完畢的，否則用戶根本無法順暢地完成一個完整的購物流程。

不過，為了使整個購物流程更閉環，我們可能需要增加評價模塊，支持用戶下單成功后可以評價商品，以此作為獲取用戶需求的一種通道；為了刺激和提高用戶回流，我們可能需要在支付成功頁增加個性化商品推薦模塊和促銷廣告模塊；為了引導用戶進行購買決策，我們可能需要在分類列表頁/商詳頁/活動頁等各個頁面增加一個促銷標識、用戶評價數、下單數等信息。后面說的這些，都是可以在完成最簡單基礎的MVP 電商網站之后再排期開發的。

或者任何一個需要前后端協作的需求，接到需求的時候，前端和后端可以同時開始，但由于工作量或其他原因，可能后端需要的時間久一些。但前端要寫完這個功能必須用到后端接口，所以從理論上后端接口應當提前開發完畢，這樣才能在 deadline 使前后端都完成這個功能的全部開發工作。

前/后置需求分析法也是日常工作中時?？梢允褂玫?，大家可以嘗試下。

方法五：滿足核心用戶需求的優先（二八原則）

這個很好理解的。產品的用戶有核心用戶（可能 80% 左右），也有邊緣用戶（可能 20% ?左右）。產品本身就是為那 80% 的核心用戶開發的，不可能滿足所有用戶的所有需求。

所以，核心目標用戶的需求永遠是放在第一位的，非核心的邊緣用戶的需求在分析的時候很順其自然就會往后排，甚至排到你根本不想開發。

這是絕大部分公司的通用做法，可能只有類似鵝廠這樣的公司才會稍微考慮點邊緣用戶的需求吧，比如會考慮和照顧殘障人士的需求。

而在實際工作中，我們可能并不能很清晰地區分出誰是核心用戶，誰又是邊緣用戶。那我們可以簡單轉換下思想——提出相同或者類似需求的用戶體量有多少。提的人多咱就做（比如100個人里有70個人說要做。），提的人少咱就不做（比如10個人里就1個人說可以做。）

方法六：滿足核心業務的需求優先（資源最大化利用）

公司有自己的主營業務，一款產品也有自己重點發展的業務和需要滿足的用戶群。

比如我現在做餐飲軟件，我重點參與的項目主要集中于“智慧門店”這塊，那么圍繞“智慧門店”的正餐、快餐業務、會員營銷、門店的數據統計與分析等是我們的重點業務，所以在排定需求優先級時，我們就會把這方面的需求排在?P1 優先級里，把其他非核心業務的需求排得比較靠后。

方法七：滿足核心業務的投入產出比最大的需求優先（ROI最大化）

按照方法六的說法，我們應當優先滿足核心業務的需求，但核心業務的需求可能有很多，比如我剛才說的正餐業務需求，光說正餐業務其實是比較籠統而空泛的，因為整個正餐業務也許有幾百上千個需求。

那么如何從這些需求當中找到優先級排第一的需求呢，這時就可以參考方法七了——在所有能滿足核心業務的需求里面，找到投入產出比最大的需求優先開發。

舉個例子，我們從整個正餐業務的需求里面抽出 20 個需求放入 P1 優先級需求池，那這 20 ?個需求到底先開發哪個呢，按照方法七，先開發投入產出比最大的需求。從理論上講，總的原則就是，花最少的時間、最少的資源、最少的預算開發完功能，盡可能快地趕在時間窗口，獲取最多的用戶，賺最多的錢。

當然，說了這么多，可能最終都敵不過老板那句話——來，咱們先做這個需求吧。聽我說，這是大部分公司的常態，心態放好就ok。

不過，碰到這種情況，我們還是需要分析一下的。

首先，我們需要嘗試站在老板角度思考問題，因為我們不是老板，站的高度沒有老板高，看得也不如老板遠，他對市場的判斷可能比你更準確，要命的是也許比你還更懂產品。那么在這種情況下，如果我們跟老板的意見相左，我們可以提出自己的想法，但最終決策權交給老板。

但是，如果老板對產品啥也不懂，就知道瞎雞巴亂指揮，今天讓你先做 a 需求，明天就讓你先做 b 需求了，反反復復沒個定數。那么作為偉哥，能給你的建議只有一個——趕緊收拾東西跑路。恩，這也許是你 2018 年聽到的最真誠的建議。

最后，不管你在工作中受到老板多大程度的牽制與干涉，作為產品經理，如何去排定需求的優先級，你自己心里要有一桿秤。