By 6days · v1.0 · Updated 7/20/2026
Score competing work on reach, impact, confidence and effort so the argument is about evidence.
Fill this in for your own situation — a private worksheet only you can see.
When to use
Use it when you have many comparable candidates competing for one team's capacity, when prioritisation has become political and you need a neutral vocabulary, or when you need to explain to stakeholders why their request did not make the cut without it being personal.
When not to use
Avoid it for work that is not discretionary — security fixes, legal obligations and keeping the service up do not get scored, they get done. It handles strategic bets badly: anything genuinely new scores low on confidence and reach by construction, so a team that follows RICE mechanically will optimise itself into small safe increments forever. It also cannot see dependencies or sequencing.
Every roadmap has more candidates than capacity, and the selection usually goes to whoever argues best — the loudest stakeholder, the most recent customer escalation, the executive's pet idea. The team cannot articulate why one item beat another, so the decision cannot be revisited when things change, and everyone suspects, often correctly, that the process is political rather than analytical.
RICE scores each candidate on four factors and combines them into a single number: reach (how many people it affects in a period), impact (how much it moves the thing you care about, per person), confidence (how much you trust your own reach and impact estimates) and effort (person-time to deliver). Multiply the first three, divide by effort. The output is deliberately crude. Its value is not the ranking but the conversation the scoring forces: confidence makes the team say out loud how much of the case is guesswork, and comparing two items usually reveals that a disagreement about priority was really a disagreement about an estimate.
Framework by 6days on 6days — https://6days.apexaion.ai/framework/rice-prioritisation
Decide what 'impact' means before scoring anything — activation, retention, revenue, support load. Without one agreed metric, scores are not comparable and the whole exercise produces a number that means nothing.
Count how many users or events this touches per quarter, using real numbers wherever they exist. Reach is the factor most amenable to evidence, and grounding it prevents the whole score from floating free of reality.
Use a deliberately blunt scale — massive, high, medium, low, minimal — rather than pretending to precision you do not have. False precision here creates unearned confidence in the ranking.
Discount for how speculative your estimates are. This is the factor that does the real work: it stops a thrilling idea with no evidence from outranking a modest one with data, and it makes the team admit which is which.
Estimate total person-months across all functions, not just engineering. Compute the scores, then interrogate the ranking — where the number offends someone's intuition, find out which input they disagree with. That argument is the actual output.
Worked example
Two candidates. A bulk-export feature: reach 400 users/quarter, impact 1 (medium), confidence 80%, effort 2 person-months — score 160. A redesigned onboarding flow: reach 3,000 new signups/quarter, impact 2 (high), confidence 50% (the evidence is one small study), effort 6 — score 500. Onboarding wins by roughly three to one, which surprises the room because export is what customers ask for by name. The disagreement resolves to a single input: the sales lead thinks onboarding's confidence should be 20%, not 50%. At 20% the ranking flips. Now the team knows exactly what to go and find out, which the argument alone would never have produced.
The scoring model was developed and published by the team at Intercom in the mid-2010s to prioritise their own roadmap, and was shared openly rather than commercialised. It sits within a much older tradition of weighted scoring in project selection; its contribution is the specific inclusion of a confidence discount, which is what distinguishes it from earlier value-over-effort schemes.
Related ways to think about this.
People don't buy products, they hire them for a job — find out what the job is.
Use when Use it when demographic segmentation has stopped generating insight, when you cannot explain why customers churn or convert, when entering an adjacent market, or when a roadmap has become a queue of the loudest requests with no organising logic.
Avoid when Avoid it for incremental optimisation of a well-understood product — you know the job, and reopening it is procrastination. It is weak for infrastructure and compliance work with no discretionary hiring decision. Done badly it collapses into vague poetry about customer aspirations, and 'the job' becomes whatever the loudest person already wanted, now with better rhetoric.
Sort what you know about a decision into four buckets so the gaps become obvious.
Use when Use it early, when a group needs to pool what it collectively knows before choosing a direction — entering a market, responding to a competitor, or opening annual planning. It is most valuable when the people in the room hold different pieces of the picture and have never assembled them in one place.
Avoid when Avoid it when you need a decision rather than an inventory: SWOT ranks nothing and will not tell you what to do. It rewards confident assertion, so it degrades badly in rooms with a strong seniority gradient. And it is a snapshot — for anything fast-moving it dates quickly, and a stale SWOT presented as current is worse than none.
Separate urgent from important, and notice how much of your week serves neither.
Use when Use it when you are busy but not progressing, when a team is permanently reactive, or during a periodic review of where a role's time actually goes. It works well as a recurring habit rather than a one-off, and it is a useful device for a manager and report to look at a workload together without it becoming personal.
Avoid when Avoid it where you have little real autonomy — telling someone to delegate work they cannot delegate is just a way of blaming them for their constraints. It handles individual tasks better than long collaborative efforts, and it has nothing to say about work that is important to someone else and not to you, which is most of what makes a job hard. It also assumes you can tell importance from urgency, which is exactly the skill people struggling with this tend to lack.