प्राथमिकता की कला
दस फ्रेमवर्क और सही चुनने की समझ में महारत हासिल करें — पाँच लाइव सिमुलेटरों के साथ अभ्यास करें।
Explainer
प्राथमिकता-निर्धारण वस्तुनिष्ठ रूप से सही सूची बनाना नहीं है। यह मूल्य, विश्वास, समय और बाधाओं पर एक संरचित बातचीत है। ढाँचा ईमानदारी के लिए एक forcing function है — अंतर्निहित धारणाओं को स्पष्ट करने और असहमति को सामने लाने का तरीक़ा। ग़लत प्रश्न है 'कौन-सा ढाँचा सबसे अच्छा है'। सही प्रश्न है 'कौन-सा ढाँचा हमारी विशिष्ट टीम को उसका सामना कराता है जिसे हम आम तौर पर टालते हैं'।
प्राथमिकता-ढाँचे क्यों होते हैं
हर प्राथमिकता-ढाँचा चार चीज़ों के बीच ट्रेड-ऑफ़ करने की heuristic है: मूल्य, विश्वास, प्रयास और समय। अलग-अलग ढाँचे अलग-अलग ट्रेड-ऑफ़ को सामने रखते हैं। RICE विश्वास को सामने रखता है; Kano भावनात्मक प्रतिफल को; WSJF समय को; Value/Effort लीवरेज-अनुपात को। आपकी टीम के लिए सही ढाँचा वह है जो आपको उस बात पर बहस करवाता है जिसे आप टाल रहे थे।
- ढाँचे असहमति उजागर करते हैं, सुलझाते नहीं।
- ऐसा स्कोर जिस पर बिना बहस सब सहमत हों — संदेह योग्य है; आम तौर पर कोई भी विश्वास पर ईमानदार नहीं।
- एक ही backlog पर कई ढाँचे चलाएँ और उन वस्तुओं को देखें जिनके स्कोर अलग-अलग आते हैं — वे सबसे दिलचस्प हैं।
RICE: Reach × Impact × Confidence ÷ Effort
Intercom का RICE आधुनिक PM में सबसे सामान्य scoring ढाँचा है। Reach अवधि के अनुसार प्रभावित उपयोगकर्ताओं या घटनाओं की संख्या है। Impact एक मोटा गुणक है (Massive=3, High=2, Medium=1, Low=0.5, Minimal=0.25)। Confidence एक प्रतिशत है जो सट्टे जैसे स्कोरों पर छूट लगाता है। Effort व्यक्ति-माह में है। एक ही backlog की पहलों के बीच स्कोर तुलनीय रहता है, भले ही वे प्रोडक्ट के बहुत अलग क्षेत्रों में हों।
- Reach अवधि-सहित वास्तविक संख्या होनी चाहिए — '5,000 उपयोगकर्ता प्रति तिमाही', 'बहुत' नहीं।
- Impact जान-बूझकर मोटा है — सटीकता नक़ली है; अलग बकेट बातचीत मजबूर करती हैं।
- Confidence साक्ष्य का प्रतिबिंब हो, उत्साह का नहीं — असमर्थित विचारों के लिए 50% ईमानदार डिफ़ॉल्ट है।
- Effort में डिज़ाइन, इंजीनियरिंग, QA, संचार और रैंप-डाउन सपोर्ट शामिल हो — केवल कोड नहीं।
ICE: Impact × Confidence × Ease
Sean Ellis का ICE, RICE का तेज़ चचेरा भाई है। हर इनपुट 1-10 का स्कोर है; गुणनफल ही रैंक है। ऊँचे थ्रूपुट वाले प्रयोग-backlogs (growth, conversion tests) के लिए ICE का प्रयोग करें — वहाँ हर वस्तु पर RICE स्कोरिंग एक हफ़्ता खा जाती। ट्रेड-ऑफ़: कोई Reach घटक नहीं, इसलिए ICE आसान जीतों की ओर पक्षपाती है, और व्यापक पहुँच लेकिन कठिन निर्माण वाले व्यवस्थागत सुधारों के विरुद्ध।
- ICE फ़ीचर backlogs के बजाय प्रयोग-backlogs के लिए सबसे अच्छा है।
- Ease, effort का व्युत्क्रम है — Ease अधिक = शिप करना तेज़।
- अंतर्ज्ञान से स्कोर करें, असली परिणामों के विरुद्ध कैलिब्रेट करें; मासिक रूप से पुनः कैलिब्रेट करें।
- एक अलग 'थीम' टैग के साथ जोड़ें ताकि किसी रणनीतिक थीम से अनजाने में दूर अनुकूलन न हो।
मूल्य बनाम प्रयास (2×2 मैट्रिक्स)
सबसे सरल विज़ुअल प्राथमिकता उपकरण। हर वस्तु को मूल्य (लक्ष्य पर प्रभाव) बनाम प्रयास के 2×2 पर रखें। चतुर्थांश: quick wins (उच्च मूल्य, कम प्रयास), big bets (उच्च मूल्य, उच्च प्रयास), fill-ins (कम मूल्य, कम प्रयास), thankless (कम मूल्य, उच्च प्रयास — छोड़ें)। 30 मिनट की संरेखण कार्यशाला के लिए सर्वोत्तम — जहाँ बातचीत ही डिलीवरेबल है, मैट्रिक्स नहीं।
- टीम को हर वस्तु को रखने के लिए विवश करें; बराबरी अस्पष्ट परिभाषाओं का संकेत है।
- भौतिक स्टिकी नोट्स या वर्चुअल बोर्ड का उपयोग करें; प्लेसमेंट पर खुलकर बहस करें।
- Quick wins पहले शिप; big bets क्रमबद्ध; fill-ins क्षमता भरते हैं; thankless मरते हैं।
- ओवर-इंजीनियर न करें — यह स्पष्टता के लिए है, ट्रैकिंग के लिए नहीं।
Kano मॉडल: must-have, performance, delighter
Noriaki Kano का मॉडल फ़ीचरों को 'फ़ीचर की उपस्थिति और उपयोगकर्ता संतुष्टि के संबंध' के अनुसार वर्गीकृत करता है। Must-have उपस्थित होने पर अदृश्य और अनुपस्थित होने पर विनाशकारी होते हैं (login का काम करना, डेटा persistence)। Performance फ़ीचरों का रैखिक संबंध होता है — अधिक बेहतर है (तेज़ load, अधिक स्टोरेज)। Delighter अप्रत्याशित सकारात्मक हैं — अनुपस्थित में चोट नहीं देते पर उपस्थित में प्यार पैदा करते हैं। Reverse फ़ीचर उपस्थित होने पर सक्रिय रूप से चिढ़ाते हैं।
- हर फ़ीचर को वर्गीकृत करने के लिए functional / dysfunctional प्रश्न-जोड़ी से उपयोगकर्ताओं का सर्वे करें।
- Must-have ऑक्सीजन हैं — आवश्यक पर विभेदक नहीं।
- Performance फ़ीचर रोडमैप का बड़ा हिस्सा हैं; जिनकी संतुष्टि-वक्र सबसे ढालू हो उन्हें चुनें।
- Delighter घिस जाते हैं; आज का delighter कल का must-have है (Uber का 'चालक आ रहा है' मैप सोचें)।
MoSCoW: Must / Should / Could / Won't
MoSCoW रोडमैप टूल से ज़्यादा रिलीज़-स्कोपिंग टूल है। Must-have रिलीज़ के लिए ग़ैर-वार्ता-योग्य हैं। Should-have महत्वपूर्ण पर महत्वपूर्ण नहीं। Could-have nice-to-have हैं। Won't-have स्पष्ट रूप से दायरे से बाहर हैं — scope creep रोकने के लिए नामांकित। निश्चित-समय वाले संदर्भों (नियामकीय, लॉन्च) में उपयोगी जहाँ प्रश्न है 'इस रिलीज़ में क्या है', 'अगले क्या काम करना चाहिए' नहीं।
- अधिकांश टीमें ज़्यादा Must लगाती हैं — पूछ कर कैलिब्रेट करें: 'क्या हम इसे शिप करने के लिए लॉन्च एक हफ़्ते टालेंगे?'
- Won't-have सबसे कम उपयोग की जाने वाली श्रेणी है; स्पष्ट बहिष्करण scope creep को कम करते हैं।
- हर रिलीज़ में पुनः वर्गीकृत करें — स्थिर दस्तावेज़ की तरह नहीं।
- तारीख़ के साथ जोड़ें; तारीख़ के बिना MoSCoW बस नाम बदला हुआ wishlist है।
WSJF: Weighted Shortest Job First
WSJF (SAFe / lean से) Cost of Delay को Job Size से विभाजित करके प्राथमिकता देता है। Cost of Delay = User-Business Value + Time Criticality + Risk Reduction / Opportunity Enablement। समय जब मायने रखे — नियामक डेडलाइन, बाज़ार-विंडो, अन्य काम को रोकने वाली निर्भरताएँ — वहाँ ढाँचा चमकता है। ऐसे backlog पर इसे इस्तेमाल करें जहाँ 'कब' उतना ही महत्वपूर्ण है जितना 'क्या'।
WSJF = (User-Business Value + Time Criticality + Risk Reduction & Opportunity Enablement) / Job Size
- हर घटक के लिए Fibonacci-जैसी 1/2/3/5/8/13 स्केल का उपयोग करें।
- Time criticality decay पकड़ता है: रुकने पर मूल्य कितना गिरता है।
- Risk reduction / opportunity enablement अन्य काम को अनब्लॉक करने का दूसरे-क्रम का मूल्य पकड़ता है।
- अधिक WSJF पहले। आश्चर्यजनक रूप से बार-बार, उच्च time criticality वाले छोटे काम बड़े दाँवों पर जीतते हैं।
Cost of Delay
Cost of Delay (Don Reinertsen) शिप न करने पर प्रति इकाई समय खोया गया आर्थिक मूल्य है। यह WSJF का सामान्यीकरण है और जब वित्त कमरे में हो तो सबसे कठोर लेंस। CoD/सप्ताह × विलंब के सप्ताह = खोया मूल्य। उपयोगी जब आपको भर्ती करने, समानांतर करने या scope कम करने का तर्क डॉलरों में देना हो — भावनाओं में नहीं।
- रेंज में अनुमान लगाएँ, बिंदु में नहीं — '$50-150k प्रति सप्ताह' ईमानदार है; '$73,520' थिएटर है।
- ग़ैर-रैखिक decay का ध्यान रखें: लॉन्च-विंडो, नियामक डेडलाइन, वायरल क्षण।
- टीम क्षमता के साथ देखें कि क्या समानांतर करने से कुल CoD घटता है या बस हर परियोजना खिंचती है।
- Reinertsen: 'अगर एक ही चीज़ मात्रात्मक करना हो — Cost of Delay मात्रात्मक करें।'
Stack ranking
सबसे सरल ढाँचा: पूरे backlog को सामने रखें और 1 से N तक मजबूरन रैंक करें। बराबरी की अनुमति नहीं। अनुशासन असहमति में है: यदि दो वस्तुएँ '#3 पर बंधी' हैं, तो टीम ट्रेड-ऑफ़ टाल रही है। Stack ranking उसे मजबूर करता है। RICE/ICE/Kano के बाद अंतिम पास के रूप में उपयोगी — मनुष्य स्कोर-द्वारा निहित क्रम को अंतर्ज्ञान से जाँचते हैं और ग़लत-स्कोर वाली वस्तुओं को सामने लाते हैं।
- backlog प्रिंट करें और दीवार पर भौतिक रूप से क्रमित करें — स्थानिक लेआउट कमज़ोर तर्कों को उजागर करता है।
- बराबरी पर अटके हों, तो पूछें: 'अगर अगले तिमाही में सिर्फ़ एक शिप कर सकूँ, तो कौन-सा?'
- अंतिम पास के रूप में उपयोग करें, एकमात्र पास के रूप में नहीं।
Buy a Feature
Luke Hohmann का सहयोगी खेल: हर हितधारक को नक़ली मुद्रा का निश्चित बजट दें, effort के अनुपात में मूल्यांकित फ़ीचरों का मेनू प्रस्तुत करें, और उन्हें वे फ़ीचर 'ख़रीदने' दें जिन्हें वे सबसे अधिक महत्व देते हैं — महंगी वस्तुओं के लिए पैसा एक करना भी शामिल। यह वास्तविक प्राथमिकता उजागर करता है, गठजोड़ सामने लाता है और दुर्लभता को मूर्त बनाता है।
- ग्राहक-केंद्रित प्राथमिकता-सत्रों के लिए सबसे अच्छा (advisory boards, design partner programs)।
- पैसा-एकजुट करना सबसे दिलचस्प संकेत है — हितधारकों के गठबंधन संरेखण उजागर करते हैं।
- परिणामों को रोडमैप के रूप में अक्षरशः न लें; माँग की तीव्रता पर खोज मानें।
- विविधता: 'Pay for a Feature' — रियायती बंडलों के साथ — packaging hypotheses की जाँच करता है।
Opportunity Scoring (ODI)
Tony Ulwick की outcome-driven scoring: हर वांछित परिणाम (फ़ीचर नहीं) के लिए, उपयोगकर्ताओं से importance और वर्तमान satisfaction पूछें — दोनों 1-10। Opportunity = Importance + max(0, Importance − Satisfaction)। उच्च-opportunity परिणाम (≥12) कम-सेवित हैं; निम्न (<10) अधिक-सेवित या संतृप्त। निवेश को उन परिणामों की ओर ले जाता है जिनकी उपयोगकर्ता परवाह करता है पर बाज़ार ने संतुष्ट नहीं किए।
Opportunity = Importance + max(0, Importance − Satisfaction)
- परिणाम समाधान-निरपेक्ष कथन हों ('डुप्लिकेट पहचानने का समय न्यूनतम करें')।
- स्थिर स्कोर पाने के लिए लक्ष्य segment में n≥100 उपयोगकर्ताओं का सर्वे करें।
- उन उपयोगकर्ताओं का सर्वे न करें जो वास्तव में वह job नहीं करते — असंगत डेटा सिग्नल पतला करता है।
- वार्षिक रूप से पुनः सर्वे करें; बाज़ार के विकास के साथ संतृप्ति बहती है।
Theme scoring
जब backlog में 200 वस्तुएँ हों, हर एक को स्कोर करना ऊर्जा की बर्बादी है। Theme scoring वस्तुओं को 5-10 रणनीतिक थीमों में लपेटता है (जैसे 'time-to-first-value घटाएँ', 'mid-market में विस्तार', 'platform reliability'), थीमों को स्कोर करता है, और थीम-वार क्षमता आवंटित करता है। थीम के भीतर टीम सामरिक प्राथमिकता देती है। रणनीतिक थीमों और कई छोटे दाँवों वाली प्रोडक्ट orgs के लिए सर्वोत्तम।
- थीमों को रणनीतिक संरेखण + मापने योग्य परिणाम-मूल्य पर स्कोर करें — फ़ीचर-स्तरीय स्कोर पर नहीं।
- थीम-वार क्षमता आवंटित करें (जैसे 50% reliability, 30% growth, 20% experiments)।
- हर थीम के भीतर सामरिक क्रम के लिए RICE या ICE उपयोग करें।
- तिमाही पर नेतृत्व के साथ थीम पुनः-संतुलित करें; सामरिक चुनाव टीम के पास रहते हैं।
विश्वास को प्रथम-श्रेणी स्कोर मानें
PM प्राथमिकता में सबसे कम उपयोग किया जाने वाला आयाम ईमानदार विश्वास है। कमज़ोर साक्ष्य पर टिके भारी विचार को छोटे, स्पष्ट-माँग वाले विचार से डिफ़ॉल्ट रूप से ऊपर नहीं होना चाहिए। विश्वास सट्टे जैसे reach और impact को रोडमैप पर हावी होने से रोकता है। उसे स्पष्ट करें, साक्ष्य-टैग्ड बनाएँ, और बार-बार समीक्षा करें।
- विश्वास-स्तर साक्ष्य-लंगरों के साथ परिभाषित करें: 100% (डेटा से सत्यापित), 80% (गुणात्मक + अग्रणी सूचक), 50% (साक्षात्कार समर्थन, कोई डेटा नहीं), 30% (सूचित परिकल्पना)।
- हर विश्वास-स्कोर के पीछे साक्ष्य टैग करें।
- हर रोडमैप-समीक्षा में विश्वास पुनः देखें और समायोजित करें।
- जब विश्वास गिरे, वस्तुएँ नीचे रैंक हो सकती हैं — यही उद्देश्य है।
सही ढाँचा चुनना
ढाँचे को निर्णय से मिलाएँ। मिश्रित दाँव-आकार वाला नया प्रोडक्ट backlog? RICE। Growth प्रयोग backlog? ICE। त्वरित संरेखण कार्यशाला? Value/Effort। हितधारकों की माँग का सत्र? Buy a Feature। डेडलाइन-सहित रिलीज़ स्कोपिंग? MoSCoW। निर्भरताओं वाला समय-संवेदनशील backlog? WSJF। बड़ा परिपक्व backlog? Theme scoring। आप पहले जिस ढाँचे के लिए हाथ बढ़ाते हैं वह बताता है आप किस तरह के निर्णयों का सामना करते हैं — और आपने कौन-सा अनुशासन अभ्यास किया है।
Framework atlas
Reference cards for each method in this mission
Expand a card for when to deploy it, misuse patterns, sequencing guidance, and (where relevant) shorthand formulas.
Quantitative scoring · Sean McBride at Intercom (2017)RICE(RICE)
Reach × Impact × Confidence / Effort. The most common cross-functional scoring framework.
RICE = (Reach × Impact × Confidence%) / Effort
When to use
- Roadmap candidate backlog with mixed bet sizes.
- Cross-team prioritization where transparency matters.
- When confidence varies wildly across items.
When not to
- Pure experiment backlogs (use ICE, faster cycle).
- When all items are within the same theme (RICE noise > signal).
How to apply
- Estimate Reach as a number per period (users, events, or sessions).
- Pick Impact from a coarse scale: Massive=3, High=2, Medium=1, Low=0.5, Minimal=0.25.
- Set Confidence honestly with an evidence tag (100/80/50/30%).
- Estimate Effort in person-months across all functions.
- Compute the score; rank descending; argue about top vs bottom of ties.
- Reach written as 'all users' — meaningless without a time period.
- Confidence inflated to win the comparison.
- Effort that excludes design, ops, comms, and ramp-down.
Quantitative scoring · Sean Ellis (popularized through GrowthHackers)ICE(ICE)
Impact × Confidence × Ease, each on a 1-10 scale. Lightweight scoring for high-volume experiment backlogs.
ICE = Impact × Confidence × Ease
When to use
- Growth experiment backlogs.
- When you need a score in <2 minutes per item.
- Backlogs where Reach is roughly equal across items.
When not to
- Roadmap-level prioritization with mixed bet sizes.
- Cross-team trade-offs (RICE's transparency helps more here).
How to apply
- Score Impact (1-10): expected lift on the target metric.
- Score Confidence (1-10): evidence quality.
- Score Ease (1-10): inverse effort.
- Rank by product; calibrate weekly against actual experiment outcomes.
- Same person scoring all three components — biased.
- Never recalibrating against actual outcomes.
Visual prioritization · Lean / agile workshopsValue vs Effort 2×2
Simple 2×2 matrix plotting items by value and effort to surface quick wins, big bets, fill-ins, and items to drop.
When to use
- Quick alignment in a 30-minute workshop.
- Sanity-checking a RICE-ordered list visually.
When not to
- When you need numerical comparability across many items.
How to apply
- Define the value dimension explicitly (revenue impact? activation lift? NSM movement?).
- Plot every item with the team co-present.
- Cluster into quick wins (DO), big bets (PLAN), fill-ins (FILL), thankless (DROP).
- Sequence quick wins immediately; scope big bets formally.
- Letting 'value' stay vague — produces a useless map.
- Skipping the DROP quadrant — it's the most valuable category.
Customer satisfaction · Noriaki Kano (1984)Kano Model
Classifies features by the relationship between presence and satisfaction: Must-Have, Performance, Delighter, Indifferent, Reverse.
When to use
- Designing a tier or plan structure.
- Detecting under-investment in basics or over-investment in delighters.
When not to
- Highly novel categories where users can't classify yet.
How to apply
- List candidate features.
- For each, ask users a functional and dysfunctional question pair (how would you feel if this feature existed / didn't exist?).
- Classify each feature by the response pattern.
- Re-score annually as delighters age into must-haves.
- Treating Kano as a static taxonomy instead of a moving target.
- Surveying customers who don't yet know the feature category.
Release scoping · Dai Clegg / DSDM (1990s)MoSCoW(MoSCoW)
Must-have, Should-have, Could-have, Won't-have-this-time. Release-scoping tool for fixed-deadline contexts.
When to use
- Fixed-date launches (regulatory, partner integrations, conferences).
- Releases with strict scope boundaries.
When not to
- Continuous-delivery products without releases as a unit.
How to apply
- List every candidate item for the release.
- Categorize as Must / Should / Could / Won't.
- Validate: would you delay the release a week to land each Must? If not, demote.
- Publish the Won't list to set expectations explicitly.
- Over-Must-ing under stakeholder pressure.
- Treating Won't as a deferral list instead of an exclusion list.
Time-sensitive scoring · SAFe / Don ReinertsenWSJF(WSJF)
Weighted Shortest Job First: Cost of Delay divided by Job Size. Prioritizes high-CoD short jobs first.
WSJF = (User-Business Value + Time Criticality + Risk Reduction & Opportunity Enablement) / Job Size
When to use
- Backlogs where time-to-value or sequencing matters.
- Dependency-heavy programs where unblocking work has compounding value.
When not to
- Pure feature backlogs without time pressure.
How to apply
- Score each component on a Fibonacci-like scale: 1, 2, 3, 5, 8, 13.
- Sum the value components; divide by job size.
- Sequence highest WSJF first.
- Confusing Job Size with story points — Job Size includes dependency unblocking.
- Ignoring time criticality decay.
Economic prioritization · Don ReinertsenCost of Delay
The economic value lost per unit time by not shipping. Quantifies the urgency case in dollars.
When to use
- Cross-team capacity allocation arguments.
- Hiring decisions ('how much will the second engineer save us per month?').
- When finance partners want a dollar-denominated case.
When not to
- Early-stage products without revenue mechanics.
How to apply
- Identify the value the project will create (annual revenue, retention dollars, support hours saved).
- Estimate value-per-week if shipped today vs in 13 weeks.
- Account for non-linear decay (launch windows, deadlines).
- Express as a range; communicate to stakeholders weekly.
Forced-choice ordering · Industry-wide practiceStack Ranking
Force-rank the entire backlog 1..N with no ties allowed. Surfaces hidden disagreements that scored frameworks miss.
When to use
- Final pass after RICE/ICE has produced a candidate order.
- Small backlogs (<30 items).
When not to
- Backlogs of 100+ items — use theme scoring first.
How to apply
- List all items.
- Force-rank with no ties.
- When stuck, ask 'if we could ship only one, which?'
- Reconcile against framework scores; investigate any large divergences.
Collaborative · Luke HohmannBuy a Feature
Stakeholders allocate fake currency to features priced by effort. Pooling and trading reveal demand intensity and coalitions.
When to use
- Customer advisory boards.
- Internal alignment workshops with multiple competing priorities.
When not to
- Solo PM scoring — Buy a Feature requires multiple participants.
How to apply
- Price each feature at 1-3 times its effort proportional cost.
- Give each participant a budget that can buy ~1/3 of the menu.
- Run a 30-45 minute session; allow pooling.
- Debrief on why pooling happened; that's the strategic signal.
Outcome-based scoring · Tony Ulwick / StrategynOpportunity Scoring (ODI)
Score outcomes by importance and current satisfaction; opportunity = importance + max(0, importance − satisfaction).
Opportunity = Importance + max(0, Importance − Satisfaction)
When to use
- Mature markets with well-understood jobs.
- Roadmap arbitration in a saturated category.
When not to
- Brand-new categories where users can't articulate the job yet.
How to apply
- Decompose the job into outcome statements.
- Survey users (n≥100) on importance and satisfaction.
- Compute opportunity score per outcome.
- Prioritize outcomes with score ≥ 12 as under-served.
Personal triage · Dwight D. EisenhowerEisenhower Matrix
Urgent vs Important 2×2 for personal task triage. Useful for managing the PM's own workload, not for product prioritization at scale.
When to use
- Personal weekly triage of inbound asks.
- Distinguishing reactive support from strategic work.
When not to
- Roadmap prioritization — 'important' is too vague at scale.
How to apply
- List all open asks/tasks.
- Tag each: urgent or not; important or not.
- Triage: do, schedule, delegate, drop.
Product Psychology
Cognitive biases that distort product decisions
Confidence Inflation
Scorers inflate confidence to ensure their preferred items rank highly.
Product Risk
Speculative bets dominate the roadmap because nobody will admit a 30% confidence score.
Research Countermove
Tag every confidence score with the specific evidence behind it. Audit retroactively: did 80%-confidence items actually hit?
Effort Sandbagging
Engineers overestimate effort on items they don't want to do; underestimate on items they want to ship.
Product Risk
Roadmaps reflect engineering preferences disguised as effort scores.
Research Countermove
Track estimated vs actual effort over time per scorer; calibrate against history; consider a second estimator.
Reach Hallucination
Optimistic Reach estimates because nobody fact-checks the user counts.
Product Risk
Big-feeling features dominate over targeted features that are genuinely more impactful.
Research Countermove
Pull reach from analytics, not hopes. If the segment can't be quantified, set Reach = 0 and force the team to instrument first.
HiPPO Effect
Highest Paid Person's Opinion overrides scoring frameworks.
Product Risk
Frameworks become rationalization for predetermined exec preferences.
Research Countermove
Score blind first; reveal to leadership only after the team has converged. Disagreements with leadership become explicit conversations, not silent overrides.
Organizational anti-patterns
When ceremonies look like rigor but aren't
Score Then Ignore
Team produces a beautifully scored RICE sheet, then ships in the order leadership prefers anyway.
The framework is performative; real authority is elsewhere.
Either commit to the score or admit the framework is advisory. Performative scoring corrodes trust faster than honest political prioritization.
All Confidence at 80%
Every item has confidence 70-90%; the lever is never used.
Confidence below 50% feels like an admission of failure; nobody wants to write it down.
Define explicit confidence anchors (with examples). Reward calibration over confidence.
Effort Without Capacity Check
Top-ranked RICE items add up to 18 person-months in a 3-month quarter; team commits anyway.
Prioritization and capacity planning live in different docs.
After ranking, draw the line at actual capacity. Items below the line are explicit not-doing; their existence is information for next quarter.
One Framework Forever
Team uses RICE for everything regardless of decision type.
Cargo-culting; nobody on the team has tried the alternatives.
Use at least three frameworks across the year. Notice which one each kind of decision gravitates toward.
Resurrection Backlog
Items that lost prioritization three quarters ago keep returning, slightly rebranded, against the same evidence.
Stakeholders feel unheard; the team has no public record of why items were declined.
Maintain a public 'declined items log' with the reason and the evidence threshold for revisiting. Items can return only when the threshold is met.
Worked examples
Walkthroughs translated from real trade-off rooms
Walking through a real RICE comparison
A B2B SaaS team is comparing two roadmap candidates: 'Onboarding checklist' and 'Bulk admin invite flow'.
- Onboarding checklist: Reach 800/quarter (new accounts), Impact 2 (High — activation step), Confidence 85% (validated in 8 user interviews), Effort 3 PM. Score = (800 × 2 × 0.85) / 3 = 453.
- Bulk admin invite: Reach 260/quarter (mid-market signups only), Impact 3 (Massive — unlocks team activation), Confidence 60% (qualitative only, no behavioral data), Effort 5 PM. Score = (260 × 3 × 0.6) / 5 = 94.
- First instinct says bulk-invite is bigger ('massive impact!'), but the smaller-reach + lower-confidence + bigger-effort combination drops it 5x below the checklist.
- Action: ship checklist now; instrument the bulk-invite hypothesis to raise its confidence; revisit next quarter.
TakeawayWithout RICE, gut feel might have prioritized the bulk invite. With RICE, the lower-confidence bigger bet correctly defers to the higher-confidence smaller bet.
Picking ICE over RICE for a growth experiment backlog
A growth team has 28 conversion experiments queued. RICE-scoring all of them would take a full week.
- Reach is roughly constant (all hit the same signup funnel) — so RICE's Reach lever is dead weight.
- Switch to ICE; score each from gut in a 90-minute session.
- Top-scoring experiment: 'Add social proof on signup'. ICE = 7×6×9 = 378.
- Bottom-scoring: 'Animated hero on landing page'. ICE = 4×3×5 = 60.
- Run the top 3; recalibrate scores against actual lift; adjust scoring style.
TakeawayICE was the right tool for high-volume same-Reach experiments. RICE's transparency overhead would have starved velocity.
Using WSJF when the deadline is real
Three roadmap items are competing: 'GDPR DPA renewal automation', 'New-user activation experiment', 'Premium plan tier launch'.
- GDPR DPA: Job 5, User-Business Value 5, Time Criticality 13 (regulatory deadline 4 months out), Risk Reduction 8. WSJF = (5+13+8)/5 = 5.2.
- Activation experiment: Job 2, V 5, TC 3, RR 2. WSJF = (5+3+2)/2 = 5.0.
- Premium tier: Job 8, V 13, TC 5, RR 5. WSJF = (13+5+5)/8 = 2.875.
- Rank: GDPR > Activation experiment > Premium tier. Despite Premium having the highest dollar value, its size and lower time criticality push it to third.
TakeawayWSJF correctly highlighted that the regulatory deadline created ambient cost-of-delay invisible to RICE. The big premium bet still gets done, just sequenced after the urgent shorter jobs.
Catching a Kano misclassification
Team wants to invest heavily in custom dashboard builders, treating them as a Delighter that will differentiate.
- Run Kano survey on 50 enterprise users: results show 71% classify dashboard builders as Must-Have or Performance, only 12% as Delighter.
- Reframe: dashboard builders are table-stakes, not delight. Delight will need to come from somewhere else.
- Re-prioritize: ship the dashboard builder MVP fast as a competitive must-have; redirect 'delight' investment to the AI-summarization feature that scored as a true Delighter (78% Delighter response).
TakeawayKano correctly redirected investment from a feature that would only meet expectations to a feature that would actually generate satisfaction lift.
Interactive lab
These instruments implement the textbook formulas loosely—use them to stress‑test judgments, compare frameworks on the same backlog, then document evidence and decisions.
← swipe to see all frameworks →
RICE
Reach × Impact × Confidence ÷ Effort (Intercom scale)
Reach × Impact × Confidence% ÷ Effort— Reach = users/events in one consistent period; Effort in person-months
score = (reach × impact × confidence/100) ÷ effort| # | Initiative | Reach | Impact | Confidence | Effort | RICE Score | |
|---|---|---|---|---|---|---|---|
| 1 | 85% | 453.33 800×2×0.85÷3 | |||||
| 2 | 60% | 93.60 260×3×0.60÷5 |
Resources / Case Studies
Curated reading for this mission
Sean McBride / Intercom
The original Intercom blog post introducing the RICE framework with worked examples.
Source-of-truth article for RICE; the simulator in this curriculum implements the same math.
Don Reinertsen
The seminal text on Cost of Delay, queuing theory, and product development economics.
The most rigorous treatment of why time-based prioritization matters; foundational for WSJF.
Sean Ellis / GrowthHackers
Sean Ellis's lightweight scoring method for high-velocity experiment backlogs.
Establishes when ICE is the right tool over heavier frameworks like RICE.
Mind the Product
Practical guide with templates for running a Kano survey, classifying responses, and avoiding common pitfalls.
Most accessible operational guide for actually running Kano analysis.
Luke Hohmann
Hohmann's collaborative game for surfacing demand intensity from stakeholders.
Strong tool for advisory boards and internal alignment workshops.
Joshua J. Arnold (Black Swan Farming)
Plain-language explanation of CoD with case studies showing the dollar impact of late shipments.
Best free introduction to CoD for PMs new to the concept.
Tony Ulwick
Outcome-Driven Innovation's quantitative scoring method for under-served outcomes.
The clearest reference for combining JTBD discovery with quantitative roadmap prioritization.
Janna Bastow / ProdPad
The case for Now / Next / Later format and why date-based roadmaps damage trust.
Foundational reading for moving teams off Gantt-roadmap pathology.
Itamar Gilad
Gilad's Confidence Meter — a structured way to attach evidence to confidence scores in any prioritization framework.
Operationalizes confidence in a way every framework benefits from.
Lenny Rachitsky
Recurring case studies from PMs at large tech companies on how they actually prioritize.
Reality-check against the canonical frameworks; current practitioners share what works and what doesn't.
John Cutler / Amplitude
Weekly notes from a product strategy lens on prioritization, theme allocation, and team operating models.
Sharpens systems-level thinking about prioritization beyond per-item scoring.
Ryan Singer / Basecamp
Basecamp's alternative to backlog-driven development: shaped bets, fixed appetite, no estimation theater.
Provocative counter-view to scoring-based prioritization; worth reading even if you don't adopt it.