基於需求金字塔模型的解答用戶需求千奇百怪，先做哪些需求，後做哪些需求，不是由產品經理和公司老闆拍腦門決定的。先出一道題考考產品經理們：1998年，QQ開始規劃，1999年2月推出Beta1版本，1999年5月Beta2，1999年8月Beta3。 Beta1版本只能實現3個特性，優先推哪三個呢?請從以下選項裡勾選：
1、卡通頭像
2、不可竊聽安全通訊
3、聊天室
4、很小的.exe文件
5、皮膚skin
6、速度超快0.5秒反應
7、聊天記錄管理器
8、語音
9、視頻
10、看誰在線上
11、傳文件
12、QQ表情
這道題難倒了很多產品經理。這裡提供兩種解答方法，一是基於騰訊當時實際情況的解答(從當時實際情況解答，比較現實)，另一種是基於智能手機金字塔的解答(從現在角度出發，比較理想)。
基於騰訊當時實際情況的解答
筆者跟騰訊公司最早的一批產品經理韓宇宙(Punk)，曾昭朗(Paul)和胡俊智(Kinzeer)探討過這個問題，他們給出了當時的答案是選1、3、10，理由如下：
當時，騰訊QQ的競爭對手13家左右，各有一些特色，從單純的功能上而言，QQ的功能並不突出。真正讓用戶覺得QQ很嗨的主要有兩個特性：
第一個是卡通頭像。它不算啥功能，但讓用戶活了起來，是用戶情感需要的很重要出口。 QQ頭像第一批用的是迪斯尼的卡通人物，因為當時的核心用戶大多是70後，對藍精靈等經典頭像熟悉，容易對號入座，有情感認知。
第二個是聊天室。 QQ和其他IM(即時聊天工具)不一樣的地方，是有一個聊天室，而且是客戶端形態的。所有剛推出來的IM都要解決一個問題：用戶從哪來?QQ聊天室解決了這個問題。因為早期的網絡用戶習慣上Web聊天室，對IM還不熟悉和習慣，更談不上熟人關係。其他IM的用戶關係，一直是相對陌生的，而QQ的關係鍊是從聊天室的陌生，轉化為比較熟悉，是有一定的社區關係，然後再相互加一下QQ，很好地解決了用戶QQ上沒有任何好友的問題，因為只有有了好友，用戶才會有動力持續用QQ與好友互動。而要找人聊天，得知道誰在線上，所以10是優先選擇的特性。
QQ的聊天室是客戶端形態，因此體驗比當時Web 聊天室要好很多，功能強大，而且還引入了社交化體系和金字塔管理體系，大量的用戶每天都能進入固定聊天室相互熟悉，泡妞。這批用戶後來也成為QQ論壇的核心用戶。
有人或者會說，一開始QQ安全性很低，用戶QQ經常被偷，應該優先解決這個問題。但如果考慮到當時用戶都還不習慣用QQ，安全性做得再好又怎麼樣? 況且早期互聯網用戶根本沒安全意識，當時電腦的性能比較低，軟件再怎麼優化也看不出差異。還有現在QQ上很流行的應用：音頻視頻，當時列為優先滿足特性也不實際。當時網速只有56K，支撐不了音視頻應用，並且當年網戀風行，文字聊天更有想像空間。
正如馬化騰所說的：“第一個版本想寫成大也寫不出。簡而言之，10秒內找到人聊，且頭像有趣是最樸素的需求，還有一個是好友保存在服務器端，換電腦也可以恢復。”
總之，在當時環境下，卡通頭像屬於用戶興奮型需求，聊天室屬於用戶期望型需求，看誰在線上屬於用戶基本型需求。
產品跟運營是不分家的，從這個案例可以看出，雖然新產品未上線，但因為運營的迫切需要，騰訊產品人員需研發一部分需求，製造產品的亮點和賣點，在市場上與競爭對手形成差異化。
基於需求金字塔模型的解答
以現在的角度來選擇QQ第一個測試版最重要的三項特性，可能就不是1、3、10的答案了。
使用金字塔的需求層次模型(配圖)來解答這道題目，從現在的角度和環境出發，簡單的方法就是：砍掉這些需求，產品還能用麼?
砍掉特性1“卡通頭像”，普通頭像的QQ也可以用。砍掉特性12“QQ表情”，不影響產品使用。沒有特性7“聊天記錄器”，就不能使用QQ聊天了嗎?顯然是可以的。這也解釋了MSN的聊天記錄保存功能並不是默認地幫用戶勾選上的情形。
特性4“很小的.exe文件”是不是優先滿足的需求?分歧比較大。很多人說當時電腦是撥號上網，網速很慢，“很小的.exe文件”應該是優選的三項特性中的一項，是這樣麼?不是。試想一下，一款網游，文件很大(好幾個G)，網速雖然慢，但是用戶就不去下載了嗎?顯然用戶還是會去下載使用。再想一下， 其實每一個新產品剛推出的時候，都是比較笨重粗糙的。用戶體驗依次是有用、能用、可用、用得爽和品牌，QQ文件太大，用戶獲取的成本有點高，但是還能用。
特性3“聊天室”是多人聊天，一對一聊天的需求還沒有滿足，就去滿足多人聊天需求，顯然也不合理。砍掉特性11“傳文件”的功能，產品照樣能用，用戶之間還可以發文字信息溝通。特性8和9“視頻語音”也是同理。這樣分析下來，特性6、2、10是最重要的三項特性，這跟金字塔需求模型也匹配。如果反應速度太慢，用戶在使用過程中會崩潰。如果QQ1.0的版本很容易被黑客攻擊，導致癱瘓，照樣也使用不了，再說了，QQ上都是自己的熟人關係，比較隱私，一旦QQ被人盜用，後果不堪設想。
從QQ的案例可看出，如何定義需求的優先級很能體現產品經理的水平。產品經理需要評估哪些需求該做，哪些需求不該做，對於已經決定要做的需求(數量很多)，是現在做，還是以後做，不可能在同一時間內全部研發完畢，優先級高的需求優先研發，優先級低的需求延後研發。在實操中，很多產品經理是拍腦門決定先做哪些需求，後做哪些需求，或者公司老闆拍腦門決定需求的優先級，這有點兒戲。在日常生活中，任務的優先級依次如下：重要且緊急;重要不緊急;緊急不重要;不緊急不重要，這也是我們處理產品需求優先級的原則。
需求金字塔模型
新產品未上線，沒有相關的運營數據做支撐，所以從需求對用戶的重要性和緊迫性來判斷需求的優先級是一種比較合理的方法。
這可參考需求金字塔法則：金字塔的最底層是基本型的需求，往上是期望型需求，最上面一層是興奮型需求。基本型需求是必須有的，否則用戶使用不了產品，如果它被砍掉，需求金字塔就可能轟然倒下。所以，基本型需求重要性最高。期望型需求是用戶期望能有的需求，越多越好，如果這一層被砍掉，需求金字塔不會受較大影響，因為最底層的需求還在。所以，期望型需求重要性低於基本型需求。興奮型需求是超出用戶預期的需求，有可以給產品加分，沒有也無大礙，如果砍掉這一層，需求金字塔更不會受影響。
需要特別注意的是，每個用戶心裡的基本型需求、期望型需求和興奮型需求是是千差萬別的，有的用戶認為期望型需求是基本需求，而有的用戶認為興奮型需求是基本需求，這也隨著時間在動態變化。產品需求優先級也要根據實際情況來定。
是不是明確需求的重要性之後就可以判斷需求的優先級了呢，這裡面還需要加上一個因素，即緊迫性。基本型需求重要性最高，也最緊迫，所以它是默認的最高優先級需求。
一般情況下，產品經理肯定先滿足基本型需求，有時因運營、營銷、銷售等的迫切需要，會同時研發一部分的期望型需求(重要不緊急)和興奮型需求(緊急不重要) ，主要是製造產品的亮點和賣點，在市場上與競爭對手形成差異化或者品牌區隔，也有利於產品上線初期憑藉期望型需求或興奮型需求贏得用戶良好的口碑。
需求重要性計算公式
免費型產品已經上線指的是全部免費型產品(全部功能免費)或者部分免費型產品(有些功能免費，有些功能收費)從有到優(調優)的過程。這時因為有了運營數據的支撐，能聚類分析出用戶的行為，甚至可以給用戶畫像。
用戶需求重要性的判斷標準：用戶基數、使用次數和類別重要性。類別重要性分成基本型、期望型和興奮型需求三類。
對於基本型需求，比如產品的性能、安全、瀏覽器兼容等方面，一旦出現問題，用戶不能訪問使用產品，產品經理應立馬放下手頭的工作，利用一切可利用的資源盡快解決這方面的問題。這在有的公司被稱為“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功能。
賺大錢的產品功能先做
收費型產品指已上線或者未上線的全部功能收費型產品或者部分收費型產品。在這特別說明，收費型產品的需求主要是期望型需求和興奮型需求。
收費型產品是公司的收入來源，如無特殊情況，同等條件下，一般收費型的功能優先級要高於免費型的功能優先級。經濟收益(將戰略上的收益也歸為濟收益，包括有形的和無形的收益)高且緊急的功能需求先做，經濟收益高且不緊急的功能需求後做，緊急且經濟收益不高的功能需求再往後做，不緊急且經濟收益不高的功能需求最後做。
此外，還要注意另外一種情況，即有時候必須先完成A功能，才能做B功能，從需求的優先級來看，A功能的優先級肯定高於B功能的優先級。這叫前置後置條件。
不管什麼情況下，基本型需求的優先級永遠默認為最高級，期望型需求和興奮型需求根據具體情況來分析。
此外，畢竟產品需求的滿足是要通過研發人員來實現，所以產品經理還要考慮到研發資源來確定研發優先級。研發的優先級=商業價值/工作量。有些需求或者bug非常簡單，研發工作量非常少，基本上是舉手之勞的事，按照公式，在分子一定的情況下，分母越小，整個比值就會相對較大。這也解釋了為什麼有時候在一個產品的迭代版本里，順便將一些小的需求也一併做了的情況。當然，產品經理在考慮投資回報(商業價值/工作量)的同時，也要考慮到所帶來的風險。
文章來源：iheima.com
特別注意：本站所有轉載文章言論不代表本站觀點，本站所提供的攝影照片，插畫，設計作品，如需使用，請與原作者聯繫，文章轉自alibuybuy