需求的優先級是產品經理工作中常被提及的，那么在產品工作中，要如何去評估需求的優先級呢？

在產品經理的工作中，需求優先級是經常被提及的事情。畢竟資源總是有限的，需求是無限的，想利用有限的資源來做無限的需求是不現實的，所以需要給需求排優先級。只是這個優先級怎么定義，一直是個問題，下面我來講講我的理解。

• 首先，需求來源于我們的目標用戶，我們的需求是用來解決用戶遇到的摩擦。所以，優先級定義的第一個維度就是摩擦的強烈程度。舉個例子：對溫飽的需求的強烈程度會遠遠高于文化生活的需求。
• 其次，用戶的摩擦，存在一定的發生頻率，頻率可能從“時時刻刻”到“百年一見”，很明顯，如果頻率越高，那么用戶這個需求就越迫切。
• 最后，需求的滿足都是需要一定的成本的，產品經理需要對自己的投入產出比有一定的衡量。

所以總結一下，需求優先級可以暫時定義為：

一、重要程度

對于重要程度，需要時刻考慮兩個維度：用戶的維度和公司的維度。

我們需要為用戶考慮，因為他是我們需求的直接來源；我們需要為公司考慮，是因為我們本質上是為了公司服務的。在產品生命周期的初始階段，我們需要多為用戶考慮多一點，這樣產品才能成長起來；在生命周期進入穩定期時，這時候就需要多為公司考慮，從而達到盈利的目的。

由于公司的維度和用戶維度大多時候都是沖突，所以我想先從用戶層面來剖析需求，最后引入到公司的維度。用戶的維度而言，有一種經典的模型：卡諾模型。它將需求分為以下幾種，我用統一的“如果有……就；如果沒有……就”這種句式做統一的解讀：

1. 必備型需求：如果有這個功能，用戶滿意度不會提升；如果沒有，用戶滿意度會降低；
2. 期望型需求：如果有這個功能，用戶滿意度會提升；如果沒有，用戶滿意度會降低；
3. 魅力型需求：如果有這個功能，用戶滿意度會提升；如果沒有，用戶滿意度不會降低；
4. 無差異需求：如果有這個功能，用戶滿意度不會變化；如果沒有，用戶滿意度也不會變化；
5. 反向型需求：如果有這個功能，用戶滿意度會下降；如果沒有，用戶滿意度不會變化。

這五類可以用下面的圖來展示，為了方便理解，我把線條都畫成直線或者折線。

對于這5種需求的分類中，有些人會把發生頻率也納入到評估體系中，但是嚴格來講，這是不對，這5種需求劃分應該只跟產品的定位有關系。

舉個簡單的例子：

1. 對于網盤，它的定位是一個“在線存儲”的產品。其最基礎的功能應該是：增、刪、改功能，所以這三個是作為必備型的需求。
2. 接著，如果文件越來越多，那么就會有管理的需求，這時候需要有文件夾分類、移動文件和復制文件等功能，所以這些會作為期望型的需求。
3. 如果網盤能提供高達1T的存儲空間，那么這個功能就作為一個魅力型需求。
4. 如果網盤提供一個功能：用戶可以選擇讓文件大小顯示精確到小數點后10位的功能，這個對于大部分用戶來講是無感知的，那么這就是一個無差異需求。
5. 如果你在網盤里插入廣告，那么用戶會反感，這就是反向型需求。

這5種需求里在產品的生命周期的不同階段，優先級各不相同。初期是必備型需求占優，第一個版本需要做出一個最小的可用產品，才能投入到市場里。在后續迭代里，需要穩步地加入期望型功能，然后每個迭代版本加入一兩個魅力型功能，也就是傳說中的“亮點”功能，用以配合產品的宣傳。大部分的無差異需求和反向型需求是不會被安排的，除非對于公司來講，這些需求有其他方面的價值。

比如：某手機廠商之前標榜的后蓋的弧度打磨經過了xx個版本。這種弧度的差異接近于無差異功能。但是為什么還要做這個事情呢？因為這可以作為一個營銷的亮點，打造“匠心公司”的一種品牌形象。

再比如，反向型的需求常見于各種商業化的需求，不管是廣告、還是增值服務、道具收費等，這些都可能陰氣用戶反感，但是可以增加公司營收，所以這些需求在最后產品穩定期，都會作為重點去坐。

總結一下，需求重要程度的評估既需要考慮對于用戶的價值，還需要考慮對于公司的價值，以及考慮所在的產品周期。

二、頻率

頻率這個詞比較好理解，這是一個比較客觀的標準，大家對這個詞也很熟悉。只是，我有一個有趣的想法想跟大家分享一下：摩擦的發生頻率不僅僅是存在于實際遇到的時候，也存在于用戶自己的想象中。

舉個簡單的例子，對于鬧鐘，一開始大家都習慣于“周中”的鬧鐘，即周一到周五的鬧鐘。因為大多數的情況下，我們都是這5天需要上班上學。但是，大部分的國家都有一個叫做法定節假日的東西，所以就有可能出現周六或者周日上班的情況。

如果，只從“周中”和“周末”這兩個概念來說，是沒辦法滿足用戶的需求的。這時候，就需要引入一個“工作日鬧鐘”的概念。產品會自動判別今天是不是需要上班，從而智能地提醒。

這個現在基本都是鬧鐘產品的標配了，但是，我思考的是這個需求的發生頻率。理論上節假日都是少數，大部分情況下，只選“周中”也是可以滿足用戶的訴求的。但是，如果用戶在設置之后，都需要一直擔心“明天會不會響”這種事情，那么我認為這個需求的摩擦就一直都存在的。

可能用戶設置完之后沒有感知，但是如果發生第一次、第二次調休遲到之后，這個擔心就會一直困擾著用戶。雖然實際上節假日是少數，但是在用戶的想象中，這確實是一個“每天擔心的事情”，所以從這一點而言，我覺得這個是一個“高頻”的場景，而不是“低頻”的場景。

三、成本

產品經理這個崗位，一直都有一種“管理”的屬性，因為產品經理需要協調好設計、開發和測試同學，共同地完成自己的設想。對于管理者而言，成本的評估一直都是不可繞過的一環。

最基礎的成本，也就是開發成本，開發成本是所有成本里最主要的成本，而開發成本最直接的指標就是開發時間。除此之外，如果涉及到比較復雜的場景，那么交互設計的成本也是明顯增加。如果涉及到比較復雜的動畫，那么視覺設計的成本也比較高。最后，還有測試的人力成本。

你以為這就完了嗎？

其實并不是，產品經理自身梳理邏輯以及撰寫文檔也是需要時間成本。這是最常規的成本。有些需求可能還會涉及到商務、法務甚至三方公司，涉及到方面越多，成本就越高。

最后這些零零總總加起來，才是總的成本。提出成本這個概念最重要的一條就是：希望產品經理在評估成本的時候，也要把自己考慮進去。

以上，就是我對于需求優先級評估這件事情上的心得，分享給大家。這種評估方法適用于大部分的需求，除了“老板的需求”。老板需求的存在不可以用常理來衡量，如果老板比較講道理（理想情況下），你可以拿這套優先級評估的方法跟他溝通。如果不行，那么老板的需求優先級直接就提到最高了，而不需要經過任何評估。

#專欄作家#

妖葉秋，交互設計師，人人都是產品經理專欄作家。做過ToC產品的交互設計，現在在嘗試ToB的業務。主攻交互，也懂點用研、視覺和產品的知識。愛生活、愛設計、愛讀書、愛總結，頭像下方是我的聯系方式，歡迎志同道合者與我交流。

本文原創發布于人人都是產品經理，未經許可，不得轉載。

題圖來自Unsplash，基于CC0協議