Prioritization Frameworks

Definition: Structured methods for deciding what to build next when there are more good ideas than time to build them, replacing gut-feel or “whoever asked loudest” with a consistent, repeatable process.

How It Works

RICE: scores each candidate on Reach, Impact, Confidence, and Effort, then ranks by the resulting number
MoSCoW: sorts work into Must-have, Should-have, Could-have, and Won’t-have for a specific release, forcing a conversation about what actually gets cut, not just what gets added
Kano: classifies features by the reaction they produce, basic expectations, linear satisfiers, and unexpected delighters, usually via a paired survey question (“how do you feel if this exists” vs. “how do you feel if it doesn’t”)
Value vs. Effort matrix: plots ideas on two axes and favors the top-left quadrant, high value, low effort, useful when there isn’t time for a full RICE pass
All of them exist to make tradeoffs explicit and defensible, not to produce a single “mathematically correct” answer
The output of any framework is a starting point for a prioritization conversation, not a replacement for one
Most teams run a lightweight framework weekly for backlog grooming and a heavier one, RICE or a weighted scorecard, quarterly for roadmap-level calls
Effort estimates typically come from engineering, reach and impact from product and data, confidence from how much validation (research, past experiments) already exists

RICE’s Impact field is usually scored on a fixed scale rather than a free number, which keeps estimates comparable across different scorers:

Impact score	Meaning
3	Massive impact
2	High impact
1	Medium impact
0.5	Low impact
0.25	Minimal impact

Confidence is typically bucketed too, rather than picked freely, for the same reason:

Confidence	Meaning
100%	High confidence, backed by data or a shipped experiment
80%	Medium confidence, some supporting signal
50%	Low confidence, mostly a guess

Under the Hood

The RICE pipeline, from raw candidate list to ranked backlog:

Worked example: RICE scoring for a Q3 backlog

Given three competing features for a checkout product, scored by the team:

Feature	Reach (users/quarter)	Impact (0.25-3)	Confidence	Effort (person-weeks)
Dark mode	9,000	0.5 (minor)	100%	2
Saved payment methods	4,000	2 (high)	80%	4
Bulk export API	500	3 (massive)	50%	6

Step, apply RICE = (Reach x Impact x Confidence) / Effort:

Dark mode:              9000 x 0.5 x 1.0 / 2 = 2250
Saved payment methods:  4000 x 2   x 0.8 / 4 = 1600
Bulk export API:         500 x 3   x 0.5 / 6 =  125

Answer: rank order is Dark mode (2250), then Saved payment methods (1600), then Bulk export API (125). The flashiest idea, bulk export with “massive” impact, loses because it reaches few users and the team isn’t confident in the estimate. That’s the exact case RICE is built to catch: a low-effort, high-reach item beating a high-effort, high-impact one.

Same release, scored with MoSCoW instead

Given the deadline is fixed (a contractual integration date), not open-ended, the team switches frameworks:

Feature	Bucket	Reasoning
Saved payment methods	Must-have	Contract requires it for the partner integration
Dark mode	Could-have	Nice, but not required to hit the deadline
Bulk export API	Won’t-have (this release)	Low reach, low confidence, defer to next quarter

Answer: MoSCoW produces a different kind of output than RICE, not a ranked score but a binding scope decision for one release. The two frameworks aren’t competing answers to the same question, RICE optimizes an ordered backlog, MoSCoW scopes a deadline.

Why It Matters

Without a shared framework, prioritization defaults to whoever has the most organizational power or the loudest voice in the room, not necessarily the best idea
A written score forces hidden assumptions, like “we’re sure this matters,” into the open where they can be challenged before months of engineering time are spent
Gives a product manager a defensible answer when a stakeholder asks “why isn’t my feature next,” a documented tradeoff instead of a shrug
Makes it possible to revisit a decision later and see exactly which input changed, instead of re-litigating the whole argument from scratch

Common Pitfalls

Treating a framework’s score as objective truth rather than a structured starting point, the inputs (especially confidence and impact) are still judgment calls
Gaming the inputs, inflating confidence or impact scores after the fact to justify a feature someone already wanted to build
Using RICE for everything, including strategic bets and platform investments it’s bad at scoring, since their reach and impact are genuinely unknowable in advance
Re-running a full prioritization exercise for every minor decision, adding process overhead that outweighs its value for small calls
Comparing RICE scores across teams or quarters as if they were calibrated the same way, they rarely are
Letting effort estimates come only from whoever is most optimistic, skewing every score toward the same team’s pet projects
Treating MoSCoW’s “Won’t-have” as a permanent no instead of “not this release,” which quietly kills ideas that just needed more time

Comparison

	RICE	MoSCoW	Kano	Value vs. Effort
Output	Numeric score, rank order	Four buckets	Feature category	Quadrant position
Best for	Comparing many unrelated ideas	Scoping a single release	Understanding user sentiment	Fast, low-rigor triage
Inputs needed	Reach, impact, confidence, effort estimates	Team judgment on necessity	User surveys	Rough value and effort guesses
Weakness	Inputs can be gamed or false-precise	No sense of relative value within a bucket	Needs real user research to be accurate	Too coarse for close calls
Rigor	High	Low	Medium, requires a survey run	Low
Good for strategic bets	No	Somewhat	No	No

Example

Intercom popularized RICE in a widely cited 2016 post by product manager Sean McBride, describing how the company built the framework internally to standardize prioritization across teams that had previously argued from instinct. It has since become one of the most commonly adopted prioritization methods in software product management, alongside MoSCoW (which originated in the 1990s DSDM software delivery method) and the Kano model (developed by Noriaki Kano in the 1980s to classify customer satisfaction drivers). Roadmapping tools like Productboard and Aha! now ship built-in RICE scoring calculators, a sign of how standard the framework has become outside Intercom itself.

Referenced by

Dig deeper

Spot an error in this note?