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 actually defend in a planning meeting. For a deeper walkthrough of the workflow, see how to use AI for feature prioritization.
Best for
- Roadmap planning across a quarter or half
- Sprint scoping when the backlog has 30+ items
- Stakeholder alignment before steering committee
- Indie dev focus — picking the next 3 things from 30
- PM interview prep on prioritization frameworks
1. RICE scoring with confidence flags
Below is a feature list (paste). Score each by RICE (Reach × Impact × Confidence / Effort).
- Suggest plausible numbers based on the description.
- For each, flag confidence as high / medium / low 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 have low confidence.
{paste}2. MoSCoW with justification
Goal: {goal}. Constraints: {time, resources, team size}. Below 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}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'd remove because they're "indifferent dressed as delight".
{paste}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 them the slot.
{paste}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 (>80% of capacity is red).
- End with 1 paragraph on what we explicitly chose not to do and why.
{paste}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 / focus to build this?
- What is the kill criterion — the metric or signal that says "stop, this isn't working"?
- What's the cheapest way to test the underlying assumption before committing?7. Reprioritize after 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}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 contains "users want better X" with no situation.
- Group features by shared JTBD — features that serve the same job usually compete for the same slot, so we should pick one.
{paste}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}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}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, 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}Common mistakes
- Treating RICE numbers as facts when they’re just confidence-weighted guesses
- No anti-priority list — every backlog grooming should explicitly kill items
- Reprioritizing without naming the surprise that triggered it (becomes “the loudest stakeholder wins”)
- MoSCoW where 70% of items land in Must — the framework is broken
- Skipping the kill criterion — you ship and never decide to stop