TL;DR
Use AI as a structured second opinion on prioritization, not as the decision-maker. Feed it your backlog plus your real impact data, ask it to apply RICE scoring with explicit reasoning, then audit every reach and impact number against your own analytics. AI is reliable at applying the framework consistently and writing the rationale; it is unreliable at guessing impact and effort, which depend on data and a codebase it cannot see. The payoff is a scored, sortable list you can defend line-by-line in sprint planning.
The task
Your backlog has 30+ items, the next sprint needs clarity, and “what does the team feel like building” is not a strategy. You want a scored list with reasoning, a clear top 5 to ship, a clear bottom 5 to drop or defer, and stakeholders who object on specifics instead of vibes. A general-purpose model like Claude Opus 4.7, GPT-5.5, or Gemini 3.1 Pro is genuinely good at the bookkeeping part of this: applying one formula to 30 heterogeneous items without drifting, and writing the “why” behind each score. It is bad at the part you actually get paid for, which is judging real-world impact.
The RICE formula, in one line
RICE was developed by Sean McBride at Intercom to remove subjective judgment from roadmap decisions. The score is:
RICE = (Reach × Impact × Confidence) / Effort| Component | What it measures | Scale |
|---|---|---|
| Reach | How many users this affects in a fixed time window (e.g. one quarter) | A raw count from your analytics |
| Impact | How much it moves the needle per user | 3 = massive, 2 = high, 1 = medium, 0.5 = low, 0.25 = minimal |
| Confidence | How sure you are of the Reach/Impact/Effort estimates | 100% = high, 80% = medium, 50% = low |
| Effort | Total work, in person-months | A number from engineering, even rough |
The single most useful property of RICE is that one formula applies across product, growth, and platform work, so a checkout fix and an internal tooling task land on the same scale.
Where AI helps — and where it does not
AI is strong at applying the scoring rules consistently across all 30 items, surfacing dependencies between features, reframing Impact for platform teams, and drafting the rationale you will read aloud in review. As the team at IdeaPlan notes in their AI-RICE guidance, models genuinely improve the inputs to RICE — especially Reach and Confidence — when you give them real analytics to reason from.
AI is weak on two components, and it is weakest exactly where mistakes cost a sprint:
- Impact requires your usage data, win-rate, NPS, and competitive context. A model that has not seen those numbers will output a confident placeholder. Treat every impact score AI proposes as a hypothesis to confirm, not a fact.
- Effort depends on your codebase, technical debt, team composition, and architecture — none of which the model can see. Use AI to structure the effort breakdown so you ask engineering sharper questions, never to produce the person-month number itself.
What to feed the AI
- The backlog with one-line descriptions
- The quarterly goal (what success looks like in one sentence)
- Constraints: team size, time, code areas off-limits this quarter
- Real impact data per feature: usage requests, support volume, sales asks, churn drivers
- Effort estimates from engineering, even rough ranges
- Strategic bets: features that must ship regardless of score, each with the reason written down
Copy-ready prompt
Prioritise the following backlog.
Quarterly goal: [one line]
Constraints: [list]
Strategic must-ships (with reason): [list]
Backlog:
1. [feature] — [description] — usage data: [N requests / support tickets / sales asks] — eng estimate: [small / medium / large]
2. ...
Use RICE scoring:
- Reach: estimate quarterly users affected, with the calculation shown
- Impact: 0.25 / 0.5 / 1 / 2 / 3 — explain the choice
- Confidence: 50% / 80% / 100% — explain (low confidence = needs validation first)
- Effort: person-months, using my eng estimates as the anchor
Return:
1. Scored table: feature / R / I / C / E / RICE score / reasoning / dependencies
2. Top 5 to ship this sprint, with sequencing
3. Bottom 5 to drop or defer, with reasoning
4. "Watch list": 3 features that score low now but might shift if data changes
5. The single biggest risk in your scoring (where you would push back on yourself)
6. Which features need validation before the scoring is trustworthy
Do not invent reach numbers. If I did not give you data, mark [NEEDS DATA] and exclude from the top 5.For platform teams, add: “Reframe Impact as unblocking other teams rather than end-user impact.” For early-stage teams without analytics, drop to ICE (Impact × Confidence × Ease) — it skips Reach and is faster when you lack the data to estimate it honestly.
A worked example
Three backlog items, scored on one consistent scale:
| Feature | Reach (users/qtr) | Impact | Confidence | Effort (PM) | RICE | Verdict |
|---|---|---|---|---|---|---|
| SSO for enterprise plan | 1,200 | 2 | 80% | 3 | 640 | Top 5 — gates 3 sales deals |
| Inline CSV export | 8,000 | 0.5 | 100% | 1 | 4,000 | Top 5 — cheap, high reach |
| AI summary widget | 500 | 3 | 50% | 4 | 188 | Watch list — needs validation |
The CSV export wins not because it is exciting but because high reach over low effort beats a flashy, low-confidence bet. The AI widget’s 50% confidence is the tell: before it earns a sprint, you run a fake-door test. This is the kind of ranking that reads as obvious in hindsight and prevents the loudest-voice-wins meeting.
RICE vs the alternatives
| Framework | Optimises for | Best when |
|---|---|---|
| RICE | Breadth of user impact per unit effort | Mid-size team with customer data; the default |
| ICE | Speed of scoring | Early-stage, < 10 people, little data |
| WSJF | Value delivery speed with time-sensitivity | Large team, 50+ people, SAFe/agile-at-scale |
| Kano | Satisfaction vs. table-stakes classification | When you need to understand why users want something |
RICE is the most versatile and most widely used — roughly 38% of product teams pick it as their default, per ProductLift’s survey of 94 teams. The sophisticated move is to combine: Kano to classify the nature of a need, RICE to score the individual feature, story mapping to plan the release.
Where the AI output plugs into your stack
The model produces a scored list; your tooling makes it durable. Discovery-and-prioritization platforms like Productboard pull together how many customers requested a feature, their ARR, and how often it appears across support and sales, then push the winners into Jira or Linear for execution. If you do not run those tools, a shared sheet is fine — the non-negotiable is that the scoring is visible. Hidden scoring breeds resentment; visible scoring forces specific feedback.
How to check the output is usable
- Every reach number references your data, not an estimate the model invented
- Confidence scores below 100% state what validation would raise them
- The top 5 includes the strategic must-ships you named, even at low RICE
- Bottom 5 reasoning includes “comes back when X happens” where it applies
- Top 5 sequencing respects dependencies, not just raw score
Common mistakes
- Trusting AI impact scores without data. The single most common scoring failure.
- Skipping Confidence. A high RICE on an unvalidated feature wastes a whole sprint.
- No watch list. Features that should re-enter when the world changes get forgotten.
- One-shot scoring. Re-score the top 5 each sprint and the full backlog each quarter; RICE is not a one-time ritual.
- Letting AI suppress a strategic must-ship. You wrote down the reason — honour it.
FAQ
- Which AI model is best for this? Any frontier model handles the bookkeeping. Claude Opus 4.7 and GPT-5.5 both produce clean, well-reasoned RICE tables; Claude tends to push back harder on weak data when asked, which is what you want here.
- Can AI estimate effort for me? No. Effort depends on your codebase and team. Use AI to break the work into sub-tasks so you can ask engineering a sharper question, then take their number.
- What about Kano / MoSCoW / WSJF? Same prompt structure, different framework. RICE stays the most reusable across product, growth, and platform; switch to ICE only when you lack the data for Reach.
- Should the whole team see the scoring? Yes. Visible scoring turns vague objections into specific ones, which is the entire point.
- How often should I re-score? The top 5 every sprint; the full backlog once per quarter.
Related
- Feature prioritisation prompts — additional prompt phrasings
- Feature prioritisation AI — workflow variant
- Workload prioritisation prompts — non-feature work
- Technical debt prioritisation prompts — for tech-debt scoring
- PRD draft — the spec for whatever wins prioritisation
- Project plan draft — once prioritised, plan delivery
- Roadmap planning AI — multi-quarter view
Tags: #Workflow