一、 需求的優先級怎么定義？
很多產品經理，包括我，一定都會遇到這樣的場景：“ 需求堆如山，什么都想做 ”。
面對各種各樣、來自各個渠道的需求，產品經理的工作職責之一，就是梳理需求的優先級。我們不可能毫無選擇、毫無優先級地挨個實現所有需求，因為無論公司規模大小，時間資源和開發資源往往是有限的。任何事情，都講ROI（投入產出比），追求效率利益最大化的公司，更是如此。因此我們需要篩選出價值最大、影響面最廣、正收益最大的需求來實現，這就要對需求進行優先級排列。
要對優先級進行排序 --> 就不可避免地要對其進行量化
要對其量化 --> 就要搞清楚影響優先級的因素有哪些1. 影響面
首先，這個功能預估會影響多少用戶，很大程度上決定了這個功能的影響面。覆蓋用戶數量越大，重要程度也越大。其次，用戶的使用頻率，在另一個維度上決定了影響面的大小。影響面 = 覆蓋用戶數 x 用戶日使用頻次
例如一個影響500人的功能，每人每天使用10次，與一個影響1000人的功能，每人每天只使用1次，前者影響面可以簡單的計算為500 x 10 = 5000，后者為1000 x 1 =1000。雖然前者覆蓋用戶數量只有后者的一半，但前者的影響面卻要比后者大。2. 體驗提升度
要獲知體驗提升度，就需要按照具體需求類型來看，需求一般大體可以分為：新增功能模塊（如：新增想法Tab，用戶可以分享交流想法）、優化功能（如：多步驟流程，通過預填寫抓取字段來降低用戶的輸入成本）、完善功能點（如: 為用戶的收藏夾提供分類標簽的功能，以便于用戶管理數量較大的收藏內容）
體驗提升度的評估一般由產品、用戶調研來估算。
值得注意的是，這里的“提升度”是一個相對差值，因為在開發某項功能之前，用戶可能已經找到其他的替代方案了，當你開發了一個新的功能后，一定會帶來額外的成本，包括：學習成本（取決于功能在理解層面的復雜程度）、遷移成本（用戶從原有的習慣遷移到新的需要額外付出的成本）、機會成本（例如在收集表單時，預填字段大概率能節省用戶的時間，但是也有可能會給用戶帶來額外成本，當預填字段與用戶想要輸入的內容不符，用戶需要手動刪除，這就是機會成本）。3. 研發成本
有些需求是可以單純客戶端 / 前端就可以完成的，實現成本一般較低，靈活度低（需要發版），例如：將圖片的尺寸放大、緩存記錄用戶的近期輸入數據等；還有一些是需要服務端與前端配合，不需要發版，這種需求相對來說實現成本中等，靈活度適中，例如想要在原生App內嵌套的H5頁面進行優化，不需要發版本，相對靈活，但可能需要服務端的配合；還有一些功能開發需要全端配合，服務端甚至要開單獨的表來寫入讀取數據，這種就需求開發成本大，靈活度低。
除此之外，還要考慮到后續的維護成本、運營成本，這些都是衡量一個需求的研發成本的重要指標。
我們可以簡單抽象為一個公式，來衡量一個需求的收益：
收益（Return） = 待解決問題影響面 x 解決問題后體驗提升度 - 研發成本
二、 對優先級進行排列
有了上面的公式，是不是就代表，我們按照收益得分倒序排列，然后就可以交給開發，依次從上到下實現所有收集到的需求了呢？答案是否定的。
要知道，很多需求，盡管收益得分非常高，但大概率開發成本也是巨大的，甚至需要幾個大版本、數十人的開發團隊，數月的工作才能實現。如果我們將這類需求放置于開發列表的第一條，那就太不劃算了，這就好比，在一場時間有限的考試中，拿到試卷專挑分數最高，但難度也最大的壓軸大題開始下手，啃了半天，時間過去了，會做的題目也沒有時間作答了，這是很不經濟的。
為了解決這個問題，我們創建一個二維圖表，橫軸代表需要投入的成本，縱軸代表預估收益，我們可以將這個二維圖表分成四個部分：

1.Quick wins：屬于投入低、收益高的需求，我們應該盡可能地多發掘這類需求，盡可能多開發實現這類需求；2. Major projects：屬于投入高、收益也高的需求，這類需求意味著投入開發成本會比較高；3. Fill ins：投入低、收益低的需求，有多余資源就做；4. Thankless tasks：投入高、收益低的需求，對于此類需求，我們應該盡可能避免，因為它們會浪費大量的開發資源，卻無法獲得良好的收益。
參考閱讀：The Action Priority Matrix