【產品方法論】如何確定需求優先順序

05-28

【產品方法論】如何確定需求優先順序

來自專欄互聯網視角

互聯網產品經理每天都會面對各種各樣的需求，分別來自不同的角色，包括用戶、老闆、同事等。可是團隊資源有限，面對需求池中如此多的需求，如何確定優先順序呢？這是很多產品新人面對的困擾。

通過和產品組同事一起小圓桌交流討論，結合自己實際項目經驗總結，現將其沉澱下來，並方法論化。

1、為什麼需要優先順序排序

首先，每個公司或者團隊資源是有限的，不控制需求的優先順序，產品可能永遠無法封閉，得不到想要的產出。就好比我每天下班，希望早點到家，但公司離地鐵站有點遠。回家的方案有走路或騎共享單車到地鐵站，然後坐地鐵回家。也可以直接打車回家。每種方式的成本和效益都不一樣。

其次，需求是經常變更。沒有哪個產品是完全按照預設出來的。中間總會因為各種原因導致無法按照預期步驟進行。可能市場環境變了，可能領導想法變了，可能.....這也是為什麼互聯網產品快速迭代不斷試錯。

2、現有需求優先順序排序理論

2.1 KANO模型

定義：KANO模型是對用戶需求分類和優先排序的有用工具，以分析用戶需求對用戶滿意的影響為基礎，體現了產品性能和用戶滿意之間的非線性關係。

KANO模型最初並非用於互聯網產品需求優先順序排序，而是提高企業服務的方法論，後由於與互聯網產品經理日常工作非常契合，開始逐步被大家熟知，並被廣泛應用。

KANO模型將用戶需求分為5個維度：基本需求，期望需求，興奮需求，無差異需求，反向需求。

具體每種類型需求的定義不累述，百度一下就有詳細的概念，通過上圖基本能夠理解。KANO模型的基本思想：通過用戶調研，測量每個用戶對於每個需求功能點進行評價，然後進行無差異化的滿意係數計算，得到一個優先順序排序。KANO模型優點是量化明確，從用戶角度出發，相對合理。不足之處在於，依賴用戶調研樣本，及調研過程中各種可能的差異。因此，實際工作中，這些用研結果僅作為一個需求優先順序參考，與實際產品數據結合來運用。

2.2 波士頓矩陣（瘦狗金牛）

定義：波士頓矩陣又稱市場增長率-相對市場份額矩陣、波士頓諮詢集團法、四象限分析法、產品系列結構管理法等。

波士頓矩陣也並非最開始用於互聯網產品需求優先順序排序，而是企業如何選擇更有前景的產品市場。將原有坐標進行更改，以適用於產品需求優先順序判斷。如下圖。

波士頓矩陣方法在《產品視角》書中也有提及，大家可以閱讀了解。瘦狗金牛方法運用類比手法，也將需求進行分類，包括4類：問題型需求、明星需求、金牛需求和瘦狗需求。瘦狗金牛方法的核心思想：瘦狗需求需要過濾掉，明星需求優先順序最高，金牛需求和問題需求則根據產品生命周期及產品定位等因素有先後。相對於KANO模型定量分析，瘦狗金牛方法則是一種定性的分析。

3、實戰中需求優先順序排序

實際工作中，上述理論並無法完全支撐需求優先順序排序。不是說上述理論無用，而是由於各種條件限制，導致的一種無序狀態，讓產品經理在實操過程中非常抓狂。我總結了以下思考的維度：

3.1 產品生命周期階段

談產品的生命周期，從《用戶體驗要素》中的5個層次來講，就是戰略層的思考。產品處於不同階段，側重點是不同的。處於引入期，能帶來新增的功能優先順序較高。新增達到一定量級的成長期，留存變得更重要。成熟期的產品，商業化變現逐漸重要起來。這主要是從產品的定位來考慮。有些產品從一出現開始，就是為了大量變現的，洗一波用戶就撤的。

3.2 影響範圍

需求的影響範圍是衡量優先順序的重要因素。直接影響產品的絕大部分核心目標用戶一定是優先順序高的需求，這是產品的基石。對於一個toC線上產品而言，核心功能至多2-3個，解決用戶的核心痛點。功能日活躍滲透率是個很好的衡量指標。

3.3 影響程度

痛點需求一般情況大於癢點需求。只有因為難用而死掉的產品，沒有因為難看而死掉的產品。A功能影響用戶基本使用，B功能能夠基本達到用戶要求，孰輕孰重？

3.4 投入產出比

投入產出比主要考量效益和成本。效益可以包含直接收入，運營效率及推廣成本，用戶的效益等。成本主要是人力成本、時間成本和金錢成本等。潛在風險有時候也是未來的一種成本。較小的成本獲取較高收益的需求一般優先順序較高。

3.5 老闆需求

老闆需求是產品經理無法避免的，而且一般優先順序較高。這主要是從需求來源的維度去考慮，有同事、用戶、老闆.....為什麼收老闆需求優先順序高？首先，老闆的經驗和思考高度一般是高於一般產品經理的。其次，老闆是直接為產品最終結果買單和負責的。最後，不按照老闆需求來，產品經理可以滾蛋了...這裡討論的老闆需求，不討論老闆需求的正確性。如果已經說服老闆調整需求優先順序，就不存在該問題。而是老闆就是要提高某個需求的情況下，且態度較明確。

3.6 目的明確，版本封閉

無論需求的優先順序多麼高，產品迭代的版本必須封閉。目前互聯網產品主要通過快速迭代方式進行，周期一般1-2周時間。一個版本開發周期越長，功能越多，延期風險越大，且問題是成倍的出現。一般情況下，對於影響重大，實時性非常強的需求才可臨時加入當前版本，否則加入下個版本。需求未能按時完成，為了按期版本封閉，常用方法為砍需求。

以上，通過現象，到理論，再到實戰中思考維度來說明如何確定需求的優先順序。最後，說了再多方法論，不如自己踩過的坑。