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 do, a clear bottom 5 to drop or defer, and stakeholders who can object on specifics rather than vibes. AI is useful as a structured second opinion, not as the decision-maker.
When AI helps — and when it does not
AI is excellent at applying scoring frameworks consistently (RICE, ICE, Kano), surfacing dependencies between features, and writing the reasoning behind each score. It is poor at impact estimation. That requires your usage data, win-rate, NPS, and competitive context. AI’s confidence numbers are placeholders until you replace them with your real signals.
What to feed the AI
- The backlog with one-line descriptions
- Quarterly goal (what success looks like)
- 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
- Strategic bets (which features must ship regardless of score, with the reason written down)
Copy-ready prompt
Prioritise the following backlog.
Quarterly goal: <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 a calculation
- Impact: 0.25 / 0.5 / 1 / 2 / 3 — explain
- Confidence: 50% / 80% / 100% — explain (low confidence = needs validation first)
- Effort: person-months, using my eng estimates as anchor
Return:
1. Scored table: feature / R / I / C / E / RICE score / reasoning / dependencies
2. Top 5 to do this sprint, with sequencing
3. Bottom 5 to drop or defer, with reasoning
4. "Watch list" — 3 features that score low 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 scoring is trustworthy
Do not invent reach numbers. If I did not give you data, mark [NEEDS DATA] and exclude from top 5.For platform teams: “Same scoring but reframe Impact as ‘unblocking other teams’ rather than end-user impact.”
Recommended output structure
A sortable table with all RICE components, top 5 in a sequenced list, bottom 5 with explicit reasoning, and a “watch list” callout. The “biggest risk in your scoring” line is what protects you in stakeholder review.
How to check the output is usable
- Every reach number references your data, not estimates AI made up
- Confidence scores below 100% explain what validation would raise them
- Top 5 includes strategic must-ships you named, even if low RICE
- Bottom 5 reasoning includes “comes back when X happens” if applicable
- The sequencing in top 5 considers dependencies, not just score
Common mistakes
- Trusting AI impact scores without data. The most common scoring failure
- Skipping confidence. High RICE on unvalidated features wastes sprints
- No “watch list”. Features that should re-enter when the world changes get forgotten
- One-shot scoring. RICE needs re-scoring each quarter, not once
- Letting AI suppress the strategic must-ship. You wrote it down; honour it
Practical depth notes
For How to Use AI to Prioritise Features: RICE Scoring with Honest Pushback, the difference between a usable AI result and a generic one is the input packet. Give the model the audience, the current draft or raw material, the desired format, the decision you need to make, and two examples of what good and bad output look like. Ask it to preserve facts first, then improve structure or wording second.
After the first response, do a separate review pass. Look for missing constraints, invented details, weak calls to action, and language that sounds plausible but does not match the real situation. The best final output should be easy to use immediately: clear owner, clear next step, and no hidden assumption that someone else has to untangle. A stronger version of this workflow also defines the handoff. Decide who will use the output, what they should do next, and what information would make them reject it. If the deliverable is copy, test whether it has a single clear action. If it is analysis, test whether it separates observation from recommendation. If it is planning, test whether dates, owners, and tradeoffs are explicit enough for someone else to execute. One final check: compare the finished result against the original goal in a single sentence. If that sentence is hard to write, the output is probably polished but unfocused. Tighten the goal, remove decorative language, and rerun only the weak section instead of regenerating the entire piece.
FAQ
- What about Kano / MoSCoW / WSJF? Same structure, different framework. RICE is the most reusable across product / growth / platform.
- Should the team see the scoring? Yes. Hidden scoring breeds resentment; visible scoring forces specific feedback.
- How often to re-score? Once per sprint for top 5; once per quarter for the full backlog.
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