How to prioritize a roadmap with RICE

Baltej SinghBaltej Singh8 min read
How to prioritize a roadmap with RICE

How to prioritize a roadmap with RICE is a way to rank ideas with four scored factors instead of the loudest voice in the room. RICE stands for Reach, Impact, Confidence, and Effort. The score helps early teams compare hard-to-compare projects without pretending gut feel is a plan.

Intercom published the method as a simple prioritization tool for product managers: estimate reach, impact, confidence, and effort, then combine them into a single number you can sort (Intercom: RICE prioritization, checked 1 Nov 2026). Startups can use the same math with a shorter list and harsher honesty about confidence.

What does it mean to prioritize a roadmap with RICE?

To prioritize a roadmap with RICE, you score each candidate project, sort by score, then override only with named reasons such as a hard dependency or a table-stakes need. The framework is a decision aid, not a court order.

It is not a substitute for strategy. If the startup has no product focus, RICE will neatly rank noise. Pick the outcome you care about this season before you open the sheet.

Illustrative pattern (composite only): a three-person product team scores twelve candidates, ships the top two, and parks a pet idea that scored low on reach despite high excitement.

Keep the backlog short enough to score in a single sitting. A hundred unscored rows is a graveyard, not a roadmap.

Invite only people who can change an input. Spectators turn scoring into a debate club. Time-box the session and end with a sorted ranking plus named overrides, not with a promise to "finalize later."

Spell the factors before you multiply anything

Reach estimates how many people or events the change will touch in a defined period, such as customers per quarter. Prefer numbers from your product analytics over invented hope.

Impact estimates how much the change helps each person who encounters it. Intercom's scale uses 3 for massive, 2 for high, 1 for medium, 0.5 for low, and 0.25 for minimal. Pick one scale and freeze it for the season so scores stay comparable.

Confidence is a percentage that discounts shaky estimates. Common buckets are 100% high, 80% medium, and 50% low. Anything weaker is a moonshot until you gather evidence.

Effort estimates total person-months across product, design, and engineering (or whatever roles you actually have). More effort lowers the score because it divides the benefit.

Factor

Plain meaning

Early-startup tip

Reach

Who is touched, in a time window

Use last month's funnel counts, not dreams

Impact

How much it helps each person

Score against a single company goal only

Confidence

How solid the estimates are

Cap confidence when you lack user proof

Effort

Person-months to finish

Round up; founders under-price their own time

Write the units next to Reach each time (for example, "activated workspaces per quarter"). Mixed units make rankings dishonest.

For pre-revenue products, Reach can be "pilot users who hit this screen per 30 days" or "qualified waitlist signups who would see the change." Do not use total LinkedIn followers as Reach for an in-app change they will never open.

Calculate the score the same way each time

The formula Intercom uses is:

RICE score = (Reach × Impact × Confidence) ÷ Effort

Confidence enters as a fraction (80% as 0.8). Effort stays in the denominator so cheaper wins rank higher when benefits are equal.

Work a sample in the open so the team trusts the sheet. Example shape: Reach 450, Impact 3, Confidence 0.8, Effort 2 → (450 × 3 × 0.8) ÷ 2 = 540. Another idea with Reach 2000, Impact 1, Confidence 0.8, Effort 4 → 400. The first idea ranks higher even though the second touches more people, because impact and effort differ.

Do not hide the inputs. A score without Reach and Effort lines invites political rewrites later.

Show the formula at the top of the sheet so newcomers do not invent a different one. If someone proposes replacing Effort with "story points," pick a single unit for the season and stick to it. Mixing person-months and points in the same denominator corrupts the sort.

Re-score when new evidence arrives. Confidence should rise after a prototype test or fall after an engineering spike reveals mess. Static scores go stale.

Build a scoring sheet founders will actually update

Create a single table with columns for idea name, Reach, Impact, Confidence, Effort, score, owner, and notes. Sort by score descending after each batch of edits.

Limit active candidates to what you can discuss in half an hour. Archive the rest with a date so they do not haunt the sort.

Assign a single sheet owner. Shared editing without an owner produces competing versions and silent score changes.

When a cofounder wants to boost a favorite, change an input with a written reason, not the final score by hand. Hand-edited totals destroy trust in how to prioritize a roadmap with RICE.

Screenshot or export the sorted ranking after each scoring meeting. Without a dated snapshot, people rewrite history when a low-scoring pet idea suddenly jumps the queue.

Store the sheet where the team already looks for work, next to Task boards if you use them (Task boards help). The board tracks execution; the sheet decides sequence.

Use overrides sparingly and name them

Dependencies can force a lower score earlier. Table-stakes items for a sale can force a lower score earlier. Legal or safety fixes can jump the queue. Write the override reason in the notes column on the same day.

If everything is an override, you are not using RICE. You are decorating a priority ranking you already chose by politics.

A healthy pattern is rare overrides with boring scores. A sick pattern is a beautiful sheet nobody believes, while the real order lives in a private chat between cofounders.

Review overrides in the same meeting where you pick the next build. Silent overrides teach people to ignore the sheet.

Strategy still wins ties. When two scores are close, prefer the idea that teaches the riskiest assumption this month. Learning value is a valid tie-break when you say so out loud.

Work a live example before you trust the ranking

Before the first real ranking meeting, score three contrasting ideas together: a small copy fix, a medium feature, and a large rewrite. Force Reach units, Impact against the same goal, Confidence buckets, and Effort in person-months.

Discuss where the ranking feels wrong. Usually the discomfort is an honest signal that Impact was inflated or Effort was fantasy. Fix the inputs, not the sort order by hand.

Save that worked example as a tab in the sheet labeled "calibration." New teammates learn faster from a filled sample than from a blank template and a lecture about the acronym.

If engineering and design disagree on Effort by more than a person-month, run a short spike before you finalize the score. Disagreement is data; averaging angry guesses is not.

Keep RICE from becoming theater

Refuse vanity Reach numbers pulled from total signup counts when the change only hits a tiny segment. Segment the Reach to the people who will actually see it.

Refuse Impact scores of 3 on every row. If everything is massive, nothing is. Cap how many 3s you allow in a batch.

Refuse Effort of 0.5 on vague epics. If you cannot name the weeks of work, spike first and then score.

Connect finished builds back to evidence. After a scored item ships, note whether Reach and Impact guesses were high or low so later scoring rounds improve. In Nautis, real results can feed the Learning engine as recorded lessons (Learning engine help). That memory is optional; the honesty loop is not.

Pair roadmap ranking with a clear market-proof horizon when growth projects is in the mix, such as a 30-60-90 go-to-market plan. RICE sequences builds; the go-to-market plan sequences market proof. Do not ask one sheet to do both jobs.

Revisit the whole list when the product focus changes. Old high scores for a retired focus are traps.

Run a calibration pass the first time the team scores together. Pick three past ships you already shipped, score them as if they were still candidates, and compare the ranking to what you wish you had built first. Calibration teaches the scale faster than a lecture.

When contractors join a scored item, include their person-months in Effort. Leaving paid help out of the denominator quietly inflates scores for outsourced work.

Publish the top five scores in the same channel where people request features. Transparency reduces side-channel lobbying more effectively than another "no new ideas" speech.

How to prioritize a roadmap with RICE works when the factors stay visible, the math stays boring, and overrides stay rare and named. Score in the open. Sort. Ship the top honest row.

When scores feel noisy, pause new candidates and finish the top honest row already on the ranking.

Prefer a boring sheet that people trust over a clever method nobody updates. Trust is the scarce resource; the acronym is not.

If a candidate cannot state Reach units, Impact aim, Confidence basis, and Effort range in one breath, leave it unscored until those answers exist.

If a candidate cannot survive those four questions, leave it unscored until the answers exist.

Frequently asked questions

How do you prioritize a roadmap with RICE?

Score each candidate on Reach, Impact, Confidence, and Effort, compute (Reach × Impact × Confidence) ÷ Effort, sort descending, then override only with a written reason.

What does RICE stand for?

Reach, Impact, Confidence, and Effort. Intercom popularized the scoring method for comparing product ideas consistently.

Should the highest RICE score always ship first?

Usually yes, unless you name an override such as a dependency, a safety fix, or a table-stakes requirement. If everything is an override, the sheet is theater.

How many ideas should we score at once?

Only as many as you can discuss in about half an hour. Archive the rest with a date so unscored rows do not haunt the ranking.

Sources

Baltej Singh
Baltej Singh

Baltej Singh is a serial entrepreneur, technology leader, and Founder & CEO of Nautis and DemoVexa, with over 16 years of experience building software products, SaaS platforms, and startups. Previously the Co-Founder & CTO of SanchiConnect, he has worked extensively in the DeepTech startup ecosystem, connecting with 200+ venture capital firms and supporting a network of 4,000+ startups. Passionate about AI, automation, and entrepreneurship, he focuses on building innovative products that solve real-world problems and help businesses grow.

How to prioritize a roadmap with RICE scoring