The Art of Prioritization

Every prioritization framework is a heuristic for trading off four things: value, confidence, effort, and time. Different frameworks foreground different trade-offs. RICE foregrounds confidence; Kano foregrounds emotional payoff; WSJF foregrounds time; Value/Effort foregrounds the leverage ratio. The framework that fits your team is the one that makes you argue about the thing you were avoiding.

• Frameworks expose disagreement, they don't resolve it.
• A score that everyone agrees on without debate is suspect — usually nobody is being honest about confidence.
• Use multiple frameworks for the same backlog and look for items that score divergently — those are the most interesting.

Intercom's RICE is the most common scoring framework in modern PM. Reach is the number of users or events affected per period. Impact is a coarse multiplier (Massive=3, High=2, Medium=1, Low=0.5, Minimal=0.25). Confidence is a percentage that discounts speculative scores. Effort is person-months. The score is comparable across initiatives in the same backlog, even when they're in very different areas of the product.

• Reach must be a real number with a time period — '5,000 users per quarter' not 'lots'.
• Impact is intentionally coarse — the precision is fake; the discrete buckets force conversation.
• Confidence must reflect evidence, not enthusiasm — 50% is the honest default for unsubstantiated ideas.
• Effort should include design, eng, QA, comms, and ramp-down support — not just code.

Sean Ellis's ICE is RICE's faster cousin. Each input is a 1-10 score; the product is the rank. Use ICE for high-throughput experiment backlogs (growth experiments, conversion tests) where you'd burn a week scoring RICE on each. The trade-off: no Reach component, so ICE is biased toward easy wins and against systemic improvements with broad reach but harder construction.

• ICE is best for experiment backlogs, not feature backlogs.
• Ease is the inverse of effort — higher Ease = faster to ship.
• Score from gut, calibrate against actual outcomes; recalibrate scores monthly.
• Pair with a separate 'theme' tag so you don't accidentally optimize away from a strategic theme.

The simplest visual prioritization tool. Plot each item on a 2×2 of value (impact on the goal) versus effort. Quadrants: quick wins (high value, low effort), big bets (high value, high effort), fill-ins (low value, low effort), thankless (low value, high effort — drop). Best used for a 30-minute alignment workshop where the conversation is the deliverable, not the matrix itself.

• Force the team to place every item; ties are a sign of unclear definitions.
• Use sticky notes physically or a virtual board; debate the placement openly.
• Quick wins ship first; big bets get sequenced; fill-ins fill capacity; thankless die.
• Don't over-engineer — this is for clarity, not for tracking.

Noriaki Kano's model classifies features by the relationship between feature presence and user satisfaction. Must-haves are invisible when present and catastrophic when absent (login working, data persistence). Performance features have a linear relationship — more is better (faster load times, more storage). Delighters are unexpected positives that don't hurt when absent but generate love when present. Reverse features actively annoy users when present.

• Survey users with a feature-functional / feature-dysfunctional question pair to classify each feature.
• Must-haves are oxygen — necessary but not differentiating.
• Performance features are the bulk of the roadmap; pick the ones with the steepest satisfaction curve.
• Delighters wear off; today's delighter is tomorrow's must-have (think Uber's map showing the driver coming).

MoSCoW is a release-scoping tool more than a roadmap tool. Must-have items are non-negotiable for the release. Should-have are important but not critical. Could-have are nice-to-haves. Won't-have are explicitly out of scope, named to prevent scope creep. Useful in fixed-deadline contexts (regulatory, launches) where the question is 'what's in this release', not 'what should we work on next'.

• Most teams over-Must — calibrate by asking 'would we delay launch a week to ship this?'
• Won't-have is the most underused category; explicitly listing exclusions reduces scope creep.
• Re-categorize at every release, not as a static document.
• Pair with a date; without a date, MoSCoW is just renamed wishlist.

WSJF (from SAFe / lean) prioritizes by Cost of Delay divided by Job Size. Cost of Delay = User-Business Value + Time Criticality + Risk Reduction / Opportunity Enablement. The framework excels when timing matters — regulatory deadlines, market windows, dependencies blocking other work. Use it for a backlog where 'when' is as important as 'what'.

WSJF = (User-Business Value + Time Criticality + Risk Reduction & Opportunity Enablement) / Job Size

• Use Fibonacci-like 1/2/3/5/8/13 scales for each component.
• Time criticality captures decay: how much value drops the longer we wait.
• Risk reduction / opportunity enablement captures the second-order value of unblocking other work.
• Higher WSJF first. Surprisingly often, smaller jobs with high time criticality win over big bets.

Cost of Delay (Don Reinertsen) is the economic value lost per unit time by not shipping. It generalizes WSJF and is the most rigorous lens when finance is in the room. CoD per week × weeks of delay = the lost value. Useful when you need to make the case for hiring, parallelizing, or descoping in dollars rather than feelings.

• Estimate as a range, not a point — '$50-150k per week' is honest; '$73,520' is theater.
• Account for non-linear decay: launch windows, regulatory deadlines, viral moments.
• Pair with team capacity to see whether parallelizing actually reduces total CoD or just stretches each project.
• Reinertsen: 'If you only quantify one thing, quantify Cost of Delay.'

The simplest framework: lay out the entire backlog and force-rank from 1 to N. No ties allowed. The discipline is in the disagreement: if two items are 'tied for #3', the team avoids the trade-off. Stack ranking forces it. Useful as a final pass after RICE/ICE/Kano have produced a candidate ordering — humans cross-check the score-implied ranking against intuition and surface mis-scored items.

• Print the backlog and physically order it on a wall — the spatial layout exposes weak rationales.
• When stuck on a tie, ask: 'if I could only ship one of these next quarter, which?'
• Use as the final pass, not the only pass.

Luke Hohmann's collaborative game: give each stakeholder a fixed budget of fake currency, present a menu of features with prices proportional to effort, and let stakeholders 'buy' the features they value most — including pooling money to buy expensive items. Reveals true preference, surfaces coalitions, and makes scarcity tangible.

• Best for customer-facing prioritization sessions (advisory boards, design partner programs).
• The pooling behavior is the most interesting signal — stakeholders' coalitions reveal alignment.
• Don't take results literally as a roadmap; treat as discovery into demand intensity.
• Variation: 'Pay for a Feature' with discounted bundles tests packaging hypotheses.

Tony Ulwick's outcome-driven scoring: for each desired outcome (not feature), survey users for importance and current satisfaction, both 1-10. Opportunity = Importance + max(0, Importance − Satisfaction). High-opportunity outcomes (≥12) are under-served; low-opportunity outcomes (<10) are over-served or saturated. Drives investment toward outcomes the user cares about and the market hasn't satisfied.

Opportunity = Importance + max(0, Importance − Satisfaction)

• Outcomes must be solution-agnostic statements ('minimize time to identify duplicates').
• Survey n≥100 users in the target segment to get stable scores.
• Avoid surveying users who don't actually do the job — irrelevant data dilutes signal.
• Re-survey annually; saturation drifts as the market evolves.

When the backlog is 200 items, scoring each is a waste of energy. Theme scoring rolls items into 5-10 strategic themes (e.g. 'reduce time-to-first-value', 'expand into mid-market', 'platform reliability'), scores the themes, and allocates capacity by theme. Within a theme, the team prioritizes tactically. Best for product orgs with strategic themes and many small bets.

• Score themes by strategic alignment + measurable outcome value, not feature-level scores.
• Allocate capacity by theme (e.g. 50% reliability, 30% growth, 20% experiments).
• Within each theme, use RICE or ICE for tactical ordering.
• Re-balance themes quarterly with leadership; tactical choices stay with the team.

The single most underused dimension in PM prioritization is honest confidence. A massive idea backed by weak evidence should not outrank a smaller idea with clear demand by default. Confidence prevents speculative reach and impact from dominating the roadmap. Make it explicit, evidence-tagged, and revisited.

• Define confidence levels with evidence anchors: 100% (already validated by data), 80% (qualitative + leading indicator), 50% (interview support, no data), 30% (informed hypothesis).
• Tag the evidence behind each confidence score.
• Revisit and adjust confidence at every roadmap review.
• When confidence drops, items can rank lower — which is the point.

Match the framework to the decision. New product backlog with mixed bet sizes? RICE. Growth experiment backlog? ICE. Quick alignment workshop? Value/Effort. Stakeholder demand session? Buy a Feature. Release scoping with a deadline? MoSCoW. Time-sensitive backlog with dependencies? WSJF. Large mature backlog? Theme scoring. The framework you reach for first reveals the kind of decisions you face — and the discipline you've practiced.