पाठशाला Pathshala · उत्पाद Utpād, The product · Lesson 08 · Build
Prioritisation: RICE, and the one question that beats it
A scoring frame ranks a backlog fairly and hides what is urgent. Score with RICE, then ask which item, shipped this month, lets a named customer pay or keep paying.
Pathshala, The Founder Library · 11 October 2026 · 7 min read
Every backlog is longer than the team. The question is never whether to choose but how, and the two usual methods are both bad: the founder’s instinct, which follows the last customer call, and the loudest person in the room, which follows the loudest person in the room. A scoring frame fixes both. It also creates a third failure, and this lesson is about catching it.
The frame here is RICE, because it is simple, published and widely used. The lesson explains how to score with it properly, the three ways it misleads a young company, the one question that should override it, and how to run the two together in a thirty-minute weekly review.
RICE, as Intercom wrote it
Sean McBride set out the method in a 2018 Intercom post. Each item gets four numbers. Reach: how many people or events it affects in a fixed period; Intercom used customers a quarter, and McBride asks for real product data over guesses. Impact: the effect on each person reached, on a fixed scale of 3 for massive, 2 for high, 1 for medium, 0.5 for low and 0.25 for minimal. Confidence: how well the other estimates are supported, at 100 per cent for high, 80 for medium and 50 for low; below 50 McBride calls a total moonshot. Effort: total person-months across product, design and engineering, in whole numbers or 0.5 for anything well under a month.
The score is reach times impact times confidence, divided by effort: total impact per unit of time worked. An item reaching 120 customers a quarter with medium impact, 80 per cent confidence and one person-month of effort scores 96. One reaching all 180 customers with high impact, 50 per cent confidence and four person-months scores 45. The first goes ahead of the second, and the arithmetic says why in a way nobody has to take on authority.
McBride adds a caveat that most teams skip: RICE scores should not be used as a hard and fast rule. Some low-scoring items go first, for instance because another item depends on them, and the value of the score is that it makes such out-of-order choices visible rather than accidental.
How the scoring is done matters as much as the formula. Score in silence first: each person writes their four numbers for every item before anyone speaks, so the founder’s view does not anchor the room. Then reveal, and discuss only the items where estimates differ by more than double, because that gap is where someone knows something the others do not. Record the evidence behind each confidence figure in a word or two, such as usage data, three interviews or a hunch, so the next review can see whether it has improved. Forty items take an hour this way the first time and twenty minutes a week after that.
Where the score misleads
Confidence is usually a mood. A team scores 80 per cent on an item because it feels sure, and 50 on one it finds dull. Itamar Gilad’s Confidence Meter is the corrective: there is only one way to calculate confidence, which is to look for supporting evidence. On his scale self-conviction and colleagues’ opinions are worth close to nothing, interviews and surveys a little, and real usage of a working version a great deal. The rule that follows is simple. Give 100 per cent only to items with usage data, 80 to items backed by customer evidence, and 50 to everything else, including the founder’s favourite idea.
Reach favours breadth. An item that touches every customer a little beats one that matters enormously to one customer, which is correct for a mature product and dangerous for a young one whose next ₹20 lakh of revenue may sit with three accounts. Impact is compressed. Five values from 0.25 to 3 cannot separate a pleasant improvement from the thing a customer will leave over. Effort is a guess made before the work is understood, and a large item has more room to be wrong than a small one, so an optimistic estimate quietly flatters ambitious work.
None of these is a reason to drop the frame. They are reasons not to let it decide alone, and one of them, the blindness to concentrated revenue, is serious enough to need its own question.
The one question that beats it
Ask of every item: if this shipped this month, would a named customer start paying, keep paying or pay more? Not customers in general and not next year. A name, a rupee figure and a month. A chain that will sign a ₹1.8 lakh-a-month contract once branch logins exist. Three distributors who have said in writing that they will cancel if the accounting sync keeps breaking. A pilot that converts to paid when bulk import works.
The reason this question outranks a score is survival arithmetic. Paul Graham’s Default Alive or Default Dead? asks whether, on current expenses and recent revenue growth, a company reaches profitability on the money it has left; his observation is that half the founders he talks to do not know. For a company that is not yet default alive, revenue this month changes the answer and a better product next quarter may not arrive in time. The question is the product team’s share of that discipline.
The formal version is cost of delay, which Don Reinertsen popularised and which Black Swan Farming describes as the way time affects the outcomes you want, combining urgency and value. Divide it by duration and you get CD3, cost of delay divided by duration: rupees a month lost while you wait, per month of work to stop the loss. For most early-stage backlogs only a handful of items have a measurable cost of delay at all, and those are exactly the ones RICE tends to rank low.
A worked backlog
An Ahmedabad company sells inventory software to 180 pharmaceutical distributors at ₹4,000 a month. The backlog has six items worth arguing about: an AI demand forecast the founders are excited by; a fix to the sync with Tally, which breaks weekly for 120 customers and has three threatening to leave, about ₹12,000 a month at risk; bulk import from Excel, which blocks pilots worth about ₹20,000 a month; batch-expiry alerts; logins for each branch of a forty-outlet chain that has said it will sign at ₹1.8 lakh a month once they exist; and dark mode.
Scored by RICE, bulk import comes first, the Tally fix second and dark mode third. The chain’s branch logins come last, with a score of 2, because they reach one customer. Asked the revenue question, the order changes: branch logins first at ₹1.2 lakh a month per person-month, then bulk import, then the Tally fix. The two rankings agree that the AI forecast waits. They disagree about the most valuable item in the backlog by five places.
Move the confidence on the AI forecast from 50 to 100 per cent and its score doubles, from 45 to 90, taking it from fifth to level with dark mode. Nothing about the evidence has changed, only the team’s mood. That is the case for Gilad’s rule, and the case for a second question that does not depend on a guessed number at all.
A score ranks what is valuable on average. The question ranks what is urgent for this company, this month. Ask the question first.
Running both, in the right order
The order of operations is fixed. First, list the items with a named customer and a rupee figure attached, and rank them by rupees a month per person-month. Second, cap how much of the team’s time they may take, because a company that only ever builds what the next customer asks for becomes a services firm; a sensible cap is half of a cycle, and anything above that should be a deliberate decision rather than a drift. Third, rank everything else by RICE with evidence-based confidence. Fourth, check dependencies by hand, as McBride advises, and move an item up when a high scorer needs it.
Two warnings. A customer’s promise to pay is not revenue until it is in writing; a revenue-now item needs a signed order, a written intent or a cancellation notice, not a pleasant call. And a single customer whose requests keep jumping the queue is telling you something about your segment: read [the lesson on ideal customer profiles](/library/ideal-customer-profile-on-one-page) before building a fourth feature for them.
The weekly backlog review, in thirty minutes
Every Monday after the metrics review: list the items with a named customer and a rupee figure, check each one’s evidence is in writing, and rank them by rupees per person-month. Re-score any item whose evidence changed during the week, using usage data, customer evidence or nothing as the confidence ladder. Confirm the top three for the week and the share of time they take. Write the order in one place the whole team can see. Once a month, compare what was predicted against what was paid, and lower the confidence of whoever keeps forecasting revenue that does not arrive, including the founder.
The scales are Intercom’s and the confidence ladder follows Gilad; the worked company and its rupee figures are illustrative.