核心概念

優先排序是產品管理最核心的判斷能力——需求永遠多過資源，錯誤的排序會讓團隊在不重要的功能上消耗開發容量。框架的作用不是消除判斷，而是結構化判斷過程，讓決策透明、可辯論、可複查。

三個最常見的框架各自解答不同的核心問題：

RICE（Reach × Impact × Confidence ÷ Effort）

RICE 是目前使用最廣泛的量化排序框架（約 38% 的團隊採用），核心邏輯是透過四個維度的計算產生可比較的分數。

  • Reach（觸及人數）：這個功能在一段時間內（通常一個月或一季）會影響多少用戶？用具體數字，例如「每月 2000 位活躍用戶」
  • Impact（影響程度）：對每個被觸及的用戶產生多大影響？使用固定量級：0.25（極小）/ 0.5（小）/ 1（中）/ 2（大）/ 3（極大）
  • Confidence（信心程度）：對以上估計有多確定？有用戶資料支撐 → 80%；有間接資料 → 50%；純猜測 → 20%
  • Effort（所需工作量）：完成此功能需要多少「人月」？

計算公式：RICE = (Reach × Impact × Confidence) ÷ Effort

分數越高代表 ROI 越高，應優先執行。RICE 最大的價值在於強迫考慮「觸及人數」，防止過度在意少數高聲量用戶的需求，讓小眾痛點被誤判為全局優先級。

ICE（Impact × Confidence × Ease）

ICE 是 Sean Ellis（GrowthHackers 創辦人）設計的輕量評分方式，三個維度全用 1-10 分評估：

  • Impact（影響）：成功執行後對目標指標的影響有多大？
  • Confidence（信心）：估算有多少把握？
  • Ease（難易度）：實作難度如何？（注意是容易度，越容易分越高）

計算公式：ICE = Impact × Confidence × Ease（或三項相加）

ICE 刻意犧牲精確性換取速度，適合每週迭代的成長實驗。每個 ICE 條目必須附上一句話假設（例如「我們相信 X 會導致 Y，因為 Z」）和防護指標，避免分數淪為無意義的直覺投票。

MoSCoW（Must / Should / Could / Won't）

MoSCoW 不排序，而是分類。它的問題不是「哪個更重要」，而是「這個版本的邊界在哪裡」：

  • Must-have：這個版本不做就無法上線的功能（法規合規、核心流程、安全性）
  • Should-have：重要但可有替代方案，不影響上線
  • Could-have：有時間就做，沒時間可延後的增益功能
  • Won't-have（this time）：明確排除本次版本，記錄在案防止需求蔓延

關鍵原則：Must-have 不能超過開發容量的 60%；保留 20% 給 Could-have 吸收不確定性；Won't-have 必須明確記錄，讓利害關係人知道什麼是「未來版本的事」而非「被遺忘的需求」。

關鍵要點

三個框架回答不同的問題

框架 核心問題 輸出
RICE 這些功能哪個 ROI 最高？ 排序後的數字分數清單
ICE 哪個實驗值得先跑？ 快速排序清單
MoSCoW 這次版本的邊界在哪？ 功能分類（Must / Should / Could / Won't）

何時用哪個框架

  • 季度規劃、backlog 有 20+ 個候選功能 → RICE
  • 成長實驗、每週 sprint 快速決策 → ICE
  • 版本發佈規劃、MVP 範圍確認、跨部門對齊 → MoSCoW
  • 技術債與功能混在一起需要統一比較 → RICE（可跨類型打分）

常見錯誤

  1. RICE 的 Impact 用主觀大中小代替固定量級：導致不同人的估分無法比較，框架失去意義
  2. ICE 只打分不寫假設：高分功能執行後無法驗證原始假設，學習循環斷裂
  3. MoSCoW 的 Must-have 超過 60%：等於把所有東西都說成必要，需強制二次排序
  4. 長期只用同一個框架：RICE 適合季度規劃，ICE 適合週迭代；混用才能覆蓋不同決策時機

與北極星指標的結合

排序框架需要錨定目標才有意義。RICE 的 Impact 應對照北極星指標與產品數據體系設計定義的核心指標打分——「這個功能提升了多少用戶活躍度？」而非「這個功能感覺上多重要？」

實務應用

季度 roadmap 規劃（RICE）

團隊有 15 個候選功能，需選出下季 5 個。用 RICE 打分：先定義 Reach 的時間窗（一個月活躍用戶），對每個功能估 Impact 量級（固定 5 段），最後評估 Confidence（有用戶訪談資料或 A/B 數據的打 80%+，否則 50%）。分數最高的通常不是最複雜的功能，而是觸及廣、實作輕的功能——這正是框架的核心貢獻。

MVP 範圍確認（MoSCoW）

在MVP 假設驗證與實驗設計階段，MoSCoW 特別適合和利害關係人對話：請每個人把功能分進四格，再對比差異。「這個功能有人說 Must、有人說 Could」正是需要深入討論的地方，而非用多數決跳過。

成長團隊每週實驗選題（ICE）

成長團隊有 8 個本週候選實驗，ICE 在 30 分鐘內決定跑哪三個。每個實驗先寫一句假設，再打 Impact / Confidence / Ease 分，最後按總分排序。

延伸觀點

框架失效的共同根源：缺少目標錨點

多個產品管理研究者都指出，三個框架都有同一個失效模式：在沒有明確目標的前提下使用。RICE co-developer Sean McBride 建議「專注在單一季度目標」——對照目標打分，而非對照「功能感覺上多重要」；Agile Insider 的研究則更直接指出 MoSCoW 在沒有用戶目標錨定時是「劇場排序」（prioritization theatre），產出的 Must-have 清單反映的是利害關係人偏好，而非用戶需求。結論是一致的：框架只是工具，沒有目標錨點，任何框架都會淪為高層拍板的包裝。

B2B 情境下 RICE 的 Reach 需要改寫

在 B2B 產品中，「觸及用戶數」本身不夠用——一個 $100k 合約客戶和十個 $1k 客戶的觸及數字可能相同，但業務影響截然不同。Clement Kao 建議將 Reach 抽象為帳戶層級的營收影響（Account Revenue Impact），才能讓 RICE 在 B2B 場景下真正反映優先級。這個改寫原則可以推廣：框架的變數定義應該隨商業模式調整，而非硬套 B2C 的預設值。

MoSCoW 的現代替代方案：Now / Next / Later

MoSCoW 遭到批評的部分原因是分類太靜態——Must 和 Won't 之間缺乏流動性，且「四格」容易讓所有功能都擠進 Must。部分敏捷實踐者轉向 Now / Next / Later 框架：Now（當前 sprint 執行）、Next（下一個週期候選）、Later（未來考慮）。這個三層架構更接近實際的迭代節奏，也更容易在每週 backlog grooming 時更新，而不是只在版本規劃時才啟動一次。對已有 RICE 做季度排序的團隊，Now / Next / Later 可作為週層級的輕量補充。

反向連結

以下頁面引用了本頁：