Prioritization frameworks: RICE, ICE, MoSCoW, Kano, WSJF and more

A prioritization framework won't make the decision for you. It makes the trade-offs visible, so your team argues about evidence instead of whoever spoke last. This guide covers the eight frameworks product teams use most, with the formula, a worked example and the trap in each.

Every framework here scores the same sample backlog, so you can compare them directly. Edit it in the live scorer, or score your own list with the free RICE calculator and ICE calculator.

Why prioritization frameworks fail

Every product team has more ideas than time. A prioritization framework is a repeatable way to choose: score each item on the same few factors, sort, and argue about the result instead of the loudest opinion. Frameworks rarely fail because the maths is wrong. They fail for four other reasons.

• Made-up inputs. A score is only as good as the numbers behind it. If reach is a guess and impact is a hope, a precise-looking 412.5 is still a guess. Tie inputs to evidence: votes, conversations, usage data and revenue.
• The score becomes the decision. Frameworks sort a list. They don't know about your strategy, a promise sales made or the bug that will cost you a customer next week. Treat the ranking as the start of a conversation.
• One framework for every question. RICE is good at comparing features. It's poor at scoping a release with a fixed date, and it ignores timing. Pick the framework that answers the question you actually have.
• Scored once, never revisited. Estimates drift. A backlog scored in January is fiction by June. Re-score when the inputs change and keep the old numbers so you learn which estimates were wrong.

The rest of this guide walks through the common frameworks, then runs one sample backlog of eight items through every one of them, so you can see where they agree and where they don't. You can edit that backlog in the live scorer below the guide.

RICE: reach, impact, confidence, effort

RICE was popularised by Intercom's product team. It scores each item on four factors and combines them into one number:

RICE = (Reach × Impact × Confidence) ÷ Effort

• Reach: how many people the change affects in a set period, such as customers per quarter.
• Impact: how much it moves the goal for each of them, on a fixed scale: 3 massive, 2 high, 1 medium, 0.5 low, 0.25 minimal.
• Confidence: how sure you are of the other estimates, as a percentage. 100% means you have data, 50% means a hunch.
• Effort: the total work, in person-weeks or person-months, across design, engineering and everyone else.

In the sample backlog, an onboarding checklist reaches 3,000 people a quarter with medium impact, 60% confidence and 3 weeks of work: 3,000 × 1 × 0.6 ÷ 3 = 600. That's the top RICE score. SSO reaches only 120 people, so even with high impact it scores 32 and comes last.

Use it when features compete for the same team and you can estimate reach from real data. Watch for reach that counts people equally: 120 enterprise users may matter more than 3,000 free ones. Confidence is also easy to inflate; agree what 80% means before you score.

ICE: impact, confidence, ease

ICE, associated with growth marketer Sean Ellis, drops reach and scores three things from 1 to 10: impact, confidence and ease. Teams either average the three or multiply them.

ICE = (Impact + Confidence + Ease) ÷ 3

It takes seconds per item, which is the point. ICE was built for growth experiments, where you run many small tests and the cost of a wrong guess is low. The trade-off is resolution: with three 1 to 10 scales, lots of items land on the same score. In the sample backlog, dark mode, the onboarding checklist and the audit log all score 7.0 and tie for third.

Use it when you have a long list of cheap experiments and need a rough order quickly. Watch for ties and drift: one person's 7 is another's 5, so score together, and switch to RICE when the work is big enough to deserve real estimates.

MoSCoW: must, should, could, won't

MoSCoW comes from the DSDM agile method. It doesn't score anything. It sorts items for one release into four groups:

• Must have: the release fails without it. If you'd ship without it, it isn't a must.
• Should have: important, painful to leave out, but there's a workaround.
• Could have: nice to include if time allows.
• Won't have (this time): agreed out of scope for now. Writing these down is the most useful part.

Use it when the date is fixed and the scope has to flex, or when you need stakeholders to agree what's in and out. Watch for everything becoming a must. A common rule is to keep musts to around 60% of the effort, so the shoulds and coulds give you room when estimates slip.

Kano: basics, performance and delighters

The Kano model, published by Noriaki Kano in 1984, asks how each feature affects satisfaction. It sorts features into three main types:

• Basic (must-be): customers expect them. Having them earns no credit; missing them causes real dissatisfaction. SSO is a basic for an enterprise buyer.
• Performance: more is better, in a straight line. Faster onboarding, more integrations.
• Attractive (delighters): customers don't expect them, so leaving them out costs nothing, but including them delights. Over time, delighters become basics.

You find the category with a paired survey: for each feature, ask how a customer would feel if it were there, and how they'd feel if it weren't. The pattern of answers places the feature. Kano also names indifferent features (nobody cares) and reverse features (some customers would rather not have it).

Use it when you're deciding what a product or segment needs to be credible versus what will set it apart. Watch for treating it as a ranking. Kano tells you what kind of value a feature brings, not which to build first.

Value vs effort: the 2x2 matrix

The simplest framework of all: plot each item by value and effort, then split the grid into four quadrants.

• Quick wins (high value, low effort): do these first.
• Big bets (high value, high effort): plan them deliberately, one or two at a time.
• Fill-ins (low value, low effort): pick them up between bigger pieces of work.
• Money pits (low value, high effort): don't.

It works well in a workshop, because everyone can see the picture and move the sticky notes. The weakness is that "value" hides a lot: value to whom, and by how much? Two people will place the same item in different quadrants for different reasons. Use the 2x2 to start a conversation, then score the big bets more carefully.

WSJF and cost of delay

Most frameworks ask how valuable something is. Cost of delay asks what it costs you to wait. A feature worth a lot next month and nothing next year has a high cost of delay, even if its total value is modest.

Weighted shortest job first (WSJF), used in the Scaled Agile Framework, turns that into a score. It divides cost of delay by job size, so short, urgent, valuable work goes first:

WSJF = (Value + Time criticality + Risk reduction or opportunity) ÷ Job size

SAFe scores each part on a relative scale, often a modified Fibonacci sequence, comparing items against each other. The sample scorer below uses 1 to 10 and effort in weeks so the inputs line up with the other frameworks.

WSJF changes the order. The audit log reaches 80 people and comes seventh under RICE. But a security review is due and two deals are waiting on it, so urgency and risk are high. Under WSJF it scores (5 + 7 + 8) ÷ 4 = 5 and moves up to fourth. Dark mode goes the other way: lots of reach, but nothing is lost by waiting, so it drops to seventh.

Use it when timing matters: a contract, a regulation, a launch window, a competitor. Watch for urgency inflation. If everything is time critical, nothing is.

Weighted scoring

Weighted scoring lets you choose the criteria. List the three to five things that matter to your business this year, give each a weight that adds up to 100%, score every item from 1 to 10 on each, and add up the weighted scores.

The onboarding checklist scores 8 × 0.40 + 9 × 0.35 + 8 × 0.25 = 8.35, rounded to 8.4. The weights are where the strategy lives: a team moving upmarket might weight strategic fit at 50%, and SSO would climb.

Use it when leadership has clear goals and you want the backlog to reflect them openly. Watch for too many criteria. Past five, the weights blur and every item drifts toward the middle. Agree the weights before anyone scores an item, or people will tune them to get their favourite to the top.

Weighting by customer demand and revenue

Reach in RICE and value in a 2x2 are usually estimates. Customer demand is evidence: who asked, how many of them, and what they pay. Collecting it means putting requests and votes in one place, then looking at more than the vote count.

By votes, dark mode wins easily. By the revenue of the accounts asking, SSO alone is worth more than three times as much, and the audit log more than twice. Neither view is the answer on its own:

• Votes show breadth. They favour vocal users and free plans, and they miss customers who never visit your board.
• Revenue shows what's at stake today. It favours your largest customers and can starve the features that would win the next segment.
• Segments answer the useful question: what do the customers you're trying to win and keep actually want? Look at demand from your target plan or industry, not everyone.

A practical approach is to feed demand into your framework's inputs rather than replace it. Use the number of companies asking as RICE reach, or the revenue at stake as part of WSJF value, and say so next to the score.

How Quackback helps

Quackback collects requests and votes on feedback boards on every plan. Your team can add a vote on a customer's behalf from a post, and a support chat turned into feedback carries the customer's vote with it. You can sort requests by votes and see who voted.

You can record each company's plan and monthly revenue by hand or through the REST API (see companies). On Business and up, you can build segments from those attributes, such as companies on your top plan, and filter requests to the ones those customers posted. Votes aren't weighted automatically: every vote still counts as one, and the weighting decision stays yours.

Opportunity solution trees

Scoring frameworks rank solutions you already have. An opportunity solution tree, from product coach Teresa Torres, steps back a level. It starts with an outcome, maps the customer needs that could drive it, and only then lists solutions and the experiments that would test them.

• Outcome: one measurable result the team owns, such as week-4 retention. Not a feature.
• Opportunities: customer needs, pain points and desires, ideally in their own words from interviews and feedback. This is where your feedback board earns its keep.
• Solutions: several candidates per opportunity, so you compare options instead of falling for the first idea.
• Experiments: the cheapest test that would tell you whether a solution works.

Use it when you own an outcome and need to decide which problem to solve, not just which feature to ship. It pairs well with the scoring frameworks: choose the opportunity with the tree, then score the solutions under it with RICE or WSJF.

One backlog through every framework

Here is the same eight-item backlog for a B2B project management app, ranked four ways. You can change any input in the live scorer and watch the ranks move.

What the four rankings tell you together:

• They agree on the top. CSV export and Slack alerts are small, useful and well understood, so every framework ranks them highly. Ship them.
• They agree on the bottom. The mobile app is big and uncertain. Every framework puts it last or nearly last. It needs discovery before it needs a score.
• They disagree on SSO, the audit log and dark mode. RICE counts people, so it buries the two enterprise features. WSJF counts urgency and risk, so it lifts them. That disagreement is the conversation to have, and the customer demand data above is what settles it.

The other frameworks add what the scores can't. For a release aimed at enterprise readiness, MoSCoW would make SSO and the audit log musts, the onboarding checklist a should, CSV export and Slack alerts coulds, and the rest won'ts for this release. Kano would call SSO and the audit log basics for enterprise buyers, the onboarding checklist a performance feature, and AI summaries and dark mode delighters. An opportunity solution tree would ask whether the onboarding checklist and Slack alerts serve the outcome you're chasing at all.

Which framework should you use?

Start from the question you need answered, then pick the framework built for it.

Most teams settle on one scoring model for the backlog, MoSCoW for release scoping, and customer demand as the evidence under both. Whatever you choose, publish the result: a roadmap that shows what's planned, and a reply to the people who asked, so they know their request was weighed.