Sign in Subscribe

產品功能開發排序邏輯: RICE/ROI

這是這個系列的第五篇，我終於要寫到自己實際在用的東西了。除了艾森豪矩陣之外，另一個在面試時有聽過幾次的排序方法是 RICE 以及其各種變形。這套方法（的其中一個變形）也是我後來採納、並且實際帶進團隊裡的排序方式。

產品功能開發排序邏輯: RICE/ROI

這是這個系列的第五篇，我終於要寫到自己實際在用的東西了。除了艾森豪矩陣之外，另一個在面試時有聽過幾次的排序方法是 RICE 以及其各種變形。這套方法（的其中一個變形）也是我後來採納、並且實際帶進團隊裡的排序方式。

四種要素與計算

RICE 是由知名的軟體公司 Intercom 所提出的排序方式（同一公司針對蠻多不同事情分享過他們的方法論，例如先前速攻型讀書會也有看過他們提供的 JTBD 手冊）。這四個英文字母是「Reach、Impact、Confidence、Effort」的縮寫，本質其實跟先前提過的價值/複雜度矩陣一樣，在探究投資報酬率（ROI）這件事情：

  • Reach 人數: 一段時間內能接觸到多少使用者/產生幾次特定事件（例如「交易」）？這個「一段時間」只要是固定的就可以了，實際的長度方便定義即可。
  • Impact 影響力: 對單一使用者可以造成多大影響？這是一個主觀數字，Intercom 那邊建議的是 0.25（Minimal）、0.5（Low）、1（Medium）、2（High）以及 3（Massive）。
  • Confidence 信心: 我對以上兩者有多有把握？是個百分比或小數點。
  • Effort 投入: 要花多少力氣才能交付？Intercom 使用的原版是「人月（person‑month）」，實務上也是訂一個版本就可以了，設計開發測試都包含在內。

四種值都知道以後，計算方式很簡單：

RICE 分數 ＝ ( 人數 × 單人影響力 × 信心 ) ÷ 投入

算完分數，把候選項目的 RICE 值由高到低排，就能快速且有其根據地抓出可以先動手的事情。

變形：ROI Scoring

我個人不是個很愛過度展開的人，比方說我蠻喜歡行銷 4P/4C 這種一體兩面的框架論述，但看過幾種數字部分超過 4 的版本，就認為切得太細、反而會引人落入填表交差的心情，忘記深入思考。

所以前面的 RICE 我其實偏好更簡潔地想成是 ROI，此時 R 的部分是這件事情會產生的效益、I 的部分則是要投入的努力，另外加上信心度，那麼公式就會變成這樣：

( 報酬 × 信心 ) ÷ 投資

無獨有偶，在《Product Roadmaps Relaunched》這本書裡描述了這樣一組非常相似的公式：

Value ÷ Effort × Confidence 
= (Σ Customer Needs + Σ Business Objectives) ÷ Σ Effort × Confidence

這邊導入了前面幾篇提過了數次的重點：商業組織自己的目標 — — 事實上，前面一整塊價值我們都可以簡單地看做「這間公司現在重視什麼」，如果策略上認為需要針對某些使用需求再多點著墨、那這邊的分數就放進去；如果認為拓展海外市場是未來十年大計，那這邊的分數也放進去。

BTW 後來我才知道 RICE 也有單純稱為 ICE 的版本（不特別將 reach 拉出來），誰先誰後就沒探究了，原理都是相同的。

企業重視的價值與 OKR

「重視什麼」要從哪裡來呢？如果公司採行 OKR，這是個將 OKR 納入產品功能排序邏輯的絕佳機會。你面對的可能是這樣的東西：

Objective 1 打造絲滑的新手體驗，讓首次使用者立即感受到產品價值 
KR 1.1 - 新用戶首次完成「播放一支影片」的成功率由 25 % 提升至 55 % 
KR 1.2 - App onboarding 流程完成率由 60 % 提升至 85 % 
KR 1.3 - 針對新用戶進行 ≥ 30 份深度訪談，蒐集「前 15 分鐘體驗」痛點並完成洞察報告 
KR 1.4 - 運用 A/B test，至少 迭代 3 個版本 的首次登入流程

那麼會對這四個 KR 有幫助的或許就可以在「價值」的層面拿到分數。又或者如果你管理的範圍更大，面對的可能是這樣的東西：

Objective 1 深化市場滲透，強化產品-市場契合度（PMF） 
KR 1.1 - 季度新客成交率（PQL → 客戶）提升 +10 pp，達 32 % 
KR 1.2 - 重點 ICP 客戶（500–5,000 員工）平均啟用率 ≥ 85 % 
KR 1.3 - 針對三大流失原因完成客戶驗證迭代各 1 回，並使對應流失率較去年同期降低 20 % 
KR 1.4 - 「北極星指標」關鍵子指標（平均單一客戶活躍帳號比例）提升 15 % 
 
Objective 2 提升功能交付速度與品質，確保策略落地 
KR 2.1 - 已承諾 Roadmap 項目之準時交付率 ≥ 90 % 
KR 2.2 - 上線功能於首 30 天內 P0-P1 bug 率 < 0.3 % 
KR 2.3 - 核心功能從「需求凍結」到「首批客戶可用」Lead Time 縮短 25 % 
KR 2.4 - 對應營收影響 ≥ US $50 k 的功能，皆建立完整成效追蹤儀表板，覆蓋率 100 % 
 
Objective 3 賦能產品團隊，建立可持續的高效協作文化 
KR 3.1 - 四位 PM 全員完成年度成長計畫（IDP），並完成 2 × 成長行動 
KR 3.2 - 跨職能利害關係人（Eng／UX／CS）對 PM 團隊的 eNPS 由 +18 提升至 +40 
KR 3.3 - 新品或重大改版決策前，Discovery 流程符合「雙鑽石」檢核清單比率 = 100 % 
KR 3.4 - 每月舉行產品策略會議 ≥ 2 場，並公開筆記與行動 
 
Objective 4 精準控管單位經營成本（Unit Economics），提升利潤率 
KR 4.1 - 單位毛利率（Gross Margin / 帳號）提升 +5 pp，達 72 % 
KR 4.2 - 雲端維運成本佔 ARR 比例降低 8 %（rolling 12 m） 
KR 4.3 - 付款逾期帳戶的應收天數（DSO）減少 10 天 
KR 4.4 - 完成「使用量導向定價」試點並交付可行性報告 + 財務模型

你可能就需要訂立稍微複雜一點的加權，比方說為不同的 O 設定不同權重等等。但也需要切記，我們的目標是快速排個序，不是錙銖必較的學術研究，複雜到沒人想要認真探究的話也是失敗；《Product Roadmaps Relaunched》其實甚至建議用 1–5 這樣的簡單數字來算就好，看官就自行斟酌吧。

BTW，希望你們公司的 OKR 是玩真的，不是的話這邊改成用產品策略訂可能好一些。

關於投入部分的估算

投入的部分依據 RICE 是用人月，或者現代節奏比較快也許用人天。初期幾次大概會遇到這樣的對話：

產品: 可否請你大略估算一下可能需要投入的時間？ 
開發: 資訊這麼粗糙我是要估什麼？

畢竟我們更可能是要拿著這個排序後的順序去決定規劃順序，這個階段裡沒有細緻規劃也是合情合理 — — 但，被要求估算的人也一定有各種陰影，比方說怕被拿來當作畫押證據等等。

《Product Roadmaps Relaunched》傾向的解法是用 T-shirt Size 估，也行；我自己的做法則是用費式數列，想辦法說服開發人員：如果兩天做不完的，你就直接告訴我是三天了，反正我也是當個參考。

使用 RICE/ROI 法的優點

  1. 邏輯穩固：搭配 OKR 以後中間每個環節大概都能很容易說服人，畢竟投資報酬率是種人人聽得懂的東西
  2. 「信心值」某種程度上暗示不需 100% 確定才開工：這也是當代社會的必須，要 100% 確定一件事情的話，可能到失去所有 time to market 契機後仍不可得。
  3. 可以應對非常龐大的清單：即使是數百條待辦事項，拉幾個人快速過一下也可以很快就有結果，且這個結果是參與的人都知道怎麼產生的。

缺點

  1. 估算誤差：Value（Reach 與 Impact）一定會有假設成分在，說要科學也不是所有數字都一翻兩瞪眼，且…
  2. 也許有點過度追求量化：看起來好像很數學，但實際上中間當然還是有些元素需要靠假設而來，不應過度迷信數字本身
  3. 權重遊戲：雖然《Product Roadmaps Relaunched》是期待大家不要做太多數學運算，不過如果對到的團隊很多，這邊免不了（大家本質上仍然相信數字是理性的…） ；但如果頻繁調整加權，分數可能被「調教」出想要的結果。

如果你要用 ROI 表的話，這些想法給你參考

  • 用試算表自動計算：在 Google Sheets 或 Excel 裡建立公式，把 Reach、Impact、Confidence、Effort 四欄直接引用 backlog 資料，分數隨欄位更新即時重算，省去手動複製貼上的時間，也方便版本控管。
  • 全員參與、共享假設：讓相關的人員都能夠直接參與，填寫或調整自己負責項目的 RICE 參數，並利用註解功能記錄資料來源與推論，會比較增加這套邏輯在大家心中的信任程度。
  • 把相近分數視為同一級：這都只是估算值，不要執著在小數點。一旦分數差距不高（比方說 10% 內），就當作同一級，再由 PM 參酌資訊（策略急迫性、時程、市場…）提出判斷。太執著在小數點容易誘引眾人作弊，那就不是我們想看到的事。
  • 目標變動就即時校準：當 OKR 或 North Star 指標更新時，立即調整 Impact 欄位的權重或定義，並將與新目標無直接關聯的功能 Impact 設為 0 或標註 N/A，避免舊分數干擾決策；同時保留前版工作表以便回溯。
  • 好好考慮溝通方式：「ROI」這個想法人人都吃、不難取得理解，但需要用這個等級的排序工具也許表示牽扯的環境比較複雜，那麼各種立場相異或者隔閡的問題可能也很難免得了。如果評估都有所本，那麼數值一出來，除了「信心值」以外不太容易有什麼操作空間，但也許你還是得先確保組織內的糕層願意吃這套，同時也要做很多努力避免其在過程裡淪為… 「過程」。

其他這個系列的文，沒連結的就是還在寫/還在富奸：

我不時會在 LinkedIn 或 Facebook 分享些關於產品管理的看法/見聞/活動，另有讀書會跟線上諮詢，有興趣可以前往 https://www.bobchao.net

如果你覺得這篇還不錯的話，何不幫我按幾下掌聲，幫助演算法讓這篇飄遠一點，幫助其他跟你一樣的人？

Read next

Comments ()