RICE Breaks When Effort Stops Being the Constraint

A conference clip, 53 seconds, one speaker on a purple stage with a "ROADMAPS ARE OFFICIALLY DEAD" caption pinned over her head. The argument underneath the hook is narrower and better than the hook: RICE scoring was a division problem, and when the denominator collapses toward zero, the formula stops sorting anything. Her phrasing is that "many of those letters mean nothing anymore, especially effort." That specific claim is worth taking apart, because it is the load-bearing one and the rest of the talk rests on it.

The formula was always a ratio, and the ratio is what broke

Sean McBride built RICE on Intercom's growth team and published it on the Intercom blog. The formula is (Reach × Impact × Confidence) ÷ Effort, where effort is defined as the total time a project will require from product, design, and engineering. McBride's own framing for the output is "total impact per time worked."

That structure is the whole point. Reach, impact, and confidence are estimates of value. Effort is the price. RICE is a price-per-unit-of-value sort, and it only produces a useful ordering when prices vary meaningfully across the list. When a two-week feature and a two-day feature both take an afternoon of agent time plus a review cycle, the denominator flattens into roughly the same number for every row. The ranking degenerates into R × I × C, which is three guesses multiplied together with no cost discipline attached.

The video says "many of those letters mean nothing." That overstates it. Reach and impact are still estimates about users and they did not get any easier to make. Confidence was always a fudge factor. Effort is the letter that actually changed, and it was the one doing the sorting.

Build cost fell. Ownership cost did not.

The clip treats the collapse of effort as settled. It is worth being precise about which effort collapsed. Generating a first working version got cheaper. Code review, security surface, support load, migration debt, on-call burden, and the cost of removing the thing later did not move.

RICE never priced any of that. It priced person-months to ship. So a team that keeps using RICE with a shrunken effort number is not just running a broken sort, it is running a sort that was already blind to the costs that now dominate. The shipping cost was the only cost in the denominator, and it is the one that fell.

There is also reason to hold the "effort went to zero" premise loosely. METR ran a randomized controlled trial in early 2025 with 16 experienced open-source developers across 246 tasks on repositories they averaged five years of experience with. Allowing AI tools increased completion time by 19 percent. The same developers estimated afterward that AI had made them 20 percent faster. METR has since labeled that result historical and redesigned the experiment, and the finding was about experienced developers on mature codebases rather than greenfield work. It does not refute the video. It does say that perceived speed and measured speed came apart badly once, which is a reason to measure your own cycle time before rebuilding your planning system around an assumption.

The three traps are referenced and never named

At the midpoint she says an AI factory plus an old roadmap "will get you to those three traps at machine speed." The clip is cut from a longer talk and the three traps are defined somewhere outside the 53 seconds. Anyone watching this in isolation gets the conclusion without the setup.

What the argument does describe clearly is a feature factory running faster. John Cutler published "12 Signs You're Working in a Feature Factory" in November 2016, built on a developer friend's complaint about "just sitting in the factory, cranking out features, and sending them down the line." The signs he listed are mostly about measurement: no impact tracking, success theater around shipping, teams shuffled between projects. None of those failures are caused by slow delivery. Speeding up delivery does not fix any of them, and it shortens the gap between a bad decision and its consequences. That is the actual mechanism in her closing line about bad ideas becoming problems quicker.

Sort by reversibility

If cost per item stops discriminating, the useful axis is what happens when the item is wrong.

Jeff Bezos laid this out in Amazon's 2015 shareholder letter. Type 1 decisions are one-way doors, consequential and close to irreversible, and they get the slow deliberate process. Type 2 decisions are two-way doors, changeable, and should be made fast by individuals or small groups with good judgment. His warning was that large organizations drift toward applying Type 1 process to Type 2 decisions, producing slowness and unthoughtful risk aversion.

Cheap building inverts that failure mode. When every item costs an afternoon, the drift runs the other way, and one-way doors get walked through with two-way-door process. A pricing model change, a data schema you will have to migrate, a public API contract, a permissions default: all of these are still expensive to reverse no matter how fast the first version compiles. That is the sort she is gesturing at when she says the factory "can't distinguish a truly consequential bet from an idea."

Basecamp's Shape Up offers the other half, a budget that does not depend on estimating effort at all. Chapter 3 sets an appetite, a fixed time box with variable scope, described as a time budget rather than an estimate. You decide how much a problem is worth before you design the solution, and the box forces the cut between core and peripheral. Appetite survives cheap building because it never asked how long something would take.

Where "roadmaps are dead" overshoots

The caption is a hook and the talk is better than it. A roadmap does more than sequence engineering work. It is a commitment artifact for enterprise sales cycles, a dependency signal for support and solutions teams, an input to compliance and procurement timelines, and in some contracts a legal obligation. Deleting the artifact does not delete any of those obligations, it just moves them into ad hoc Slack threads.

The honest version of the argument is that the roadmap's prioritization function is broken and its communication function is not. A team that keeps a roadmap as a statement of outcomes and commitments, while replacing the RICE-sorted backlog underneath it with reversibility triage and fixed appetites, gets the thing she is asking for without losing the thing she is not discussing.

Key Takeaways

• RICE is a ratio. It sorts by value per unit of effort, so it stops discriminating when effort is roughly constant across every candidate.
• Effort is the letter that changed. Reach and impact are still estimates about users and are no easier to make than they were.
• The cost that fell is the cost of the first working version. Review, support, security surface, and removal cost did not fall, and RICE never counted them.
• The clip references "three traps" without defining them. It is cut from a longer talk.
• Reversibility is a sortable axis that survives cheap building. Bezos's one-way and two-way doors is the usable version.
• Shape Up's appetite is a budget rather than an estimate, so it does not degrade when building gets faster.
• The roadmap's prioritization function and its commitment function are separable. Only the first one is broken.

Resources

• RICE: Simple prioritization for product managers by Sean McBride on the Intercom blog. The original definition, including effort measured as total time from product, design, and engineering.
• 12 Signs You're Working in a Feature Factory by John Cutler, November 2016. The signs are about missing impact measurement, which faster shipping does not address.
• 12 Signs You're Working in a Feature Factory, 3 Years Later by John Cutler. Twelve updated thoughts written three years after the original, covering work-in-progress limits and why teams with good intentions still end up in the factory.
• Amazon 2015 Letter to Shareholders. Contains the Type 1 and Type 2 decision framing and the one-way door metaphor.
• Shape Up, Chapter 3: Set Boundaries by Ryan Singer at Basecamp. Appetite, fixed time and variable scope.
• Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity from METR, July 2025. The randomized trial showing a 19 percent slowdown against a 20 percent perceived speedup.
• We are Changing our Developer Productivity Experiment Design from METR, February 2026. METR's own caveats on the above result and what they changed.