Reach times impact times confidence, divided by effort: RICE is the prioritization framework most product teams already use to score which features ship next, AI features included. It is fast, and it is honest about the four inputs a roadmap review actually argues over. It has no term for what a feature costs to run, because it was built for products where the marginal cost of one more user is close to zero.
An AI feature breaks that assumption. Every user who adopts a chat assistant or a copilot adds tokens, retries, and cache misses, and RICE’s effort term is a one-time build estimate, not a running cost. A feature can clear the bar on reach, impact, confidence, and effort and still lose money on every user it reaches, because nothing in the formula was built to catch that.
The direct version: cost-adjusted RICE adds a fifth term, cost-adjusted margin, to the standard reach times impact times confidence, divided by effort formula, so an AI feature prioritization framework built on the original four terms doesn’t wave through a feature that scores well everywhere except the one place that determines whether it should ship.
The Five Terms of Cost-Adjusted RICE
Standard RICE scores a feature on four named inputs, each already familiar to any product team that runs a roadmap review:
- Reach. How many users the feature will touch in a given period.
- Impact. How much the feature moves the metric it is meant to move, per user reached.
- Confidence. How sure the team is about the reach and impact estimates, expressed as a percentage.
- Effort. How many person-months it takes to build, the formula’s only cost term.
Cost-adjusted RICE adds a fifth:
Cost-adjusted margin. What the feature costs to run, per user, against what it earns or saves per user, expressed as a ratio and applied as a multiplier on the standard RICE score. A feature with a strong RICE score and a cost-adjusted margin near zero gets discounted before it reaches the top of the roadmap. A feature with a modest RICE score and a wide margin gets a boost. Effort prices what it costs to build a feature once. Cost-adjusted margin prices what it costs to run every time someone uses it, which is the number that compounds as reach grows instead of the number that gets paid off once at launch.
What Feeds the Cost-Adjusted Margin Term
Cost-adjusted margin is not a single input. It is built from the same drivers that price an AI feature’s unit economics anywhere else on this site:
- Cost per active user at current usage. The number the margin term starts from: what the feature costs, per user, at today’s request volume.
- Cost per active user at 10x usage. The same number re-run at the usage level the reach estimate implies once the feature actually succeeds, which is where a margin problem usually first becomes visible.
- Retry and re-prompt rate. Failed or low-quality responses that get re-run cost twice, and a high retry rate quietly doubles the margin term’s denominator, the same driver that shows up in what one AI request actually costs.
- Cache hit rate. How much of the feature’s token volume gets served from a cached prefix instead of priced at the full input rate. A stable-prefix feature and a fresh-context-per-query feature can land at opposite ends of this number.
- Model tier and fallback routing. Whether the feature runs on one model consistently or falls back to a costlier tier under load, since a margin estimate built on the cheaper tier alone understates the real number.
- Tool-call and context-growth overhead. For an agentic feature, the tokens spent on tool calls and the context that grows with every step, priced out in detail in what an AI agent costs to run, and missed entirely by a single-request cost estimate.
- Break-even usage. The reach level at which the feature’s cost-adjusted margin crosses zero, the number that tells a team whether growth helps the margin term or hurts it.
These seven feed one score. A team does not need all seven modeled precisely to run cost-adjusted RICE; a rough estimate of the first two from the LLM cost calculator is usually enough to separate a feature worth scoring from one that needs an unhurried second look.
RICE vs. Cost-Adjusted RICE, on the Same Two Features
Two features can clear the same RICE bar and still deserve opposite roadmap decisions. The comparison below is illustrative, built to the ranges seen once feature-level cost was correlated to product usage across production AI features at a Fortune-500 financial data company, rather than to one specific launch:
| Feature A: search filter | Feature B: AI copilot | |
|---|---|---|
| Reach, impact, confidence | 40,000 users, impact 2, confidence 80% | 40,000 users, impact 2, confidence 80% |
| Effort | 3 engineer-months | 3 engineer-months |
| Standard RICE score | 21.3 | 21.3 |
| Cost-adjusted margin | Wide (cost per user under a cent) | Thin (cost per user in the low dollars once retries and context growth are counted) |
| Cost-adjusted RICE score | 21.3, unchanged | 4 to 6, discounted |
Same reach, same impact, same confidence, same effort, same standard RICE score. Nothing in the original formula tells these two features apart. The fifth term does, because a search filter’s marginal cost per user is close to zero and an AI copilot’s is not, and only one of those two facts changes as the feature succeeds and reach grows.
When Cost-Adjusted RICE Beats Standard RICE
Not every feature needs the fifth term. The decision is simple: if a model call sits anywhere in the feature’s request path, run cost-adjusted RICE. If it does not, standard RICE is still the right tool, and adding a margin term to a feature with no meaningful marginal cost just adds a column nobody needs to fill in.
Inside that first group, cost-adjusted margin matters more the earlier a feature is in its life. Pre-build, it is the term that catches a feature before engineering commits to an architecture the unit economics cannot support. Post-launch, it does the same job the margin signals PMs miss catch after the fact, just earlier, and inside the same prioritization exercise the team already runs instead of as a separate review.
The Mistake Most Teams Make
The most common mistake is not skipping the cost-adjusted margin term entirely. It is folding cost into effort and calling the job done. Effort is a build estimate: engineer-months, once, at launch. A feature that takes three engineer-months to build and costs a fraction of a cent per user to run, and a feature that also takes three engineer-months to build but costs several dollars per user to run, get the identical effort score and the identical standard RICE score, because effort was never built to hold a number that changes with every additional user.
Score cost-adjusted margin as its own term, not as a line inside effort, or the formula keeps treating a one-time cost and a per-user running cost as the same kind of number.
The Rule
Run cost-adjusted RICE on any feature with a model call in its request path before it enters a roadmap review, not after it ships. A feature that clears standard RICE, gets built, and only then gets its unit economics checked has already spent the engineering time the fifth term exists to protect. Scoring it earlier costs one more input in a spreadsheet that already has four; scoring it after launch costs a quarter or two of a feature running at a margin nobody checked for.
FAQs
What is cost-adjusted RICE? Cost-adjusted RICE is the standard reach, impact, confidence, and effort prioritization formula with a fifth term, cost-adjusted margin, added to catch AI features that score well on the original four inputs but cost more per user to run than they return.
How is cost-adjusted margin different from the effort score in RICE? Effort prices what it takes to build a feature once, in engineer-months. Cost-adjusted margin prices what it costs to run the feature per user, which grows with reach instead of getting paid off at launch, so the two terms measure different kinds of cost and neither substitutes for the other.
Do all AI features need the fifth term? Any feature with a model call somewhere in its request path benefits from cost-adjusted RICE, since that is where a per-user running cost exists to score. A feature with no meaningful marginal cost per user is still better served by standard RICE.
What inputs does cost-adjusted margin need? A rough estimate of cost per active user at current usage and at the usage level the reach estimate implies is usually enough to score a feature. The full picture also accounts for retry rate, cache hit rate, model tier, and, for agentic features, tool-call and context-growth overhead.
What to Do Next
Run a feature’s projected numbers through the LLM cost calculator to get a rough cost-adjusted margin before it enters a roadmap review, and check the resulting score against the pricing model the feature will ship under, since a thin margin under a seat-based price is a different problem than the same margin under usage-based pricing. If a feature that already shipped is showing the same signal after the fact, the margin signals PMs miss walks through what to do once it is live. A prioritization call that keeps landing on the same discounted feature is usually a business-case problem, not a scoring problem, which is the conversation the AI business case or a fractional product leader for AI economics exists to have, backed by the same FinOps for AI discipline behind every number on this site.
I put a number on what an AI product costs per request, per active user, and per subscriber, early enough to change the model, the architecture, or the price. If you’re shipping something with a model behind it and nobody can tell you what it costs, email me.
Have a number nobody can explain?
Send a note and I will get back to you.