Back to articles
03.14 — Roadmap prioritization: beyond RICE
·15 min read

Roadmap prioritization: beyond RICE

JB · jarodbarrera.comDRAWING NO. RP-01 · 01 OF 01RICE PLUS TWORICE handles the math. The two it skips are where most roadmap arguments actually happen.RICE · the mathREACHIMPACTCONFIDENCEEFFORTthese tell you HOW MUCH — but not WHY or WHAT YOU’RE SAYING NO TO++ TWO · the meaningSTRATEGIC FITDoes this item move one of this year’s bets? If not, high RICE score is irrelevant.TRADEOFF VISIBILITYIf we say yes to this, what specifically are we saying no to? Make the cost of the choice visible.RICE alone produces a sorted list. RICE plus two produces a defensible decision.

I've used RICE in four different companies. It's a useful tool — reach, impact, confidence, effort, out comes a number, you rank the list, you ship the list. Clean. Defensible. And it breaks in every organization I've been in, usually by the end of the second quarter.

That's not a knock on RICE. It's actually a pretty elegant heuristic for a specific problem: when you have a lot of undifferentiated ideas and need a quick first-pass filter. But most product teams I've worked with aren't drowning in undifferentiated ideas. They have a mix of customer requests, strategic bets, platform investments, executive mandates, and dependencies tangled up together — and RICE scores don't capture any of that complexity.

So I stopped treating RICE as the answer and started treating it as one input among several. Here's how I actually think about prioritization now.

Where RICE earns its keep — and where it doesn't

To be fair: RICE is genuinely good at what it was designed to do. When you're sitting in front of fifty feature requests from customer support tickets and you need to identify the twenty worth discussing, a scored ranking is exactly right. It's fast, it's transparent, and it gets everyone into a shared framework quickly.

But it starts breaking down as soon as you hit these situations:

Platform work has near-zero "reach" by RICE logic. Migrating to a new auth system, rebuilding the data pipeline, improving test coverage — none of these touch users directly, so they score low every time. But if you don't do them, your ability to ship anything else degrades. I've watched teams consistently deprioritize platform investments for six quarters and then wonder why velocity cratered.

Strategic bets require judgment, not math. When you're deciding whether to build a new vertical, expand into enterprise, or launch an AI feature, you're making a bet on the future state of the market. There's no honest way to put numbers on "impact" and "confidence" for a move like that. If you try, you're just laundering your intuition into a spreadsheet format.

Dependencies don't exist in RICE world. Item A might score a 2.4 and Item B a 4.1, but if A has to ship before B makes any sense, you're building the roadmap in the wrong order. RICE treats every item as independent when real product work is deeply sequential.

Team capacity and skill mix change what's actually buildable. A feature that requires machine learning expertise scores the same whether you have two ML engineers or none. The score doesn't know what your team can do.

JB · jarodbarrera.comDRAWING NO. RP-02 · FIG 1WHERE RICE IS BLINDFive places the formula gives you the wrong answer. Or worse — the right number for the wrong work.Strategic misfithigh blindItems can score high RICE while pulling away from this year’s actual bet.Confidence inflationhigh blindEveryone scores their own item at 80%+ confidence. The number does no useful filtering.Tradeoff invisibilityhigh blindRICE ranks items. It never tells the team what WAS CUT to make room for the winner.Compound dependenciesmed blindItems that unlock other items get the same score as standalone ones. The chain effect is invisible.Effort underestimationhigh blindPMs systematically underestimate effort. Always. The math optimizes around a number that’s 2-3x too low.If the formula were enough, no one would argue about priorities. They argue because the formula is only half the job.

The model I actually use

After enough frustration, I landed on a three-layer approach. It's not a framework I invented — it's closer to how good PMs I've worked with naturally think, made explicit.

Layer 1: Strategic themes. Before I score anything, I establish the two or three strategic themes that matter for the period. These come from company strategy, from what I know about where the market is moving, and from conversations with leadership about what success looks like. They're not vague aspirations — they're specific: "close the gap with competitor X on collaboration," or "reduce churn in the SMB segment below 8%." Everything we consider for the roadmap has to map to at least one theme, or it doesn't make the list.

This sounds obvious but it changes the conversation dramatically. Instead of arguing about whether a feature scores a 3.2 or a 3.8, you're asking: does this thing actually move one of the needles we said we care about? A lot of low-value requests fall away at this layer without needing to score them at all.

Layer 2: Item scoring. This is where something like RICE can live, but calibrated. I use a simplified version: impact on the strategic theme (not general user impact), effort, and a confidence multiplier. I also add a "now or never" flag for time-sensitive opportunities — things that matter because a competitor just launched, because a customer contract is contingent on a feature, or because a window is closing.

The scores here are directional, not precise. I'm not trying to produce the True Rank Order. I'm trying to separate obvious priorities from obvious deprioritizations, with a middle zone I'll decide through judgment.

Layer 3: Feasibility and sequencing. Once I have a rough sorted list, I run it through two questions: can we actually build this given our current team and debt load, and does the order make sense given dependencies? Platform investments that were invisible to RICE show up here as prerequisites. External dependencies (waiting on a partner API, waiting on legal review) get flagged. The sequence gets rearranged based on what unlocks what.

JB · jarodbarrera.comDRAWING NO. RP-03 · FIG 2THREE LAYERS, ONE DECISIONStrategic bets up top. Solution options in the middle. Tickets at the bottom. Confuse the layers and the argument moves to the wrong level.LAYER 1 · STRATEGIC BETS3–5 per yearThe few outcomes you committed to move. The bets that justify the team’s existence this year. Set by leadership, not by the team.LAYER 2 · SOLUTION OPTIONS3–5 per betHypotheses about what would move the bet. This is where RICE earns its keep — ranking solution options inside a strategic frame.LAYER 3 · TICKETS / TASKSmanyDay-to-day work that delivers a chosen solution option. Sprint planning lives here. Strategic priority discussions DO NOT.Most “prioritization” arguments are really layer-confusion arguments. Name the layer. The decision gets easy.

This isn't dramatically more complicated than RICE. It's maybe two extra hours of work per planning cycle. But it catches the category of errors that RICE consistently misses — the strategic misalignments, the ignored dependencies, the platform debt that accumulates until it stops everything.

Making tradeoffs visible

The other thing RICE quietly buries is tradeoffs. When you generate a ranked list, it implies that you're doing the top items and not doing the bottom ones. But that's rarely how it works. You're making decisions about which customers to prioritize, which bets to take, which debt to tolerate — and those decisions deserve to be explicit.

I started keeping what I call a tradeoff log alongside the roadmap. It's a simple table: decision, what we're choosing to do, what we're explicitly not doing as a result, and who agreed to the tradeoff. It's not about covering my ass (though that's occasionally useful). It's about forcing the team and stakeholders to actually engage with what we're giving up.

The most common pushback I get on this is: "You're overthinking it. Just build the best stuff first." But that framing hides a value judgment: what's "best" depends entirely on what you're trying to achieve. A feature that's best for enterprise accounts might be terrible for the self-serve segment we're trying to grow. A feature that's best for immediate revenue might cannibalize the strategic positioning we're building for three years from now. The tradeoff log forces those judgments into the open.

JB · jarodbarrera.comDRAWING NO. RP-04 · FIG 3THE TRADEOFF LOGWhen you say yes to something, write down what you said no to. Six months later you’ll need this trail.WE SAID YES TOWHICH MEANS WE SAID NO TOBECAUSEOnboarding redesignMobile app v2 feature parityActivation > expansion this quarterSearch rewriteAnalytics dashboard polishSearch is 3rd most-cited churn reasonAI summarization v1Custom-trained ranking modelAPI now hits 90% of the valueEnterprise SSOFree-tier improvementsTwo $200K contracts blocked on itAPI rate-limit overhaulNew billing page redesignRate limits triggering enterprise escalationslog lives in the team’s memory store. Review every when reflecting on lagging metrics. Unwritten tradeoffs become unrecognized commitments.

Communicating prioritization decisions

I'll be direct about something: most prioritization communication is bad. It's either too detailed (here's our RICE spreadsheet, good luck) or too vague (we're focused on our strategic priorities). Neither builds trust.

What actually works, in my experience, is a narrative explanation anchored to the theme, paired with honest acknowledgment of what you're not doing.

Something like: "This quarter we're prioritizing retention in the enterprise segment because churn there is significantly more expensive than in SMB, and we've identified three high-confidence interventions. That means we're pushing back the self-serve onboarding redesign, which I know has been waiting. Here's why and here's when we expect to revisit it."

The "here's when we expect to revisit it" part is underrated. PMs often make decisions and then never close the loop with the people who asked for something different. You don't have to say yes to everything. You do have to help people understand the logic and feel heard.

I also make a point of communicating the confidence level honestly. "We believe this will reduce churn by 15–20%, based on the cohort analysis we ran last month" is more trustworthy than "this will increase retention." Stakeholders can handle uncertainty if you're straight with them. What they can't handle is being told something was certain when it clearly wasn't.

How AI changes the calculus

I'd be ignoring the obvious if I didn't address this: AI tools have materially changed what's possible to prototype and test quickly. Two years ago, some of the strategic bets I'd have flagged as too risky to put on the roadmap — too much uncertainty, too long a feedback loop — are now things you can prototype in a week and get real signal on. That changes the prioritization math.

Specifically, it pushes the feasibility layer in an interesting direction. Things I would have classified as "too speculative for this cycle" can now be de-risked with a prototype before we commit. Which sounds like a pure win, and mostly is. But it also creates pressure: if you can prototype anything, the question of what to prioritize becomes harder, not easier. Every idea now has a credible path to signal. The constraint shifts from "what can we build" to "what should we even be learning about."

The teams I've watched handle this well are ones that got more intentional about their learning agenda, not less. They treat prototyping as a phase of the prioritization process — something you do before committing, not after. The ones that struggled treated AI-assisted speed as an invitation to build more things in parallel, which just spreads the team across more bets than they can actually follow through on.

There's also a subtler effect: when stakeholders see how fast prototypes can move, their patience for anything that takes a quarter shortens. I've had conversations where someone saw a two-week AI prototype and then asked why the real feature would take two months. The answer involves APIs, error handling, edge cases, accessibility, data privacy, load testing, and ten other things that don't exist in prototypes — but that's a harder sell once the prototype has set the expectation. PMs working in AI-native teams are going to need to get good at managing that gap.

What I actually do at the start of every cycle

For what it's worth, here's my actual process at the start of a planning cycle:

Set the strategic themes first, in writing, before opening any backlog tool. If I can't articulate what success looks like this quarter in two sentences, I'm not ready to prioritize.

Bring platform and debt items into the same stack as feature work. They compete for the same capacity. They belong in the same conversation.

Build the tradeoff log as I go, not as a retrospective exercise. Every time I park something, I write down why.

Share the narrative, not the spreadsheet. Leadership doesn't need to see RICE scores. They need to understand the logic and feel confident that you're working on the right things.

Revisit in six weeks, not twelve. Roadmaps that last a full quarter without being updated are roadmaps that have stopped being honest.

Prioritization isn't a scoring exercise. It's a series of judgment calls about what matters most, made visible and accountable to the people who need to trust you. The frameworks help — but only if you understand what they're capturing and what they're missing.

This article is part of a series on product management in an AI-transformed landscape.