prioritization

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", "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

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: 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")

Prioritize at the opportunity level. For each opportunity, generate 2-3 possible solutions. This prevents locking into one solution prematurely.

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

Step 3: RICE Score each opportunity

Opportunity	Reach	Impact	Confidence	Effort	RICE

• 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

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 this cycle

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 6: Recommend clearly

State: "Focus on X, Y, Z this cycle. Reason: [one sentence per item]."

Anti-Patterns

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. Scoring without assumptions Bad: RICE scores presented as facts. Good: "Confidence = 50% because we haven't validated this with users yet."

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. 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

• 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
• Top priorities connect to a stated business outcome
• Clear recommendation with reasoning at the end