1. 程式人生 > >第30件事 定義需求優先級的4種方法

第30件事 定義需求優先級的4種方法

很多 影響 bsp 數值 至少 特定 還需要 銷售 並不是

從定義需求的優先級也能看出產品經理的能力。在前面已經詳細闡述了如何評估哪些需求該做,哪些需求不該做。對於已經決定要做的需求,若數量很多,就可確定哪些是現在做,哪些是以後做,不可能在同一時間內全部研發完畢。總得有先有後,優先級高的需求優先研發,優先級低的需求延後研發。這就會涉及需求優先級定義的標準。在產品實踐中,很多產品經理都是拍腦門決定先做哪些需求,後做哪些需求,要麽就是老板拍腦門決定需求的優先級。那到底定義需求的優先級有沒有原則和方法呢?先說說原則。在日常生活中,處理任務的優先級有四種情況:重要且緊急、重要不緊急、緊急不重要、不緊急不重要。這四種情況也是我們處理需求優先級的原則,即“重要性+緊急性”。我們把需求的“重要性+緊急性”統稱為商業價值原則。基於這個商業價值原則,下面主要闡述需求優先級定義的四種方法。

1.新產品未上線
產品未上線這種情況指的是產品從無到有的這個過程,這種情況因為沒有相關的運營數據作為支撐,所以從需求對用戶的重要性和緊迫性來判斷需求的優先級是一種比較合理的方法。那麽如何判斷需求對用戶的重要性呢?一般情況下,用戶需求的重要性依次為:基本型需求>期望型需求>興奮型需求。使用需求的金字塔法則來表達,金字塔的最底層是基本型的需求,往上是期望型需求,最上面一層是興奮型需求。
(1).基本型需求是必須有的需求,若沒有,用戶基本上就使用不了產品,如果金字塔最底層被砍掉,這個需求的金字塔就可能站立不穩而倒下,所以基本型需求的重要性最高。
(2).期望型的需求是用戶期望能有的需求,用戶希望越多越好,但是如果金字塔的第二層被砍掉,需求的金字塔不會受較大的影響,因為最底層的需求還在,用戶還能繼續使用產品,所以期望型需求的重要性要低於基本型需求。

(3).興奮型需求是超出用戶預期的需求,若存在,可以給產品加分,沒有也無大礙。如果我們砍掉金字塔的最頂層,需求的金字塔更加不會受到影響,因為基本型需求和期望型需求都存在,用戶還能繼續使用產品,所以,興奮型需求的重要性要低於期望型需求。其實我們從金字塔的建造過程來看,也是先建造最底層,然後是中間層,最後是最高層。
需要特別註意的是,每個用戶心裏的基本型需求、期望型需求和興奮型需求都是不一樣的。比如,有的用戶認為期望型需求是基本型需求,而有的用戶認為興奮型需求是基本型需求,而且這還隨著時間在動態變化,甚至衰減,所以產品需求優先級的定義也要根據當時的實際情況來定。是不是明確需求的重要性之後就可以判斷需求的優先級了呢?這裏還需要加上一個因素,即緊迫性。基本型需求的重要性最高,且最緊迫,所以基本型需求的優先級默認是最高的。一般情況下,肯定是先做基本型需求,在研發基本型需求的同時,有時候因為運營、營銷、銷售等業務需求的迫切需要,會同時研發一部分期望型需求(重要不緊迫)和興奮型需求(緊迫不重要),主要是制造產品的亮點和賣點,在市場上與競爭對手形成差異化或者品牌區隔,這也有利於產品上線初期憑借期望型需求或興奮型需求贏得用戶良好的口碑。
產品與運營是不分家的,從這個案例可以看出,雖然新產品未上線,但是已經開始有以運營為導向的元素出現。因為運營需求的迫切性,應該研發一部分需求來制造產品的亮點和賣點,在市場上與競爭對手形成差異化或者品牌區隔。此外,在產品實踐中,很多產品的成功都具有時效性,有的產品在當時的環境中雖然成功了,但是在現在的環境下復制這種曾經成功的模式卻不一定會成功,所以通過QQ這個案例,至少可以得出三點結論:一是需求優先級的定義要基於當時的環境和實際情況;二是用戶需求是一個動態變化過程,需要適時調整;三是產品與運營不分家,在確保滿足基本型需求的同時,也要適當考慮滿足用戶期望型和興奮型的需求。

2.免費型產品已經上線
免費型產品已經上線這種情況指的是全部免費型產品(全部功能免費)或者部分免費型產品(有些功能免費,有些功能收費)從有到優(調優)的這個過程,這時候因為有了運營數據的支撐,通過運營數據,能聚類分析出用戶的行為,甚至可以給用戶畫像。那麽如何定義需求的優先級呢?這裏還是采用需求的商業價值原則,即“重要性+緊迫性”原則。用戶有需求,產品利用相應的功能或內容來對應和滿足需求,可以根據功能的使用率、使用次數和重要性,形成一個需求重要性的計算公式,根據計算的結果和緊迫性來定義需求的優先級。
用戶需求重要性的判斷標準:用戶基數、使用次數和類別重要性。其中,類別重要性分為基本型、期望型和興奮型需求三類。對於基本型需求,比如產品的性能、安全、瀏覽器兼容等方面,一旦出現問題,用戶便不能正常使用產品,此時應該立即放下手頭的工作,利用一切可利用的資源盡快解決問題。有的公司把這種問題稱為“911bug”,意思是說其屬於最高級別的bug,優先級最高。比如,網站被黑了,或者使用起來非常慢,用戶快崩潰了,這個時候應該想方設法盡快解決。試想一下,如果用戶訪問或使用不了你的產品,那麽不管你的產品功能有多強大,做得有多好,用戶還是享受不到。這個時候如果還是投入資源做期望型需求和奮型需求,那麽用戶就會流失,這是一個常識。對於期望型需求和興奮型需求,可以通過運營數據形成公式計算。需求對應相應的產品功能,看下邊的公式:
用戶需求重要性=功能使用用戶百分比(用戶使用率)×功能使用次數百分比(功能或內容使用率)×類別重要性百分比(期望型需求、興奮型需求)
註意:最底層的基本型需求不在計算範圍內,因為默認其為最高級別。這個需求級別的公式就是綜合考慮有多少用戶需要、用戶是經常需要還是偶爾需要、對用戶重要還是不重要三個因素。比如,有的功能相對類別來說重要性雖然高一些,但是使用該功能的用戶數和用戶次數卻比較少;有的功能相對類別來說重要性雖然低一些,但是使用該功能的用戶數和用戶次數卻比較多。根據上述公式計算後得出的結果有可能是:類別重要性比較低的功能,其整體重要性要高於類別重要性比較高的功能的整體重要性。
關於計算公式舉例:
A功能屬於期望型需求,在一定時期內,假設總的用戶數有100人,其中有50人使用過A功能,那麽A功能使用用戶百分比就是50/100=50%;在這50人使用的過程中,一共使用了10000次,那麽使用次數百分比就是10000/50=200;在求類別重要性百分比時,假定期望型需求是50%,那麽A功能級別數值為50%×200×50%=50。
B功能屬於興奮型需求,在一定時期內,假設總的用戶數有100人,其中有30人使用過B功能,那麽B功能使用用戶百分比就是30/100=30%;在這30人使用的過程中,一共使用了90000次,那麽使用次數百分比就是90000/30=3000;在求類別重要性百分比時,假定興奮型需求是25%,那麽B功能級別數值為30%×3000×25%=225。
可以看出,B功能級別數值225要大於A功能級別數值50,所以B功能的整體重要性要高於A功能。
對用戶來說,基本型、期望型與興奮型需求並不是一成不變的,是一種動態的變化過程,並且運營數據也在不斷地發生變化,需要及時做出相應的調整。因此,明確需求的重要性之後,還要按照先做重要且緊迫的需求,後做重要不緊迫的需求,接著做緊迫不重要的需求,最後做不緊迫不重要的需求。

3.收費型產品
收費型產品的情況指的是已經上線或者未上線的全部收費(全部功能收費)或者部分收費的產品(有些功能免費,有些功能收費)。在這裏特別說明一下,收費型產品的需求主要也是期望型需求和興奮型需求,因為基本型需求的優先級默認是最高的(重要且緊迫)。一般情況下,收費型產品是公司的收入來源,如無特殊情況,在同等條件下,收費型的功能優先級一般要高於免費型的功能。那麽收費型產品的優先級如何定義呢?定義的標準就是商業價值,即“重要性+緊迫性”,這裏的重要性主要指的是經濟收益(將戰略上的收益也歸結為經濟收益,包括有形的和無形的收益),經濟收益高且緊迫的功能需求先做,經濟收益高且不緊迫的功能需求後做,緊急且經濟收益不高的功能需求再往後做,不緊迫且經濟收益不高的功能需求最後做。

4.前置/後置需求
前置需求的開始日期或完成日期決定後續需求的開始日期或完成日期。註意這裏的後續需求就是後置需求。有時候必須先完成前置需求,然後才能實現後置需求。從需求的優先級來看,前置需求的優先級肯定要高於後置需求優先級。前置需求的重要性和緊迫性都要高於後置需求。

總的來說,對於上述四種定義需求優先級的方法,在公司範圍內,在特定的產品階段是可以搭配使用的。需求優先級定義的原則基本上是一樣的,都是商業價值原則,即“重要性+緊迫性”。不管在哪一種方法下,基本型需求的優先級默認都是最高的,至於期望型需求和興奮型需求的優先級,要根據具體的實際情況運用上述一種或幾種方法來綜合評定,而不是用“拍腦門”的方法確定。
需要特別註意的是,上述內容都是圍繞需求的優先級來展開的,是從產品人員的角度來說的。但是從研發人員的角度來說,畢竟他們受到各種人力、物力、財力的限制和影響,並不能完完全全按照產品人員確定的需求優先級來進行研發。相對於基於產品人員確定的需求優先級來說,研發人員會基於開發資源定義出自己的一套研發優先級。至於研發優先級如何定義,將在第31件事中詳細闡述。


需求優先級的定義要基於當時的環境和實際情況;用戶需求是一個動態變化的過程,需要適時調整;產品與運營不分家,在確保滿足基本型需求的同時,也要適當考慮滿足用戶期望型和興奮型的需求。

第30件事 定義需求優先級的4種方法