需求的優先級,如何評估?

7 評論 31343 瀏覽 254 收藏 11 分鐘

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

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

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

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

一、重要程度

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

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

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

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

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

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

舉個簡單的例子:

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

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

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

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

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

二、頻率

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

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

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

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

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

三、成本

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

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

你以為這就完了嗎?

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

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

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

#專欄作家#

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

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

題圖來自Unsplash,基于CC0協議

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 產品運營

    回復
  2. 需求拆分的方法還是很好的

    回復
  3. 看到公式,特別想知道這個量的數值怎么確定,各個量取值范圍怎么定,哈哈 ??

    來自北京 回復
    1. 哈哈~不是量化的哈~

      來自廣東 回復
  4. ??

    來自北京 回復
  5. 紙上得來終覺淺,絕知此事要躬行!

    來自安徽 回復
  6. 受教了

    來自北京 回復