Prioritization frameworks get gamed the moment the highest-paid person in the room wants a feature on the list. RICE numbers get inflated, MoSCoW collapses into “everything is a must,” and Kano “delight” becomes a euphemism for someone’s pet idea. These prompts force the model to apply the framework honestly and pressure-test the assumptions, so the output is something you can defend in a planning meeting. For the full workflow, see how to use AI for feature prioritization.
TL;DR
- Paste your backlog into prompts 1–3 to get a first-pass RICE, MoSCoW, or Kano sort with reasons attached to each placement.
- The framework values are fixed: RICE Impact uses the 3 / 2 / 1 / 0.5 / 0.25 scale, Confidence uses 100% / 80% / 50%, and the score is
(Reach × Impact × Confidence) / Effort. - Use prompts 4–9 to do the part teams skip: cut features, name kill criteria, and stress-test the #1 priority.
- One hard rule: let the model suggest Reach and Impact, but get Effort from engineering. No model knows your codebase, tech debt, or migration risk.
- Any current model handles this well. Claude Opus 4.7 and GPT-5.5 (both June 2026) give the most disciplined justifications; their 1M-token context (Plus tier fits roughly 320 pages in-app) means you can paste a whole quarter’s backlog at once.
Best for
- Roadmap planning across a quarter or half
- Sprint scoping when the backlog has 30+ items
- Stakeholder alignment before a steering committee
- Indie dev focus — picking the next 3 things from 30
- PM interview prep on prioritization frameworks
The numbers behind RICE, MoSCoW, and Kano
Before the prompts, fix the scales so the model uses the canonical values instead of inventing its own. Paste this table into any RICE prompt as a reference.
| Factor | What it measures | Standard values |
|---|---|---|
| Reach | Users or events affected per time window | Raw count (e.g. 500 users/quarter) |
| Impact | Size of effect per user | 3 (massive), 2 (high), 1 (medium), 0.5 (low), 0.25 (minimal) |
| Confidence | How sure you are of the estimates | 100% (data-backed), 80% (some data), 50% (gut feel) |
| Effort | Person-months of work | Whole number from engineering |
RICE score = (Reach × Impact × Confidence) / Effort. The framework was created by Sean McBride at Intercom; the Intercom write-up is the canonical source. MoSCoW sorts into Must / Should / Could / Won’t-this-cycle. Kano sorts by satisfaction curve: basic (absence hurts), performance (more is better), delight (surprising wins), indifferent (no one cares).
1. RICE scoring with confidence flags
Below is a feature list (paste). Score each by RICE using these scales:
Impact = 3/2/1/0.5/0.25, Confidence = 100%/80%/50%, formula = (Reach x Impact x Confidence)/Effort.
- Suggest plausible Reach and Impact from the description; leave Effort blank for engineering to fill.
- For each, flag confidence as 100/80/50 and name the single biggest unknown.
- Output as a markdown table sorted by RICE score descending.
- After the table, list the top 3 and the 3 that look promising but score low on confidence.
[paste feature list]2. MoSCoW with justification
Goal: [goal]. Constraints: [time, resources, team size]. Below is the feature list.
- Sort into Must / Should / Could / Won't (this cycle).
- Each placement gets a 1-line justification tied to the stated goal.
- Reject the urge to put everything in Must. If more than 30% land there, re-sort.
[paste feature list]3. Kano model classification
For each feature below, classify Kano-style: basic (expected, absence hurts), performance
(proportional, more is better), delight (surprising, wins love), indifferent (no one cares).
- Justify each with 1 line referencing the user segment.
- Flag any features you would remove because they are "indifferent dressed as delight."
[paste feature list]4. Anti-priority list (cuts before lifts)
Below are 15 feature ideas. Cut to top 5.
- For each of the 10 you cut, give a 1-line reason chosen from: "low impact," "duplicates [X],"
"should be a setting not a feature," "premature optimization," "wrong user segment,"
"depends on infra we don't have."
- For the 5 that survive, give the single sentence that earned the slot.
[paste feature list]5. Roadmap from priorities
Given prioritized features (paste with rough t-shirt sizing), draft a 3-month roadmap.
- Group by month with capacity assumptions stated.
- Flag dependency risks (feature B blocked by feature A).
- Flag overcommitment (anything above 80% of capacity is red).
- End with 1 paragraph on what we explicitly chose not to do, and why.
[paste prioritized features]6. Pressure-test the #1 priority
My #1 priority is [feature]. Pressure-test it:
- Who specifically benefits (which segment, which job-to-be-done)?
- Who would not care, or actively dislike it?
- What are we sacrificing in capacity and focus to build this?
- What is the kill criterion — the metric or signal that says "stop, this isn't working"?
- What is the cheapest way to test the underlying assumption before committing?7. Reprioritize after a surprise
Current quarter goals: [goals]. Surprise event: [what changed: competitor launch, churn spike,
infra incident, headcount cut].
- Reprioritize remaining work: what stays, what moves to next quarter, what dies entirely.
- For each "moves" item, name the new trigger that should pull it back in.
- For "dies," name the cost of having built any of it already (sunk-cost honesty).8. Stakeholder framing
My prioritized list (paste). Reframe it for [stakeholder: CEO / sales lead / eng lead / support lead]:
- What they will love about the list.
- What they will push back on, and why.
- The 2-3 sentences I should say first to defuse the pushback.
- The honest concession I can offer if they hold the line.
[paste prioritized list]9. Job-to-be-done crosscheck
For each feature below, name the underlying job-to-be-done (JTBD) in this format:
"When I [situation], I want to [motivation], so I can [outcome]."
- Flag any feature where the JTBD is fuzzy or reads "users want better X" with no situation.
- Group features by shared JTBD. Features serving the same job compete for the same slot, so pick one.
[paste feature list]10. Effort honest-up
Engineering quoted these efforts (paste). Pressure-test the estimates:
- For each, name the single piece of work most likely to blow the estimate (migration,
integration, edge cases, design iteration).
- Flag any feature where the "1 week" estimate hides 2 weeks of design or 1 week of QA.
- Suggest a more realistic range, not a single number.
[paste engineering estimates]11. Dependency and sequencing map
Below are 10 features (paste). Map dependencies:
- Which features unlock which others (A enables B).
- Which features compete for the same shared component (so they can't be parallel).
- The optimal sequence if we only had 2 engineers for 2 months.
- Where breaking a feature into smaller slices would unblock parallel work.
[paste feature list]12. Quarterly retro on prioritization
Last quarter we shipped these [N] features (paste with the metric each was supposed to move).
- For each: did it move the metric? If yes, by how much vs. expected? If no, why: wrong feature,
wrong implementation, or wrong measurement?
- 3-paragraph retro on what to change about how we prioritize next quarter.
- 1 paragraph naming the framework misuse we keep repeating (RICE-gaming, MoSCoW-inflation,
Kano-laundering).
[paste shipped features]Common mistakes
- Treating RICE numbers as facts when they are confidence-weighted guesses.
- Asking the model for Effort. It cannot see your codebase, tech debt, or team — Effort comes from engineering, not the LLM.
- No anti-priority list. Every backlog grooming should explicitly kill items.
- Reprioritizing without naming the surprise that triggered it, which becomes “the loudest stakeholder wins.”
- MoSCoW where 70% of items land in Must. The framework is broken.
- Skipping the kill criterion, so you ship and never decide to stop.
FAQ
Which model should I use for these prompts? Any current frontier model produces a usable RICE or MoSCoW sort. As of June 2026, Claude Opus 4.7 and GPT-5.5 give the most disciplined, defensible justifications and rarely dump everything into “Must.” Both carry a 1M-token context window (a ChatGPT Plus chat fits roughly 320 pages in-app; the full 1M is on the $200 Pro tier), so a full quarterly backlog fits in one paste.
Should I let the AI estimate effort? No. Reach and Impact are reasonable to delegate because they describe user behavior the model can reason about. Effort depends on your codebase, tech debt, integrations, and team — none of which the model can see. Use prompt 10 to pressure-test an engineer’s estimate, never to generate one.
What RICE values should the model use?
Lock the scales in the prompt so it doesn’t invent them: Impact is 3 / 2 / 1 / 0.5 / 0.25, Confidence is 100% / 80% / 50%, and the score is (Reach × Impact × Confidence) / Effort. Without that, models tend to score Impact on a 1–10 scale and Confidence as a fraction, which breaks comparability across runs.
How do I stop MoSCoW collapsing into all-Must? The 30% cap in prompt 2 does most of the work. If the model still over-fills Must, follow up with “Re-sort: only the items that block the stated goal stay in Must; everything else demotes one level.”
Can I combine Kano and RICE? Yes, and it is the strongest pairing. Run Kano (prompt 3) first to label each feature’s satisfaction type, then RICE (prompt 1) to rank within those labels. Basic features that score low on RICE still ship — they’re table stakes, not optional.