RICE Prioritization in the AI Era: How to Decide What to Build When You Can Build Anything

A few weeks ago, we sat down at Full Scale to figure out which of our own internal projects actually mattered. We interviewed about 30 people across the company. Everybody had ideas. Everybody had a list of things they were sure we needed to build. By the end I had a giant pile of requests and almost no agreement on what came first.

That is the job. The hardest part of being an engineering leader isn’t shipping the code. It’s figuring out the roadmap and the priority when everybody is a stakeholder and everybody has an opinion. You don’t know what to do, and the cost of guessing wrong is months of your team’s life.

Here’s my own dirty secret about this. I don’t use a framework for myself. I wake up every day already knowing the three most important things to do. I don’t need a roadmap or a scoring model to tell me, and a lot of experienced leaders will say the same.

So I get why some people look at RICE and shrug. If you already know your priorities, the scoring looks like busywork.

But a team is not one person with one list. It’s a dozen people like me, each walking in with their own short list, each sure their three things are the right three. The hard problem was never knowing my priorities. It’s reconciling everyone’s. That’s what a framework is actually for, and it’s why RICE can feel pointless to an individual and indispensable to a team.

RICE prioritization, the scoring model that came out of Intercom, is one of the simplest ways to turn that pile of competing lists into a ranked one you can defend. It’s the step that turns a wish list into an actual product roadmap.

RICE works, it falls apart in a few predictable places, and it matters more now than it ever has, because something changed. AI can write the code now, and the deciding is the part nobody can automate.

Most engineering leaders aren’t product people

Here’s something I’ve watched for twenty years. A lot of engineering leaders are not product people, and they don’t pretend to be. They’re great at the part they trained for: how to architect a system, how to build it, how to make it scale. Ask them how to build something and you get a clear answer.

Ask them whether it’s worth building, and they get quiet.

Judging value is a different muscle. It means weighing how many people a thing helps, how much it helps them, and whether you even believe your own estimates. That doesn’t come naturally to someone who spent a decade getting good at databases and distributed systems. Somebody on the team has to carry that product judgment, whether or not they have the title to match.

A simple scoring framework like RICE forces a builder-minded leader to think like a product person, at least for an hour. It puts value and outcomes on the table next to effort. Even when the math is rough, the act of stepping back to ask “what does this actually deliver” is the most valuable thing the framework does. Hold that thought.

What RICE prioritization actually is

RICE is a scoring model for ranking projects against each other. A product manager named Sean McBride built it at Intercom and named it after its four inputs: Reach, Impact, Confidence, and Effort. It extends an older, simpler model called ICE, which scored Impact, Confidence, and Ease, by adding Reach to the mix.

You score each idea on all four, run a quick formula, and get a single number you can sort by. The point is to compare ideas in a consistent way instead of going with whoever argued loudest in the meeting.

Here’s what each letter means.

Reach is how many people the project touches in a set window of time. Customers per quarter, users per month, whatever fits, as long as you use the same window for every project you’re comparing. Use real numbers from your product analytics if you have them, not a number you pulled out of the air.

Impact is how much the project moves the needle for each person it reaches. Intercom scores it on a fixed scale so you’re not agonizing over decimals: 3 for massive, 2 for high, 1 for medium, 0.5 for low, 0.25 for minimal.

Confidence is how much you trust your own Reach and Impact estimates. It’s a percentage: 100% if you have hard data, 80% if you have some, 50% if you’re mostly guessing. This is the input that keeps an exciting idea with no evidence behind it from jumping the line.

Effort is the total work, measured in person-months across everyone involved: product, design, and engineering. More effort is a bad thing here, so it works against the score.

How to calculate a RICE score

The formula multiplies the three good things and divides by the cost:

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

What you get is roughly “value per unit of effort.” Higher is better. Sort your list by it and you have a starting order.

Here are the standard scales in one place:

Input	How to score it
Reach	People affected per time period (real count)
Impact	3 massive, 2 high, 1 medium, 0.5 low, 0.25 minimal
Confidence	100% high, 80% medium, 50% low
Effort	Total person-months (whole numbers)

Let’s run three real-ish projects, keeping every Confidence value on the scale above.

Say Project A reaches 1,200 users a month, has high impact (2), 80% confidence, and takes 2 person-months. That’s (1,200 × 2 × 0.8) ÷ 2, which comes out to 960.

Project B reaches 800 a month, and you think the impact is massive (3). But you’re working off a hunch, so confidence is only 50%, and it takes 2 months. That’s (800 × 3 × 0.5) ÷ 2, or 600.

Project C reaches the most people, 4,000 a month, but the impact per person is only medium (1). Confidence is solid at 80%, and it’s a big lift at 4 months. That’s (4,000 × 1 × 0.8) ÷ 4, or 800.

So Project A wins, even though Project C reaches more than three times as many people and Project B looked like the home run. The exciting idea you can’t back up (B) and the expensive crowd-pleaser (C) both lose to the well-understood, cheaper bet. That’s the framework doing its job. It stops you from chasing the biggest reach or the most exciting idea and makes you weigh value against cost.

Where RICE breaks

I’m not going to sell you on RICE as some objective machine, because it isn’t one.

Two of the four inputs are basically educated guesses. Impact is a number you assign based on how you feel about a feature. Confidence is your gut, dressed up as a percentage. You can run the cleanest formula in the world and still be multiplying two numbers you made up.

The scores also get gamed. People walk into the meeting already knowing what they want to build, and then they reverse-engineer the inputs to make their favorite idea win. A high Impact here, a generous Reach there, and suddenly the math agrees with the answer they brought in the door.

And effort estimates always run long. The project you scored at 2 person-months turns into 4 once you hit the part nobody thought about. Since effort is the denominator, a bad estimate there throws off everything.

None of this means RICE is useless. It means you should treat the score as one input, not a verdict. Even Intercom says so. Their own guide is clear that the score “shouldn’t be used as a hard and fast rule,” because sometimes a low-scoring project is a dependency for a big one, or it’s table stakes to land a customer. The number starts the conversation. It doesn’t end it.

The real point of RICE isn’t the score

That’s true for one leader, and it gets truer when a whole team does it. Here’s the part most guides miss.

The value of RICE was never the number it spits out. It’s that it makes a room full of people stop and think.

When my team scores an idea together, we have to argue about the Reach. We have to defend the Impact. Somebody says “I think this is massive,” and somebody else asks why, and now we’re actually talking about who this helps and how much. The score isn’t the deliverable. It’s the forcing function. You can’t assign an Impact number without arguing about who the work helps, so the number drags a real conversation out of people who would otherwise skip it. That argument is worth more than the score it produces.

I’ve run some version of this at VinSolutions and Stackify too, long before Full Scale. The tools got better. The hard part never changed.

Even if the process is messy, even if half the numbers are soft, the fact that you forced everyone to step back and reason about value and outcomes is the win. You replaced “the loudest person decides” with “we looked at this together.” For a builder-minded team that defaults to “let’s just build it and see,” that shift is enormous.

So don’t obsess over getting the math exactly right. Obsess over having the conversation at all.

Why RICE prioritization matters more in the AI era

For most of my career, the bottleneck in software was building. You had a long list of things you wanted, and not enough engineering hours to do them. Prioritization mattered because you were rationing a scarce resource.

That world is ending.

AI can write the code now, and it can write a lot of it, fast. Tools like Claude Code can chew through a well-defined backlog at a pace that would have seemed absurd two years ago. The refactors, the small features, the cleanup tickets your team kept deferring, a capable AI can knock those out in a long weekend.

Which means the old excuse is gone, at least for the work you can define well. You can’t say “we didn’t get to it because we didn’t have the hours.” The catch is that someone still has to review what the AI writes, and the messy, ambiguous problems still take real engineering judgment. The cheap part is the building you can specify clearly. The expensive part is knowing what to specify.

The problem was never how fast you can write code. It’s how fast you can make good decisions and build the right things. And that has never mattered more than it does today.

The cost of a wrong call has dropped to a weekend. That sounds like progress until you realize you can now pile up useless features faster than your team has ever built anything. The only thing standing between you and a fast, confident march in the wrong direction is the judgment to decide what’s worth building.

That judgment is the scarce resource now. A framework like RICE, which exists to force that judgment, is more useful in a world where the building is the easy part. It’s the same reason I keep arguing that cutting scope beats adding more process: the constraint was always knowing what to build, never the raw ability to build it. The work that’s left for engineering teams is the work AI can’t do, the work that takes taste, customer empathy, and the nerve to say “we shouldn’t build this.”

RICE is one way to make that call out loud.

RICE and shared ownership

There’s a second thing scoring does that I didn’t appreciate until I’d run it a few times.

It builds buy-in.

When you rank projects in the open, everyone can see why their idea landed where it did. The person whose feature came in fourth can look at the board and understand that it scored lower than three other things, not that their idea got ignored or that they lost a political fight. People will accept a low rank they can see far more easily than a decision made behind a closed door.

That’s the part that ties into how I think about building teams. The goal isn’t a manager handing down a roadmap. It’s a team that understands the priorities well enough to own them, and to see where the big problems are that need someone to step up. Visible scoring spreads that understanding around. It turns prioritization from a thing that happens to the team into a thing the team does together.

That idea, that engineering teams win when ownership is shared instead of dictated, is the whole argument of Product Driven. A scoring framework is a small, practical way to start living it.

How to actually run it

You don’t need fancy tools to start. A spreadsheet works, and Intercom even publishes one.

That said, once you’re doing this regularly, dedicated tools help. I’ve leaned on Aha! and Jira Product Discovery to capture ideas, gather the impact and effort inputs from the team, and keep the scoring honest across a lot of projects. They take the bookkeeping off your plate so you can spend the meeting arguing about value instead of fighting a spreadsheet.

A few things I’d tell any leader starting out:

• Score as a group. The argument is the point. If one person fills in all the numbers on their own, you lose the part that makes it worth doing.
• Be honest about Confidence. It’s the input people skip, and it’s the one that protects you from your own enthusiasm.
• Revisit the list. Estimates change as you learn, so a score from three months ago is a starting point and not a permanent ruling.
• Let the framework report to you, not the other way around. If the math says build something your gut says is wrong, that’s a signal to recheck your inputs, not to override your judgment.

However you run it, the job that’s left is the one that matters most now: deciding what’s worth building. RICE is just a way to force that call into the open.

If the real constraint on your roadmap turns out to be capacity rather than clarity, that’s a different problem, and it’s the one staff augmentation is built to solve. Once you know what’s worth building, you can add the engineers to ship it, often for less than you’d expect.