Neha Verma

Prioritise a Feature Backlog With RICE and Stated Assumptions

Score a backlog with RICE, show the arithmetic, expose the assumptions that could reorder it, and flag items RICE shouldn't rank at all.

At a glance

Best for: Product managers and founders facing a noisy backlog who want a defensible order and a clear list of what to verify before committing.
Tested on: Claude · Opus 5.5
You fill in: backlogcontextperiod
You get: Unit: accounts for every item. You gave users for weekly activity but accounts everywhere else. Assumptions I had to make (labelled A1-A3): A1:… (full result below)

Prompt

Score this backlog with RICE and make every assumption visible, so my team argues about the inputs rather than the ranking.

Backlog (one item per line):
{{backlog}}

Context: {{context}}
Time period for Reach: {{period}}

For each item:

• Reach: accounts or users affected in the period, with the source or assumption behind it. Use the same unit for every item.

• Impact: 3 / 2 / 1 / 0.5 / 0.25, with one sentence justifying the level.

• Confidence: 100% / 80% / 50%, lowered whenever Reach or Impact is a guess.

• Effort: person-weeks.

• RICE = Reach x Impact x Confidence / Effort.

Output:

1. A table sorted by RICE score, with all inputs and the score. Show the arithmetic so I can check it.

1. "Assumptions to check": the 3 inputs that, if wrong, would most change the order, and a cheap way to check each.

1. "What RICE misses": any item that is a dependency, a customer commitment or a risk fix and shouldn't be ranked on RICE at all.

Don't invent data I didn't give you. Use a labelled assumption instead.

Fill in

{{backlog}}: The candidate items, one per linee.g. Bulk CSV import, dark mode, Slack notifications, SSO, duplicate-contact bug fix
{{context}}: User counts, requests, bug reports and commitments that inform the scorese.g. 3,000 active accounts; 12 prospects asked for SSO; bug reported by 60 accounts
{{period}}: The time window Reach is measured overe.g. one quarter

Example input

backlog:
- Bulk CSV import of contacts
- Dark mode
- Slack notifications when a deal changes stage
- SSO (SAML) for the enterprise plan
- Fix: duplicate contacts created when two users edit at once
context: B2B CRM for small agencies. 3,000 active accounts, about 9,000 weekly active users. 1 in 5 new accounts contacts support about importing. 12 enterprise prospects in the pipeline have asked for SSO; 2 existing enterprise customers were promised it by Q1. The duplicate-contact bug was reported by about 60 accounts last quarter. Slack notifications were requested in 140 feedback posts.
period: one quarter

2080

Generated Outputs (1)

2 hours ago

Claude

Opus 5.5

2 hours ago

Generated Output

Unit: accounts for every item. You gave users for weekly activity but accounts everywhere else.

Assumptions I had to make (labelled A1-A3):

• A1: about 600 new accounts a quarter. You didn't give sign-ups.

• A2: 30% of accounts use Slack, so 900 accounts.

• A3: 20% of accounts would switch on dark mode, so 600 accounts.

| # | Item | Reach | Impact | Conf. | Effort (pw) | RICE |
|---|---|---|---|---|---|---|
| 1 | Slack notifications | 900 (A2) | 1 | 50% | 2 | 900 x 1 x 0.5 / 2 = 225 |
| 2 | Bulk CSV import | 600 (A1) | 2 | 50% | 3 | 600 x 2 x 0.5 / 3 = 200 |
| 3 | Duplicate-contact fix | 60 (reported) | 2 | 80% | 1.5 | 60 x 2 x 0.8 / 1.5 = 64 |
| 4 | Dark mode | 600 (A3) | 0.25 | 50% | 2 | 600 x 0.25 x 0.5 / 2 = 37.5 |
| 5 | SSO (SAML) | 14 (12 prospects + 2 customers) | 3 | 80% | 4 | 14 x 3 x 0.8 / 4 = 8.4 |

Impact: Slack 1 (a convenience), import 2 (an onboarding blocker for 1 in 5 new accounts), duplicate fix 2 (bad data erodes trust in the whole CRM), dark mode 0.25 (preference only), SSO 3 (a hard requirement for enterprise buyers). Effort figures are my estimates; replace them with your engineers'.

Assumptions to check

1. Duplicate-bug reach. 60 is only the accounts that reported it. Query for contacts with the same email created within 60 seconds of each other. If the real figure is 300, the score becomes 320 and the fix moves to first place.

1. Slack reach (A2). Run a one-question in-app poll ("Does your team use Slack?") for a week. At 15%, the score halves to about 112 and falls below import.

1. New accounts per quarter (A1). It's a two-minute query. Import's score scales directly with it.

What RICE misses

• SSO is a promise to 2 paying customers with a Q1 deadline. RICE counts each enterprise account as one, the same as a small agency, so it will always rank last. Schedule it by deadline and deal value, not by score.

• The duplicate fix is a data-integrity bug, and those get worse the longer data keeps being corrupted. I'd treat it as a fix that goes ahead regardless of rank, especially at 1.5 person-weeks.

• Import partly affects activation, not just a feature count. If new-account activation is your quarter's goal, weight it on that instead.

Why it works

"Use the same unit for every item" fixes the most common RICE error: mixing users and accounts, which silently inflates some scores. Tying Confidence to whether Reach or Impact is a guess makes uncertainty cost something. Show the arithmetic means anyone can recompute a row after correcting one input. The two closing sections do the real work: "Assumptions to check" points at which numbers to verify first, and "What RICE misses" stops a contractual commitment or a data-integrity bug being buried by a formula that treats every account the same.

When not to use it

RICE is weak for very early products where reach numbers are all guesses; there, use a simple risk-versus-learning discussion. It also can't weigh strategic bets, such as moving upmarket, against incremental features. If your team already trusts a different framework, don't switch just to use this prompt.

Comments (0)

No comments yet. Be the first to share your thoughts!