How to Prioritise Product Features with RICE and Cost of Delay

How do you prioritise product features, step by step?

Prioritisation is a comparison, and you cannot compare items that serve different goals. So the method starts before any scoring. Here is the sequence that works for a small or growing software team.

• 1. Agree one outcome for the quarter: a change in customer behaviour with a baseline, a target and a date.
• 2. Turn every request into a problem statement with evidence, so you are comparing problems, not pet solutions.
• 3. Score every item with RICE, using fixed scales and the same unit of reach for every item.
• 4. For big bets and deadline-driven requests, estimate cost of delay per week and divide by duration in weeks (CD3).
• 5. Mark legal, security and accessibility work as non-negotiable: plan it whatever it scores.
• 6. Compare the two ranks. Where they differ by more than a few places, find out why before you decide.
• 7. Add effort down the list until you reach your capacity for the quarter. Everything below the line moves to Next or Later.
• 8. Publish the scores and the decision, answer every requester, and log the reasons with a date to review.

What is the RICE score and how do you calculate it?

RICE was described by Sean McBride on Intercom's blog as a way to compare very different ideas on one scale. It has four factors. Reach is how many people or events an item affects in a period; choose one unit (for example customers, or new users per quarter) and use it for every item. Impact is the effect on each one, on a fixed scale: 3 for massive, 2 high, 1 medium, 0.5 low and 0.25 minimal. Confidence is how sure you are of the other estimates, as 100%, 80% or 50%. Effort is the total person-months of product, design and engineering time.

The score is reach x impact x confidence / effort: total impact per unit of time worked. Its strengths are speed and fairness: anyone can score an item, and the CEO's idea and a support agent's request go through the same formula. Its weakness is time. A request that will lose a signed deal this month and one that might matter next year can score the same.

What is cost of delay, and what is CD3?

Cost of delay asks what each week of waiting costs in value lost. The idea comes from Don Reinertsen's work on product development flow; Black Swan Farming sets out CD3, cost of delay divided by duration, as a way to order work. Estimate the value per week (revenue kept, revenue won, costs avoided, risk reduced), divide by how many weeks the work takes, and do the highest score first.

The hardest part is the estimate, so build it from parts you can defend. For a feature that stops document uploads failing, you might estimate three accounts kept a year at $15,000 each, two new deals helped at $18,000 each and 1,800 support tickets avoided at $8 each: $95,400 a year, or about $1,835 a week. Over a 10-week build, CD3 is about 180. Write down where each number came from, and label every one as an estimate.

Worked example: twelve features, two methods

Here is a fictional composite: a 40-person HR-tech company in Austin, Texas, with 240 customer accounts and an outcome of raising the share of new hires ready on their first day from 46% to 60%. Reach is new hires affected per quarter. The table shows each item's RICE inputs and score, its CD3, and its rank on each method.

SMS reminders top both lists. The surprise is custom branding: 11th on RICE, because it affects few people a little, but 1st on CD3, because a signed deal worth about $78,000 a year waits on it and the work takes three weeks. Neither method is wrong. The gap tells you a deadline is in play. The team's answer was the smallest version that met the deadline (logo and colour only, one person-month) in the Next column, with the decision logged.

What should never be decided by a score?

Some work is not optional, and scoring it invites the wrong argument. Mark it non-negotiable and plan it. Three categories come up in most software teams, and the rules behind them differ by market, so check with your adviser.

Accessibility is one. In the EU, the European Accessibility Act applies from 28 June 2025 to listed products and services, including e-commerce; elsewhere, disability and equality laws apply, and WCAG 2.2 (a W3C Recommendation since December 2024) is the usual benchmark. Interface design is another: the EU's Digital Services Act, in Article 25, bars online platforms from designing interfaces that deceive or manipulate users, and the US Federal Trade Commission has published a staff report on dark patterns. AI transparency is a third: under Article 50 of the EU AI Act, people must be told when they are interacting with an AI system unless it is obvious, and the European Commission says those rules apply from August 2026. This guide is not affiliated with or endorsed by W3C, the FTC or the European Commission.

• Accessibility fixes on changed screens
• Security and privacy work required by law or contract
• Removing confusing consent, cancellation or pricing designs
• Disclosures for AI features that talk to people

How do you connect prioritisation to discovery?

Scores are only as good as the evidence behind reach, impact and confidence. The best source is a steady flow of customer conversations, mapped onto an opportunity solution tree: Teresa Torres's structure of one outcome at the top, customer opportunities below it, solutions below those and assumption tests at the bottom. When an item's opportunity comes up in many interviews, reach and confidence rise; when nobody has mentioned it, confidence should be 50% and the item is a discovery job.

Test the riskiest belief behind each big item before building it. Marty Cagan of SVPG groups product risk into value, usability, feasibility and business viability; adding ethics and trust covers features that could exclude or mislead people. A cheap test (a data pull, five interviews, a prototype) often moves an item up or down the list faster than any debate. If you run research calls, follow a clear consent process: the GOV.UK Service Manual's guidance on informed consent for user research is a practical model.

How do you say no to feature requests?

Most prioritisation is saying no, or not yet, to people you will work with for years. Answer every request quickly, ideally within five working days. Give the reason as evidence and a trade-off: 'it scored 300; the top item affects 9,000 users a quarter' can be discussed, 'I don't think it's a priority' cannot. Offer a next step: a workaround, a date to revisit, or the one fact that would change the answer, such as a deal value and deadline.

Show what moves out whenever something moves in. A roadmap in three horizons (now, next and later, a format Janna Bastow describes inventing in 2012) makes that visible, because Now has a fixed capacity and Later carries no dates.

How do you check that the plan fits your capacity?

A ranked list is not a plan until it meets the time you actually have. Start with capacity in the same unit as effort: person-months of engineering and design available next quarter, after support rotations, bug fixing, holidays and the interrupt buffer you agreed with customer success. Be honest about it; a capacity figure that assumes nobody is ever ill is a wish.

Then add effort down the ranked list, non-negotiables first, until the running total reaches capacity. Everything above the line is Now. Everything below it moves to Next or Later, whatever anyone hoped. In the worked example, the team had about 26 person-months for the quarter, and its Now and Next items came to 14.5, which left room for support and for the tests that would decide two of the bets. If your list comes to 30 against 26, four person-months of work move out, and you say which.

Recheck capacity whenever a big item is added. The rule that keeps prioritisation honest is simple: nothing goes into Now without something coming out.

When should an experiment settle a priority question?

Sometimes the argument is not about value but about whether an idea works at all. If you have enough traffic, a controlled A/B test can settle it. A common rule of thumb for about 80% power at 5% significance is a sample per variant of 16 x p x (1 - p) / d squared, where p is the baseline rate and d the smallest change worth detecting. With a 46% baseline and a 4-point change, that is about 2,485 users per variant; at 770 eligible users a week, two variants need about seven weeks.

If the test would take months, do not run it as an A/B test. Use a staged rollout with a careful before-and-after reading, plus interviews, and record that the evidence is weaker. Either way, write the hypothesis, the primary metric, a guardrail metric and a fixed end date before you start, and do not stop early because the result looks good.

Common mistakes

• Scoring before agreeing the outcome, so every item looks important.
• Using different units of reach for different items.
• Giving everything 100% confidence; use 50% when the evidence is thin.
• Scoring in private and announcing the result.
• Averaging RICE and CD3 ranks instead of asking why they differ.
• Scoring non-negotiable work and then deprioritising it.
• Adding to Now without removing anything, then blaming the team for slipping.
• Never revisiting a decision: give each one a review date.