產品經理定義需求優先順序的四種方法
如何定義需求的優先順序也是挺能看出產品經理的能力水平的，在上一節已經詳細闡述了評估哪些需求該做，哪些需求不該做，對於已經決定要做的需求，這樣的需求數量很多，是現在做，還是以後做，不可能在同一時間內全部研發完畢，總得有先有後，優先順序高的需求優先研發，優先順序低的需求延後研發，這樣的話就涉及到需求優先順序定義的標準了，在產品實踐中，很多產品經理都是拍腦門決定先做哪些需求，後做哪些需求，要麼就是老闆拍腦門決定需求的優先順序，那到底定義需求的優先順序有沒有原則和方法呢？
先來說說原則，在日常生活中，處理任務的優先順序有四種情況：重要且緊急；重要不緊急；緊急不重要；不緊急不重要。這四種情況也是我們處理需求優先順序的原則，即重要性+緊急性。把需求的重要性+緊急性統稱為商業價值原則。基於這個商業價值原則，《神一樣的產品經理》一書中主要闡述了需求優先順序定義的四種方法。
1、新產品未上線
新產品未上線這種情況指的是產品從無到有的這個過程，這種情況因為沒有相關的運營資料做支撐，所以從需求對使用者的重要性和緊迫性來判斷需求的優先順序是一種比較合理的優先順序定義方法，那麼如何判斷需求對使用者的重要性呢？
一般情況而言，使用者需求重要性： 基本型需求>期望性需求>興奮型需求。
使用需求的金字塔法則來表達，金字塔的最底層是基本型的需求，往上是期望型需求，最上面一層是興奮型需求。基本型需求是必須有的需求，沒有的話使用者基本使用不了產品，如果金字塔最底層被砍掉的話，這個需求的金字塔就可能站立不穩而倒下，所以基本型需求的重要性最高，期望型的需求是使用者期望能有的需求，使用者希望越多越好，但是如果金字塔的第二層被砍掉的話，需求的金字塔不會受較大的影響，因為最底層的需求還在，使用者還能繼續使用產品，所以期望型需求重要性要低於基本型需求。興奮型需求是超出使用者預期的需求，有的話可以給產品加分，沒有的話也無大礙，如果我們砍掉金字塔的最頂層，需求的金字塔更加不會受到影響，因為基本型需求和期望型需求都存在，使用者還能繼續使用產品，所以說興奮型需求的重要性要低於期望型需求。其實我們從金字塔的建造過程來看，也是先建造最底層，然後是中間層，最後是最高層。
需要特別注意的是每個使用者心裡的基本型需求、期望型需求和興奮型需求是不完全一樣的，是千差萬別的，比如說有的使用者認為期望型需求是基本型需求，而有的使用者認為興奮型需求是基本型需求，這也隨著時間在動態變化，甚至衰減，所以產品需求優先順序的定義也要根據當時的實際情況來定。
是不是明確需求的重要性之後就可以判斷需求的優先順序了呢，這裡面還需要加上一個因素，即緊迫性。基本型需求重要性最高，且也最緊迫，所以基本型需求的優先順序預設是最高的。
一般情況下，肯定是先做基本型需求，在研發基本型需求的同時，有時候因為運營、營銷、銷售等業務需求的迫切需要，會同時研發一部分的期望型需求（重要不緊急）和興奮型需求（緊急不重要），主要是製造產品的亮點和賣點，在市場上與競爭對手形成差異化或者品牌區隔，也有利於產品上線初期憑藉期望型需求或興奮型需求贏得使用者良好的口碑。
案例：智慧手機的金字塔需求
先來看看智慧手機的金字塔需求，如下所示：
智慧手機的金字塔需求
智慧手機的金字塔需求一共5層，最底層是第1層，往上是第2層，直到第5層。
通過分析，不難發現，第1層和第2層屬於基本型需求，第3層和第4層屬於期望型需求，第5層屬於興奮型需求。如何評定哪些需求是基本型需求，簡單方法就是：砍掉這些需求，這個產品還能用麼？
案例：使用者需求優先順序排序
案例來源於騰訊公司內部的產品培訓。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表情
這道題難倒了很多產品經理，很多產品經理考慮到當時的網路環境和背景，對這道題的答案有較大的分歧。在這裡提供兩種解答方法，一種是基於騰訊當時實際情況的解答（從當時角度出發，比較現實），一種是基於智慧手機金字塔的解答（從現在角度出發，比較理想）。
（1）基於騰訊當時實際情況的解答
筆者跟騰訊公司最早的一批產品經理韓宇宙Punk，曾昭朗Paul和胡俊智Kinzeer曾經探討過這個問題，給出了當時的答案是1，3，10。至於為什麼選擇1，3，10？從當時角度出發，理由闡述如下：
在當時情況下，早期的IM競爭對手有，有13家左右，各有一些特色，從單純的功能上而言，QQ的功能並不突出。真正促使QQ讓使用者很HI的主要有兩個地方：
第一個是卡通頭像，讓使用者活了起來，它不算是啥功能，但是是使用者情感需要很重要的出口。當時QQ的頭像第一批用的是迪斯尼的，因為使用者對這個經典頭像熟悉，容易對號入座，有情感認知。當時都是70後嘛，這一代對迪斯尼，藍精靈等比較熟悉。這些在當時選型時，都有考慮的。
QQ和其他IM不一樣的地方，是有一個聊天室，而且是客戶端形態的，所有的IM都要解決一個問題，就是使用者從哪來。QQ聊天室解決了使用者從哪來的問題，因為早期的使用者習慣聊天室，對IM還不熟悉和習慣，更談不上熟人關係。當時的環境和現在不一樣，使用者上了QQ後，使用者的QQ上沒有人，所以聊天室，是早期QQ使用者聚集的地方，並因此互相加好友，從陌生變熟悉。其他IM的使用者關係，一直是相對陌生的，而QQ的關係鏈是從聊天室的陌生，轉化為比較熟悉，是有一定的社群關係的，然後再相互加一下QQ，很好的解決了使用者QQ上沒有任何好友的問題，有了好友，使用者才會持續用QQ。最重要的需求在於怎麼解決使用者持續使用QQ，所有的功能先圍著這個來轉。QQ客戶端的聊天室是客戶端形態，因此聊天室的體驗比當時Web 要好很多，功能強很大，而且還引入了社交化的體系，還有金字塔管理體系，讓大量的使用者每天都進入固定的聊天室相互熟悉，泡妞，有很強的成熟感，這批使用者後來也成為QQ論壇的核心使用者。聊天室為QQ使用者貢獻第一批好友，有點社群關係的好友。由於有這些好友，才有持續的動力上來和這些好友進行互動。
一開始，QQ安全性很低，隨便都能偷QQ，使用者都還不習慣用這個產品，做得再安全又怎麼樣，關於安全這東西，在早期的網際網路使用者上，不存在這個考慮。不要用現在的安全意識來評估當時的環境。效能的話，從技術的角度咯，當時的機器就那樣，軟體再怎麼優化也是看不出來的。第一代的密碼保護是02年底才有的，02年之前的QQ暴力破解就可以得到本地密碼的，很弱。03年之前的密碼保護也很弱，隨便進後臺就可以更改密保和密碼。當時的IM還太技術化，但產業環境和使用者習慣未到那個層面。比如說音訊視訊這東西，說真的，當時56K貓上網，支撐不了這個，大家都不用，並且網戀的風行，使文字聊天更有想像空間。
正如馬化騰所說的：“exe小是結果，不是規劃出來的，第一個版本想寫成大也寫不出。簡而言之，10秒內找到人聊，且頭像有趣是最樸素的需求，還有一個是好友儲存在伺服器端，換電腦也可以恢復。”
總的來說就是表情頭像讓使用者很HI，畢竟要找人聊天，得知到誰在線上，而聊天室解決的是使用者從零關係到弱關係再到強關係的問題，解決了第一批種子使用者的問題。
從某種程度上來說，在當時環境下，卡通頭像屬於使用者的興奮型需求，聊天室屬於使用者的期望型需求，看誰在線上屬於使用者的基本型需求。
產品跟運營是不分家的，從這個案例可以看出，雖然是新產品未上線，但是已經開始有以運營為導向的元素出現，因為運營需求的迫切需要，研發一部分需求來製造產品的亮點和賣點，在市場上與競爭對手形成差異化或者品牌區隔。
在介紹KANO模型的時候也闡述過使用者需求是一個隨著時間在動態變化的過程，如果以現在的角度來選擇最重要的三項特性，可能就不是1，3，10的答案了。
（2）基於智慧手機金字塔的解答
使用金字塔的需求層次來解答這道題目，上面已經闡述過智慧手機的需求金字塔，如何評定哪些需求是基本型需求，從現在的角度和環境出發，簡單方法就是：砍掉這些需求，這個產品還能用麼？
砍掉卡通頭像，產品還能用，產品剛開始的時候使用普通頭像也是可以的。砍掉QQ表情，產品還能用，不影響使用。沒有聊天記錄器，就不能使用QQ聊天了嗎？顯然是可以的，這也解釋了MSN的聊天記錄儲存功能並不是預設幫使用者勾選上的。很小的.exe檔案，在這方面分歧比較大，很多人說當時是用貓撥號上網的，網速很慢，很多人認為很小的.exe檔案是最重要三項中的一項，是這樣麼？答案不是，試想一下，一款網遊好幾個G，檔案很大，網速雖然慢，但是使用者就不去下載了嗎？顯然使用者還是會去下載使用，再想一下，每一個新產品剛推出的時候，都是比較笨重粗糙的，比如以前最初的計算機龐大得可以佔用整個辦公室，攜帶非常不方便，回過頭來再看看今天的電腦，小巧、輕薄了很多，所以說很小的.exe檔案不是最重要的三項之一，可以理解為從使用者體驗角度來說，檔案太大，使用者獲取的成本稍微有點高，但是使用者體驗的層次是有用、能用、可用、用的爽和品牌，檔案雖然比較大，但是還能用，產品前提的條件是有用。聊天室是多人聊天，一對一聊天的需求還沒有滿足，就去滿足多人聊天需求，顯然也不合理。砍掉傳檔案的功能，產品照樣能用，使用者之間還可以發文字資訊溝通。視訊語音也是同理。這樣分析下來，反映速度快、安全性和看誰在線上是最重要的三項，這跟智慧手能的金字塔需求也是匹配的。如果反映速度太慢，基本上是用不了，使用者在使用過程中會崩潰。如果1.0的版本很容易就被黑客攻擊，導致癱瘓，照樣也使用不了，再說了，QQ上都是自己的社交關係聯絡人，是比較隱私的，一旦被人盜用不堪設想（尤其是2011年12月震驚圈內的因黑客攻擊導致知名網際網路公司密碼洩露的“密碼門”事件，無疑給網站主敲響了網站安全的警鐘，提高了安全需求的優先順序。）。要想跟人溝通，首先要知道誰在線上，這是最基本的。
此外，在產品實踐中，很多產品的成功具有時效性，有的產品在當時的環境雖然成功了，但是在現在的環境下複製這種曾經成功的模式，不一定見得會成功，所以通過QQ這個案例，至少可以得出三點結論：一是需求優先順序的定義要基於當時的環境和實際情況；二是使用者需求是一個動態變化過程，需要適時調整；三是產品與運營不分家，在確保滿足基本型需求的同時，也要適當考慮滿足使用者期望型和興奮型的需求。
2、免費型產品已經上線
免費型產品已經上線這種情況指的是全部免費型產品（全部功能免費）或者部分免費型產品（有些功能免費，有些功能收費）從有到優（調優）的這個過程，這個時候因為有了運營資料的支撐，通過運營資料，能聚類分析出使用者的行為，甚至可以給使用者畫像。那麼如何定義需求的優先順序呢？這裡還是採用需求的商業價值原則，即重要性+緊迫性原則。前面已經闡述過，使用者有需求，產品利用相應的功能或內容來對應和滿足需求，可以根據功能的使用率，使用次數和重要性，形成一個需求重要性的計算公式，根據計算的結果和緊迫性來定義需求的優先順序。
現在網際網路和移動網際網路產品形態很多，比如Web、桌面客戶端、第三方平臺App、WAP、iPhone客戶端、Android客戶端、iPad客戶端等等，使用者對每一種終端產品的需求是不一樣的，所以不能機械地認為使用者對各種終端產品的基本型需求、期望型需求和興奮型需求是一樣的，這裡要區分對待。對於要做跨終端產品的公司尤其要注意。比如，在使用Web 產品時，可以使用滑鼠滾輪滾動頁面閱讀隱藏在下面的內容，能不翻頁就儘量不翻頁，因為使用者比較習慣；而在iPad客戶端產品上，從上而下滾動頁面，需要使用手指自下而上滑動，使用者使用起來有點彆扭，很多App產品，尤其閱讀型產品，改成了手指自右向左的橫向滑動閱讀未讀的內容，使用者使用起來比較自然。
使用者需求重要性的判斷標準：使用者基數、使用次數和類別重要性。類別重要性分成基本型、期望型和興奮型需求三類。
對於基本型需求，比如產品的效能、安全、瀏覽器相容等方面，一旦出現問題，使用者不能訪問使用產品的情況，應該立馬放下手頭的工作，利用一切可利用的資源儘快解決這方面的問題，在有的公司稱為“911bug”，屬於最高級別的bug，優先順序最高。比如說網站被黑了，或者使用起來非常慢，使用者快崩潰了，這個時候應該想方設法儘快解決，試想一下，如果使用者訪問或使用不了你的產品，即使你的產品功能多麼地強大，做得多麼地好，使用者也享受不到啊，這個時候如果還是投入資源做期望型需求和興奮型需求，等辛辛苦苦做完了，使用者也就流失掉了，這是一個常識。
對於期望型需求和興奮型需求，可以通過運營資料，形成公式計算。
需求對應相應的產品功能，使用者需求重要性=功能使用使用者百分比（使用者使用率）x功能使用次數百分比（功能或內容使用率）x類別重要性百分比（期望型需求、興奮型需求），注意：最底層的基本型需求不在計算範圍內，因為預設為最高級別。這個需求級別公式就是綜合考慮有多少使用者需要、使用者經常需要還是偶爾需要、對使用者重要還是不重要三個因素。
比如說有功能相對來說類別重要性雖然高一些，但是使用該功能的使用者數和使用者次數卻比較少；有的功能相對來說類別重要性雖然低一些，但是使用該功能的使用者數和使用者次數卻比較多，那麼根據上述公式計算後得出的結果有可能是類別重要性比較低的功能整體重要性要高於類別重要性比較高的功能整體重要性。
關於計算公式舉例：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、前置後置條件
前置後置條件指的是有時候必須先完成A功能，然後才能做B功能，從需求的優先順序來看，A功能的需求優先順序肯定要高於B功能的需求優先順序。A功能的重要性和緊急性都要高於B功能。
總的來說，上述四種定義需求優先順序的方法，在公司範圍內，在特定的產品階段，是可以搭配使用的。需求優先順序定義的原則基本上是一樣的，都是商業價值原則，即重要性+緊急性。
不管在哪一種方法下，基本型需求的優先順序永遠預設是最高級別的，至於期望型需求和興奮型需求要根據具體的實際情況使用方法的一種或幾種方法搭配使用，而不是再用拍腦門來決定需求的優先順序。特別注意的是，上述的內容都是圍繞需求的優先順序來展開的，是從產品人員的角度來說，但是從研發人員的角度來說，畢竟受到各種人力、物力、財力的限制和影響，並不能完完全全按照產品人員確定的需求優先順序來進行研發，基於產品人員確定的需求優先順序，研發人員基於開發資源提出相應需求優先順序的研發優先順序。至於研發優先順序如何定義，將在下一節管理需求中作詳細闡述。
REF
- ofollow,noindex">http://blog.sina.com.cn/s/blog_4ff1764801012sod.html
原文連結 https://www.devzhao.com/post/1e21d5b5.html
轉載時請註明出處，謝謝合作。