加入你是QQ的產品經理

基於需求金字塔模型的解答用戶需求千奇百怪，先作哪些需求，後作哪些需求，不是由產品經理和公司老闆拍腦門決定的。先出一道題考考產品經理們：1998年，QQ開始規劃，1999年2月推出Beta1版本，1999年5月Beta2，1999年8月Beta3。Beta1版本只能實現3個特性，優先推哪三個呢?請從如下選項裏勾選：

一、卡通頭像

二、不可竊聽安全通信

三、聊天室

四、很小的.exe文件

五、皮膚skin

六、速度超快0.5秒反應

七、聊天記錄管理器

八、語音

九、視頻

十、看誰在線上

十一、傳文件

十二、QQ表情

這道題難倒了不少產品經理。這裏提供兩種解答方法，一是基於騰訊當時實際狀況的解答(從當時實際狀況解答，比較現實)，另外一種是基於智能手機金字塔的解答(從如今角度出發，比較理想)。

基於騰訊當時實際狀況的解答

筆者跟騰訊公司最先的一批產品經理韓宇宙(Punk)，曾昭朗(Paul)和胡俊智(Kinzeer)探討過這個問題，他們給出了當時的答案是選一、三、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第一個測試版最重要的三項特性，可能就不是一、三、10的答案了。

使用金字塔的需求層次模型(配圖)來解答這道題目，從如今的角度和環境出發，簡單的方法就是：砍掉這些需求，產品還能用麼?

砍掉特性1「卡通頭像」，普通頭像的QQ也能夠用。砍掉特性12「QQ表情」，不影響產品使用。沒有特性7「聊天記錄器」，就不能使用QQ聊天了嗎?顯然是能夠的。這也解釋了MSN的聊天記錄保存功能並非默認地幫用戶勾選上的情形。

特性4「很小的.exe文件」是否是優先知足的需求?分歧比較大。不少人說當時電腦是撥號上網，網速很慢，「很小的.exe文件」應該是優選的三項 特性中的一項，是這樣麼?不是。試想一下，一款網遊，文件很大(好幾個G)，網速雖然慢，可是用戶就不去下載了嗎?顯然用戶仍是會去下載使用。再想一下， 其實每個新產品剛推出的時候，都是比較笨重粗糙的。用戶體驗依次是有用、能用、可用、用得爽和品牌，QQ文件太大，用戶獲取的成本有點高，可是還能用。

特性3「聊天室」是多人聊天，一對一聊天的需求尚未知足，就去知足多人聊天需求，顯然也不合理。砍掉特性11「傳文件」的功能，產品照樣能用，用 戶之間還能夠發文字信息溝通。特性8和9「視頻語音」也是同理。這樣分析下來，特性六、二、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