Scrolls
6 min read
On this page

Frameworks That Work

Prioritization frameworks do not make decisions. You make decisions. Frameworks are tools for structured thinking that force you to be explicit about trade-offs. The moment you treat a framework's output as the answer rather than an input to your judgment, you have abdicated the hardest part of the PM job.

That said, some frameworks are genuinely useful. They create a shared language for trade-off discussions, reduce the influence of whoever talks loudest, and make the reasoning behind decisions auditable.

RICE

RICE (Reach, Impact, Confidence, Effort) was developed by Intercom and is one of the most widely used prioritization frameworks in product management. Its strength is that it forces you to quantify, even roughly, the dimensions that matter.

RICE Score = (Reach x Impact x Confidence) / Effort

Reach:      How many users will this affect in a given time period?
            Measured in users per quarter (or per month, per week).

Impact:     How much will this move the metric per user?
            Scale: 3 = massive, 2 = high, 1 = medium,
                   0.5 = low, 0.25 = minimal

Confidence: How sure are you about the estimates above?
            100% = high (data-backed)
            80%  = medium (some data, some intuition)
            50%  = low (mostly intuition)

Effort:     How many person-months will this take?
            Estimated by engineering, not by PM.

RICE Example

Feature A: Onboarding email sequence
  Reach:      5,000 new signups/quarter
  Impact:     1 (medium improvement to activation)
  Confidence: 80% (we have benchmark data from competitors)
  Effort:     0.5 person-months

  RICE = (5000 x 1 x 0.8) / 0.5 = 8,000

Feature B: Advanced search filters
  Reach:      1,200 power users/quarter
  Impact:     2 (high impact on retention for this segment)
  Confidence: 50% (anecdotal evidence from interviews)
  Effort:     3 person-months

  RICE = (1200 x 2 x 0.5) / 3 = 400

Feature C: Performance optimization (page load)
  Reach:      20,000 all users/quarter
  Impact:     0.5 (marginal improvement per user)
  Confidence: 100% (well-researched impact of load time on conversion)
  Effort:     2 person-months

  RICE = (20000 x 0.5 x 1.0) / 2 = 5,000

The math says: onboarding emails first, then performance, then search. But this is where judgment enters. Maybe the search filters are blocking a $500K enterprise deal. Maybe performance has already been promised to the board. RICE gives you a starting point, not an ending point.

When RICE Works

RICE works best when you have a backlog of 15-30 items and need to create an initial ordering. It is particularly good at surfacing "quiet winners," small-effort items with broad reach that nobody championed because they are not exciting.

When RICE Fails

RICE struggles with strategic bets. A new product line that serves zero current users has a Reach of zero, which makes the RICE score zero regardless of how important it is. RICE is a prioritization tool for incremental work, not a strategy tool.

ICE

ICE (Impact, Confidence, Ease) is a simpler alternative to RICE. It drops Reach and uses Ease instead of Effort (the inverse). ICE is popular in growth teams because it is fast and requires less data.

ICE Score = Impact x Confidence x Ease

Impact:     1-10 scale. How much will this move the target metric?
Confidence: 1-10 scale. How certain are you?
Ease:       1-10 scale. How easy is this to implement?

ICE Example

Experiment A: Change CTA button color
  Impact: 2   Confidence: 3   Ease: 10
  ICE = 60

Experiment B: Redesign onboarding flow
  Impact: 8   Confidence: 5   Ease: 3
  ICE = 120

Experiment C: Add social proof to pricing page
  Impact: 5   Confidence: 7   Ease: 8
  ICE = 280

ICE correctly identifies that social proof is the best bang-for-buck experiment: moderate impact, but high confidence and easy to ship.

ICE Limitations

The 1-10 scales are subjective. One person's "7 impact" is another person's "4." Calibrating across a team requires practice and norming sessions. Without calibration, ICE becomes a way for people to justify their preferred projects by inflating scores.

Opportunity Scoring

Opportunity scoring, sometimes called the Opportunity-Solution framework, comes from the Outcome-Driven Innovation (ODI) method developed by Anthony Ulwick. It maps customer importance against satisfaction with current solutions.

For each user need:
  Importance:   How important is this to the user? (1-10)
  Satisfaction: How satisfied is the user with the current solution? (1-10)

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

High importance plus low satisfaction equals a big opportunity. High importance plus high satisfaction means the need is already well-served. Low importance means it does not matter how poorly it is served.

Need                        Importance  Satisfaction  Opportunity
-----------------------------------------------------------------
Find relevant search results     9           4            14
Export data to CSV               6           7             6
Customize dashboard layout       7           3            11
Share reports with team          8           6            10
Set up automated alerts          5           2             8

Search and dashboard customization are the biggest opportunities. CSV export scores low even though satisfaction is moderate because importance is only moderate. Automated alerts look interesting (low satisfaction) but importance is middling.

When Opportunity Scoring Works

This framework shines when you have user survey data on importance and satisfaction. It is especially useful for mature products where you need to find the gaps in an existing experience.

When It Fails

It requires user data, which means it is useless for new products. It also weights visible needs over latent needs. Users can rate importance for things they know about, but they cannot rate importance for things they have never considered.

Kano Model

The Kano model, developed by Noriaki Kano, categorizes features by how they affect customer satisfaction. It distinguishes between features that are expected, features that are proportional, and features that delight.

Kano categories:

Must-haves (Basic):
  Absent = extreme dissatisfaction. Present = no satisfaction increase.
  Examples: Login works. Data doesn't get lost. Pages load.
  These are table stakes. You cannot skip them.

Performance (Linear):
  More = more satisfaction. Less = less satisfaction.
  Examples: Faster load times. More storage. Better search results.
  These are what users compare when evaluating competitors.

Delighters (Excitement):
  Absent = no dissatisfaction. Present = disproportionate satisfaction.
  Examples: Spotify Wrapped. Superhuman's keyboard shortcuts.
  Slack's custom emoji. These create word-of-mouth.

Indifferent:
  Users don't care either way.
  These are waste. Stop building them.

Reverse:
  Some users actively dislike the feature.
  Example: Auto-playing videos. Notification badges that can't be
  cleared. Features that add complexity without value.

How to Use Kano

For each feature, ask users two questions:

Functional question:
  "If [feature] were available, how would you feel?"
  Options: Delighted / Expect it / Neutral / Can live with it / Dislike

Dysfunctional question:
  "If [feature] were NOT available, how would you feel?"
  Options: Delighted / Expect it / Neutral / Can live with it / Dislike

The combination of answers classifies the feature.

                        If NOT available:
                    Delighted  Expect  Neutral  Live with  Dislike
If available:
  Delighted            ?       Delight  Delight  Delight   Linear
  Expect it            Rev     Indiff   Indiff   Indiff    Must-have
  Neutral              Rev     Indiff   Indiff   Indiff    Must-have
  Can live with it     Rev     Indiff   Indiff   Indiff    Must-have
  Dislike              Rev     Rev      Rev      Rev       ?

When Kano Works

Kano is excellent for product positioning decisions. Should you invest in polishing basics or building delighters? For a new product competing against incumbents, delighters differentiate. For a mature product losing customers, must-haves need fixing first.

Airbnb's early investment in professional photography was a Kano delighter. Nobody expected a vacation rental site to send a photographer to your apartment. It created disproportionate satisfaction and word-of-mouth.

When Kano Fails

Kano is a classification tool, not a sequencing tool. It tells you what type of value a feature delivers but not which feature to build first. You still need RICE or another framework for sequencing. Also, Kano categories shift over time. What was a delighter in 2015 (free cloud storage) is a must-have in 2025.

Choosing a Framework

Situation                          Recommended framework
--------------------------------------------------------------
Backlog of 20+ items, need order   RICE
Growth experiments, need speed      ICE
Mature product, need gap analysis   Opportunity scoring
Positioning decisions               Kano
Strategic bets                      None (use judgment + one-pager)

Most teams benefit from using RICE as a default and bringing in other frameworks situationally.

Making Frameworks Work in Practice

Calibrate as a Team

Run a calibration session where the PM, engineering lead, and designer independently score 5-10 items, then compare. Where scores diverge, discuss why. This builds shared understanding of what "high impact" means in your context.

Make Scores Transparent

Post the scores where everyone can see them. When someone asks "why are we building X instead of Y," point to the scores and the reasoning. Transparency builds trust even when people disagree with the outcome.

Revisit Quarterly

Scores change as you learn more. A feature scored low confidence six months ago might have high confidence now because you ran a prototype test. Refresh scores regularly.

Override When Necessary

Sometimes the framework says one thing and your judgment says another. That is fine. Override the framework, but document why. "RICE says feature A, but we're doing feature B because it unblocks a strategic partnership worth $2M/year." Now the override is explicit and auditable.

Common Pitfalls

  • Gaming the scores. People inflate scores for their pet projects. Combat this by having multiple people score independently and discussing outliers.
  • False precision. RICE to two decimal places is nonsense. The inputs are estimates. The output is directional, not exact.
  • Framework shopping. Trying five frameworks until one gives you the answer you want. Pick one, commit, and use judgment for exceptions.
  • Forgetting the framework is a communication tool. The primary value of a framework is not the score. It is the conversation the scoring process creates. If you skip the conversation, you have missed the point.
  • Using frameworks for strategic decisions. RICE cannot tell you whether to enter a new market. That is a strategy question, not a prioritization question. Do not force strategic decisions through tactical frameworks.

Key Takeaways

Prioritization frameworks are tools for structured thinking, not decision-making algorithms. RICE is the most broadly useful; ICE is faster for growth experiments; opportunity scoring reveals gaps in mature products; Kano classifies feature types. Calibrate scores as a team, make them transparent, and revisit them regularly. Override the framework when your judgment disagrees, but document why. The framework does not decide. You do.