A practical prioritisation framework for engineers who care about building the right thing — and how to use it to make sure your team always is.

Most software that fails doesn't fail because of bad code. It fails because someone built the wrong thing. Wrong priority. Wrong moment. Wrong assumptions about who would use it and how much they'd care. The code was fine. The decision was broken.

Engineers have ceded prioritisation to product managers, roadmaps, and whoever shouts loudest in the planning meeting. That's a mistake — not because PMs can't do it, but because engineers who understand prioritisation write better software. They ask different questions before they write a single line. They push back on work that doesn't make sense. They spot when a feature with a three-month estimate is solving a problem five users have once a quarter.

RICE was developed by Sean McBride at Intercom to solve exactly this problem: too many ideas competing for attention, and a planning process producing more heat than signal. McBride's insight was to break the vague question "how impactful is this?" into four smaller questions that are individually answerable with data — or that at least force you to be honest about where your certainty ends. The result was RICE: Reach, Impact, Confidence, Effort.

At uRadical, it's part of how we work. We've used it across SafeOps365 — an operational safety compliance platform for the energy sector — Music Bingo Live, and MyWelcomeBook, a multi-tenant SaaS for independent hospitality. Different domains, different constraints, same underlying question: are we building the thing that matters most right now? RICE keeps that question honest.

The formula:

Here's how each component works, and why product-minded engineers should own the whole exercise.

Reach

How many people will this affect, in a given time period?

This is a count, not a vibe. Pick a time window — typically a month or a quarter — and estimate how many users, customers, or events will be touched by this feature.

Not "our whole user base might see this." Specifically: how many users encounter the screen, flow, or pathway where this change applies? If you're improving a checkout confirmation page, how many purchases happen per month? That's your reach, not your total registered users.

This is the point where engineers who have access to logs and analytics have a natural advantage. Pull the numbers. If you can't, ask — and note that you had to guess. That note matters when you get to Confidence.

Impact

How much will this affect each user who encounters it?

This is deliberately harder to quantify, and RICE doesn't pretend otherwise. Intercom uses a fixed scale to prevent endless arguments over precision you don't actually have:

Pick a number honestly. If you're adding a convenience feature that saves two clicks, that's not a 3. If you're fixing the thing that causes 30% of your trial users to abandon before they see any value, that might be. The important thing is consistency — use the same scale across every feature you're comparing, otherwise the scores are meaningless relative to each other.

Confidence

How certain are you about your Reach and Impact estimates?

This is RICE's honesty mechanism — and the component most teams misuse by ignoring it. If your reach number comes from analytics, your confidence should be high. If your impact score is based on one sales call and a gut feeling, it shouldn't be.

Anything below 50% is a signal you need more information before committing engineering time. Not that the idea is bad — that you don't know enough yet.

Effort

How much total work will this take, in person-months?

Effort is the denominator — it divides your benefit, so more is a bad thing. Estimate in person-months, counting everyone involved: design, engineering, testing. Intercom uses 0.5 for anything well under a month. Resist the urge to be precise beyond whole numbers — the other factors don't warrant it, and false precision in the effort estimate is its own kind of wishful thinking.

This is the part engineers are usually best at, which is exactly why they need to be in the room for the whole exercise and not just called in to estimate at the end.

Putting It Together

Using the examples above:

Now score another candidate — say, a new dashboard widget that three enterprise customers have requested:

The onboarding validation fix scores 6,720. The enterprise dashboard widget scores 20. This is the kind of clarity that ends long planning debates quickly.

Note what happened to the enterprise widget: three loud customers made it feel like a priority. The RICE score exposed that it affects a tiny slice of users, the impact estimate was half-confident, and it costs two months to build. That's not a no — it might still be the right call for commercial reasons — but now you're making a deliberate trade-off, not an accidental one.

Why Engineers Should Run This, Not Just Attend It

RICE is usually taught as a product management tool. That framing is too narrow.

Engineers bring the data that makes RICE honest. Reach estimates from someone without log access are guesswork. Confidence scores from someone who hasn't read the error reports are optimistic. Effort estimates from anyone who isn't going to write the code are frequently wrong.

More importantly, engineers who run RICE thinking — even informally — before picking up a ticket make better decisions about what to build first, what to simplify, and what to push back on. The discipline of asking how many people does this help, how much, and how sure are we is the discipline of a product-minded engineer. It's not someone else's job. It's the difference between building software that matters and building software that ships.

You don't need a formal session for every decision. But for anything that will take more than a few days, running the numbers takes twenty minutes and produces either confidence or doubt — both of which are useful before you start writing code.

The Score Is Not the Decision

RICE scores are inputs to a conversation, not outputs of one. A lower-scoring feature might need to ship first because it's a dependency. A higher-scoring feature might be blocked on third-party constraints. Sometimes you build something because a key customer needs it and the RICE score doesn't capture that commercial reality.

That's fine. The point of a scoring framework is not to remove judgement — it's to make trade-offs explicit. When you override the score, you know you're doing it. You can articulate why. You can revisit when circumstances change.

That's a better place to be than acting on whoever argued loudest.

Getting Started

You don't need tooling. A shared spreadsheet with columns for Feature, Reach, Impact, Confidence, Effort, and Score will do it. Score five or ten items from your current backlog and see what the ranking tells you. It will almost certainly surprise you.

Run it at the start of a planning cycle, or whenever the team can't agree on what to do next. The framework is simple. The discipline is the hard part. And the discipline is exactly what separates engineers who ship work that matters from engineers who are busy all year and wonder what they actually built.