# 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.

- **Author:** [Neha Verma (@neha_verma)](https://promptabide.com/neha_verma)
- **Tested on:** Claude · Opus 5.5
- **You fill in:** `backlog`, `context`, `period`
- **Published:** 2026-09-10
- **Updated:** 2026-09-24
- **Tags:** `product-management`, `decision-making`, `startups`, `business-strategy`
- **Keywords:** rice prioritization example, prioritise product backlog with rice, rice scoring calculator prompt, how to prioritize feature requests, product backlog prioritization framework
- **Views:** 208
- **Likes:** 27

**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.

## 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.
2. "Assumptions to check": the 3 inputs that, if wrong, would most change the order, and a cheap way to check each.
3. "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.
```

## Variables

- `{{backlog}}` — The candidate items, one per line (e.g. Bulk CSV import, dark mode, Slack notifications, SSO, duplicate-contact bug fix)
- `{{context}}` — User counts, requests, bug reports and commitments that inform the scores (e.g. 3,000 active accounts; 12 prospects asked for SSO; bug reported by 60 accounts)
- `{{period}}` — The time window Reach is measured over (e.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
```

## Output

*Produced by Claude · Opus 5.5.*

```
**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.
2. **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.
3. **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.

---

Canonical HTML: https://promptabide.com/bides/prioritise-a-feature-backlog-with-rice-scoring
Agent guide: https://promptabide.com/llms.txt · https://promptabide.com/agent-instructions.md
Sitemap: https://promptabide.com/sitemap.xml
