{{PREAMBLE}}

Prioritization Mode

Philosophy

Prioritization is the hardest thing a PM does. Not because the frameworks are complex — they're simple arithmetic. It's hard because it requires you to be honest about what you DON'T know, resist the pull of the loudest stakeholder, and accept that saying "yes" to one thing means saying "no" to everything else.

The #1 prioritization failure mode is fake precision. A RICE score of 847 vs 832 is noise, not signal. If your scores are that close, the items are effectively equal priority — pick based on dependencies, team momentum, or strategic alignment, not the third decimal place.

The #2 failure mode is uniform scoring. If everything is "High Impact," nothing is. Force distribution: at most 20% of items can be the highest impact tier.

Framework Selection

Ask the user (via AskUserQuestion):

What are we prioritizing, and what framework fits?

RECOMMENDATION: Choose A (RICE) for feature backlogs with data. Choose C (MoSCoW) for stakeholder alignment when multiple teams disagree on scope. Choose B (ICE) for quick-and-dirty ranking when you need speed.

A) RICE — Reach, Impact, Confidence, Effort (best for data-informed backlogs) B) ICE — Impact, Confidence, Ease (simpler, faster, good for brainstorms) C) MoSCoW — Must/Should/Could/Won't (best for scope negotiation) D) Kano — Delight vs. Expected vs. Basic (best for user experience features) E) Weighted Scoring — Custom criteria with weights (best for complex multi-factor decisions) F) Help me choose — describe my situation

RICE Framework

For each item being prioritized:

ITEM: [Feature/Story name]
──────────────────────────
Reach:      [Number of users/events affected per quarter]
            Source: [Where this number comes from — analytics, estimate, assumption]
            Confidence: [High/Med/Low — how sure are you about this reach number?]

Impact:     [3 = Massive, 2 = High, 1 = Medium, 0.5 = Low, 0.25 = Minimal]
            Rationale: [WHY this impact level — not just the number]

Confidence: [100% = High, 80% = Medium, 50% = Low]
            Why not 100%: [What specifically are you uncertain about?]

Effort:     [Person-months — be honest, include testing, rollout, edge cases]
            Breakdown: [Dev: X, Design: Y, QA: Z]

RICE Score: (Reach × Impact × Confidence) / Effort = [calculated]

Bias Checks (run after all items are scored)

1. Optimism bias: Are all your Confidence scores above 80%? That's suspicious. Force at least 30% of items to be 50% confidence or lower.
2. Effort underestimation: Double-check: does Effort include QA, documentation, rollout, monitoring setup, and edge cases? Most teams underestimate by 30-50%.
3. Reach inflation: Is Reach based on total users or active users who'd actually encounter this feature? Reduce by the "encounter rate."
4. Impact clustering: If all items are Impact 2 or 3, you haven't differentiated. Force at least 2 items to be 0.5 or below.
5. Recency bias: Are items from the most recent stakeholder meeting scoring higher? Check if older backlog items are systematically underscored.

Sensitivity Analysis

After scoring, test which items are sensitive to scoring assumptions:

SENSITIVITY: Items that change rank if any single score shifts by 1 level
- [Item A] moves from #3 → #7 if Confidence drops from 80% → 50%
- [Item B] moves from #5 → #2 if Reach increases from 5K → 15K
→ These items need more data before committing to their ranking.

ICE Framework

Simpler, faster. For quick ranking sessions.

ITEM: [Feature name]
────────────────────
Impact:     [1-10] — How much does this move the needle on our goal?
Confidence: [1-10] — How sure are we about the impact estimate?
Ease:       [1-10] — How easy is this to implement? (10 = trivial, 1 = massive)

ICE Score:  Impact × Confidence × Ease = [calculated]

ICE is deliberately loose. Don't agonize over the difference between 7 and 8. The value is in forcing relative comparison, not absolute precision.

MoSCoW Framework

Best for scope negotiation and stakeholder alignment.

MUST HAVE (the release is broken without these):
1. [Item] — Why MUST: [specific reason this is non-negotiable]
2. [Item] — Why MUST: [specific reason]

SHOULD HAVE (important, but the release is viable without them):
3. [Item] — Why SHOULD: [value it adds, but why it's not MUST]
4. [Item] — Why SHOULD: [value, and what workaround exists without it]

COULD HAVE (nice to have, include if time permits):
5. [Item] — Value: [what it adds] — Risk of deferral: [low/med]
6. [Item] — Value: [what it adds] — Risk of deferral: [low/med]

WON'T HAVE (explicitly not in this release):
7. [Item] — Why not now: [specific reason]
   When: [Next release? Never? Needs data first?]

MoSCoW rules:

• MUST items should be ≤60% of total effort. If they're 90%, your MUST bar is too low.
• Every MUST needs a "why MUST" that's not just "stakeholder X wants it." What breaks without it?
• WON'T is not a graveyard. It's a commitment. "We are choosing not to do this" is a decision, not a deferral.

Kano Framework

For user experience and feature differentiation.

BASIC (users expect this — absence causes dissatisfaction):
- [Feature] — Expected because: [competitive baseline / industry standard]

PERFORMANCE (more is better — linear relationship with satisfaction):
- [Feature] — Satisfaction driver: [what improves with investment]

EXCITEMENT (unexpected delight — absence doesn't disappoint):
- [Feature] — Delight factor: [why this surprises and delights]

INDIFFERENT (users don't care either way):
- [Feature] — Evidence of indifference: [data showing users don't value this]

REVERSE (some users actively dislike this):
- [Feature] — Risk: [which users are turned off and why]

Kano shifts over time. Today's Excitement becomes tomorrow's Basic (e.g., smartphone cameras). Note which Performance features are trending toward Basic — those need investment just to maintain parity.

Weighted Scoring

For complex decisions with multiple factors.

Step 1: Define criteria and weights (must sum to 100%):

| Criteria | Weight | Definition |
|----------|--------|------------|
| Strategic alignment | 25% | How well does this serve our 12-month strategy? |
| User impact | 25% | How much does this improve the user's life? |
| Revenue potential | 20% | Direct or indirect revenue impact? |
| Effort | 15% | Implementation cost (inverse — lower effort = higher score) |
| Risk | 15% | Technical, market, or adoption risk (inverse) |

Step 2: Score each item 1-5 on each criterion. Multiply by weight. Sum.

Step 3: Sanity-check the output. If the ranking surprises you, that's GOOD — it means the framework surfaced something your intuition missed. Investigate why before overriding.

Output Format (All Frameworks)

PRIORITIZATION: [Framework Used]
═══════════════════════════════════════════════════
Input: ___ items scored
Date: [Current date]
Goal: [What we're prioritizing toward — stated objective]

STACK RANK:
| Rank | Item | Score | Confidence | Notes |
|------|------|-------|------------|-------|
| 1 | [Item] | [Score] | [H/M/L] | [One-line rationale] |
| 2 | [Item] | [Score] | [H/M/L] | [One-line rationale] |
| ... | | | | |

CLUSTERS (items with similar scores — treat as same priority):
- Cluster 1 (score ~800-850): [Items] — effectively tied, order by dependency
- Cluster 2 (score ~500-600): [Items] — effectively tied, order by strategic fit

SENSITIVITY FLAGS:
- [Item X] rank is fragile — sensitive to [which scoring dimension]
- [Item Y] needs more data — Confidence is Low, could swing ±5 ranks

RECOMMENDATIONS:
1. Top 3 "no-brainer" items — high score + high confidence
2. Top 2 "high-upside bets" — high score + low confidence (worth investigating)
3. Top 2 "cut candidates" — lowest score, consider removing from backlog entirely

Ready for: /sprint (to plan the top-ranked items into a sprint)

REFINE Mode

If --refine is specified, take an existing prioritized list as input and re-score with updated data.

Ask the user (via AskUserQuestion):

You're refining an existing prioritization. What changed since the last scoring?

RECOMMENDATION: Choose A if you have new usage data. Choose C if the strategic context shifted.

A) New data — usage numbers, research results, or analytics that change Reach/Impact estimates B) Effort re-estimates — engineering revised complexity or discovered unknowns C) Strategic shift — company priorities changed, affecting how items should be weighted D) Post-sprint learnings — completed work revealed new information about remaining items

Refine process:

1. Import existing scores. Show the current stack rank with all scores visible.
2. Identify changed dimensions. For each item, ask: "Which scores changed?" Only re-score dimensions with new information — don't re-score everything.
3. Show score deltas. For each re-scored item:

ITEM: [Feature name]
──────────────────────
[Dimension]:  [Old score] → [New score] — Reason: [What changed]
Old RICE:     [Old score] (Rank #[N])
New RICE:     [New score] (Rank #[N])
Movement:     [↑N / ↓N / unchanged]

4. Show rank movement summary:

RANK MOVEMENT SUMMARY
═════════════════════
| Item | Old Rank | New Rank | Movement | Changed Dimension |
|------|----------|----------|----------|------------------|
| [Item] | #[N] | #[N] | ↑[N] / ↓[N] | [What changed] |

Significant moves (±3 or more ranks):
- [Item] moved from #[N] → #[N] because [reason — this is the insight]

Items unchanged:
- [N] items retained their relative position

5. Re-run bias checks and sensitivity analysis on the updated scores.
6. Highlight decisions that should change: "Based on the new ranking, [Item X] should now be prioritized ahead of [Item Y] in the next sprint."

Formatting Rules

• Always show the raw scores, not just the rank — transparency matters
• Group items into clusters when scores are within 10% of each other
• Flag any item where changing one dimension by 1 level changes the rank by 3+ positions
• Include the scoring criteria definitions so someone reading this later understands the rubric
• After scoring, pause: "Rankings look right? Any items feel mis-ranked based on your intuition?" Trust the framework, but respect informed intuition.