prioritization · diff
git:20260303.f77c189 to git:20260303.19bc151
52 added, 46 removed. Audit A to A.
---
name: prioritization
description: >
Prioritize a feature backlog or list of ideas. Use when the user says "help me prioritize",
- "prioritize this backlog", "RICE score these", "MoSCoW", "what should we build first",
- "rank these features", or has a list of items and needs to decide order
- - even if they don't explicitly say "prioritization framework".
+ "prioritize this backlog", "RICE score these", "MoSCoW", "opportunity solution tree",
+ "what should we build first", "rank these features", or has a list of items and needs
+ to decide order - even if they don't explicitly say "prioritization".
---
## Overview
- Prioritization removes the loudest-voice problem. A framework forces explicit tradeoffs. Use RICE when you need a defensible numeric score. Use MoSCoW when you need fast stakeholder alignment.
+ Based on **Continuous Discovery Habits** by Teresa Torres + RICE scoring. Torres's key insight: teams prioritize solutions when they should be prioritizing opportunities (unmet user needs). Map opportunities first, then generate solutions. Use RICE to score which opportunity is worth pursuing.
## Workflow
- ### Step 1: Identify the framework
- Ask the user which framework they want, or recommend based on context:
- - **RICE** - when you need data-driven scoring and can estimate reach/impact
- - **MoSCoW** - when you need fast consensus across stakeholders
- - **Both** - when you want RICE to inform MoSCoW buckets
-
- ### Step 2a: RICE Scoring
+ ### Step 1: Separate opportunities from solutions
+ Before scoring anything, sort the backlog into:
+ - **Opportunities** - unmet user needs, pain points, desires ("users can't track their progress")
+ - **Solutions** - specific things to build ("add a dashboard")
- Score each item on:
- - **Reach** - How many users affected per period? (number)
- - **Impact** - How much does it move the needle per user? (0.25 / 0.5 / 1 / 2 / 3)
- - **Confidence** - How sure are you? (100% / 80% / 50%)
- - **Effort** - Person-weeks to build (number)
+ Prioritize at the opportunity level. For each opportunity, generate 2-3 possible solutions. This prevents locking into one solution prematurely.
- Formula: `RICE = (Reach x Impact x Confidence) / Effort`
+ ### Step 2: Build the Opportunity Solution Tree (optional, for complex backlogs)
+ ```
+ Outcome (what business result do we want?)
+ └── Opportunity 1 (unmet user need)
+ └── Solution A
+ └── Solution B
+ └── Opportunity 2
+ └── Solution C
+ ```
- Present as a table:
- | Feature | Reach | Impact | Confidence | Effort | RICE Score |
- |---------|-------|--------|------------|--------|------------|
+ ### Step 3: RICE Score each opportunity
+ | Opportunity | Reach | Impact | Confidence | Effort | RICE |
+ |-------------|-------|--------|------------|--------|------|
- ### Step 2b: MoSCoW Bucketing
+ - **Reach** - Users affected per period (number)
+ - **Impact** - Effect per user: 0.25 / 0.5 / 1 / 2 / 3
+ - **Confidence** - How sure are you: 100% / 80% / 50%
+ - **Effort** - Person-weeks (number)
+ - **Formula:** `(Reach x Impact x Confidence) / Effort`
- Assign each item to:
- - **Must Have** - Without this, the release fails
- - **Should Have** - High value, not critical for launch
+ ### Step 4: Apply MoSCoW for stakeholder alignment
+ Use RICE scores to inform MoSCoW bucketing:
+ - **Must Have** - Highest RICE, directly tied to outcome
+ - **Should Have** - High value, not critical this cycle
- **Could Have** - Nice to have, cut if pressed
- - **Won't Have** - Explicitly out of scope this cycle
+ - **Won't Have** - Explicitly out this cycle
- ### Step 3: Identify conflicts
- Flag items where stakeholders are likely to disagree. Surface these explicitly rather than burying them in a ranked list.
+ ### Step 5: Identify assumption gaps
+ Torres's approach: before committing to a solution, list the riskiest assumptions. Flag items where confidence is low and assumptions are untested.
- ### Step 4: Recommend top 3
- Summarize with a clear recommendation: "Based on this scoring, focus on X, Y, Z in this cycle. Consider A next cycle."
+ ### Step 6: Recommend clearly
+ State: "Focus on X, Y, Z this cycle. Reason: [one sentence per item]."
## Anti-Patterns
- **1. Scoring without data**
- Bad: Assigning RICE scores based on gut feel without stating the assumptions.
- Good: State assumptions explicitly. "Reach = 500 assumes 20% of MAU hits this flow - validate with analytics."
+ **1. Prioritizing solutions before opportunities**
+ Bad: "Should we build a dashboard or a report export?"
+ Good: "The opportunity is: users can't track progress. Which solution best addresses that?"
- **2. Everything is "Must Have"**
- Bad: Stakeholders label every item Must Have to protect their work.
- Good: Force a constraint: "You have 3 Must Have slots. Which 3?" Scarcity forces honest prioritization.
+ **2. Scoring without assumptions**
+ Bad: RICE scores presented as facts.
+ Good: "Confidence = 50% because we haven't validated this with users yet."
- **3. Prioritizing solutions instead of problems**
- Bad: "Build a dashboard" vs "Build export feature" - these are solutions.
- Good: Reframe as problems first: "Users can't track progress over time" - then prioritize the problem, then pick the solution.
+ **3. Everything is Must Have**
+ Bad: Stakeholders protect everything by labeling it critical.
+ Good: Force constraint: "You have 3 Must Have slots. Pick 3." Scarcity reveals real priorities.
- **4. Never revisiting**
- Bad: RICE score set once, never updated.
- Good: Scores are estimates. Flag items for re-scoring when new data arrives.
+ **4. No connection to outcome**
+ Bad: Prioritizing features that don't tie to a measurable business outcome.
+ Good: Every top-priority item maps to an explicit outcome at the top of the tree.
## Quality Checklist
- - [ ] Framework choice is explained (why RICE or MoSCoW for this situation)
- - [ ] RICE: all four factors scored with stated assumptions
+ - [ ] Opportunities separated from solutions before scoring
+ - [ ] RICE scores have stated assumptions
+ - [ ] Confidence reflects actual evidence level
- [ ] MoSCoW: no more than 40% of items in Must Have
- - [ ] Conflicts and disagreements are surfaced, not hidden
- - [ ] Clear recommendation at the end
- - [ ] Scores are labeled as estimates, not facts
+ - [ ] Top priorities connect to a stated business outcome
+ - [ ] Clear recommendation with reasoning at the end