在產品經理的工作中，需求優先級是經常被提及的事情。畢竟資源總是有限的，需求是無限的，想利用有限的資源來做無限的需求是不現實的，所以需要給需求排優先級。只是這個優先級怎麼定義，一直是個問題。下面我來講講我的理解。
首先，需求來源於我們的目標用戶，我們的需求是用來解決用戶遇到的摩擦。所以，優先級定義的第一個維度就是摩擦的強烈程度。舉個例子，對溫飽的需求的強烈程度會遠遠高於文化生活的需求。其次，用戶的摩擦，存在一定的發生頻率，頻率可能從“時時刻刻”到“百年一見”，很明顯，如果頻率越高，那麼用戶這個需求就越迫切。最後，需求的滿足都是需要一定的成本的，產品經理需要對自己的投入產出比有一定的衡量。
所以總結一下，需求優先級可以暫時定義爲：優先級=。
一、重要程度
對於重要程度，需要時刻考慮兩個維度：用戶的維度和公司的維度。我們需要爲用戶考慮，因爲他是我們需求的直接來源；我們需要爲公司考慮，是因爲我們本質上是爲了公司服務的。在產品生命週期的初始階段，我們需要多爲用戶考慮多一點，這樣產品才能成長起來；在生命週期進入穩定期時，這時候就需要多爲公司考慮，從而達到盈利的目的。
由於公司的維度和用戶維度大多時候都是衝突，所以我想先從用戶層面來剖析需求，最後引入到公司的維度。用戶的維度而言，有一種經典的模型：卡諾模型。它將需求分爲以下幾種，我用統一的“如果有……就；如果沒有……就”這種句式做統一的解讀：
必備型需求：如果有這個功能，用戶滿意度不會提升；如果沒有，用戶滿意度會降低；
期望型需求：如果有這個功能，用戶滿意度會提升；如果沒有，用戶滿意度會降低；
魅力型需求：如果有這個功能，用戶滿意度會提升；如果沒有，用戶滿意度不會降低；
無差異需求：如果有這個功能，用戶滿意度不會變化；如果沒有，用戶滿意度也不會變化；
反向型需求：如果有這個功能，用戶滿意度會下降；如果沒有，用戶滿意度不會變化；
這五類可以用下面的圖來展示，爲了方便理解，我把線條都畫成直線或者折線。
對於這5種需求的分類中，有些人會把發生頻率也納入到評估體系中，但是嚴格來講，這是不對，這5種需求劃分應該只跟產品的定位有關係。
舉個簡單的例子，對於網盤，它的定位是一個“在線存儲”的產品。其最基礎的功能應該是：增、刪、改功能，所以這三個是作爲必備型的需求。接着，如果文件越來越多，那麼就會有管理的需求，這時候需要有文件夾分類、移動文件和複製文件等功能。所以這些會作爲期望型的需求。如果網盤能提供高達1T的存儲空間，那麼這個功能就作爲一個魅力型需求。如果網盤提供一個功能：用戶可以選擇讓文件大小顯示精確到小數點後10位的功能，這個對於大部分用戶來講是無感知的，那麼這就是一個無差異需求。如果你在網盤裏插入廣告，那麼用戶會反感，這就是反向型需求。
這5種需求裏在產品的生命週期的不同階段，優先級各不相同。初期是必備型需求佔優，第一個版本需要做出一個最小的可用產品，才能投入到市場裏。在後續迭代裏，需要穩步地加入期望型功能，然後每個迭代版本加入一兩個魅力型功能，也就是傳說中的“亮點”功能，用以配合產品的宣傳。大部分的無差異需求和反向型需求是不會被安排的，除非對於公司來講，這些需求有其他方面的價值。
比如，某手機廠商之前標榜的後蓋的弧度打磨經過了xx個版本。這種弧度的差異接近於無差異功能。但是爲什麼還要做這個事情呢？因爲這可以作爲一個營銷的亮點，打造“匠心公司”的一種品牌形象。
再比如，反向型的需求常見於各種商業化的需求，不管是廣告、還是增值服務、道具收費等，這些都可能陰氣用戶反感，但是可以增加公司營收，所以這些需求在最後產品穩定期，都會作爲重點去坐。
總結一下，需求重要程度的評估既需要考慮對於用戶的價值，還需要考慮對於公司的價值，以及考慮所在的產品週期。
二、頻率
頻率這個詞比較好理解，這是一個比較客觀的標準，大家對這個詞也很熟悉。只是，我有一個有趣的想法想跟大家分享一下：摩擦的發生頻率不僅僅是存在於實際遇到的時候，也存在於用戶自己的想象中。
舉個簡單的例子，對於鬧鐘，一開始大家都習慣於“週中”的鬧鐘，即週一到週五的鬧鐘。因爲大多數的情況下，我們都是這5天需要上班上學。但是，大部分的國家都有一個叫做法定節假日的東西，所以就有可能出現週六或者週日上班的情況。如果，只從“週中”和“週末”這兩個概念來說，是沒辦法滿足用戶的需求的。這時候，就需要引入一個“工作日鬧鐘”的概念。產品會自動判別今天是不是需要上班，從而智能地提醒。
這個現在基本都是鬧鐘產品的標配了，但是，我思考的是這個需求的發生頻率。理論上節假日都是少數，大部分情況下，只選“週中”也是可以滿足用戶的訴求的。但是，如果用戶在設置之後，都需要一直擔心“明天會不會響”這種事情，那麼我認爲這個需求的摩擦就一直都存在的。可能用戶設置完之後沒有感知，但是如果發生第一次、第二次調休遲到之後，這個擔心就會一直困擾着用戶。雖然實際上節假日是少數，但是在用戶的想象中，這確實是一個“每天擔心的事情”，所以從這一點而言，我覺得這個是一個“高頻”的場景，而不是“低頻”的場景。
三、成本
產品經理這個崗位，一直都有一種“管理”的屬性，因爲產品經理需要協調好設計、開發和測試同學，共同地完成自己的設想。對於管理者而言，成本的評估一直都是不可繞過的一環。
最基礎的成本，也就是開發成本，開發成本是所有成本里最主要的成本，而開發成本最直接的指標就是開發時間。除此之外，如果涉及到比較複雜的場景，那麼交互設計的成本也是明顯增加。如果涉及到比較複雜的動畫，那麼視覺設計的成本也比較高。最後，還有測試的人力成本。你以爲這就完了嗎？其實並不是，產品經理自身梳理邏輯以及撰寫文檔也是需要時間成本。這是最常規的成本。有些需求可能還會涉及到商務、法務甚至三方公司，涉及到方面越多，成本就越高。
最後這些零零總總加起來，纔是總的成本。提出成本這個概念最重要的一條就是：希望產品經理在評估成本的時候，也要把自己考慮進去。
以上，就是我對於需求優先級評估這件事情上的心得，分享給大家。這種評估方法適用於大部分的需求，除了“老闆的需求”。老闆需求的存在不可以用常理來衡量，如果老闆比較講道理（理想情況下），你可以拿這套優先級評估的方法跟他溝通；如果不行，那麼老闆的需求優先級直接就提到最高了，而不需要經過任何評估。