Use when there are more things to build than capacity allows and the team needs a defensible, data-backed order. Triggers on: "backlog 정리", "우선순위 정해줘", P1이 너무 많아", "what to build next", "how do we decide", "backlog grooming", 피처 순위 매겨줘".
Use when there are more things to build than capacity allows and the team needs a defensible, data-backed order. Triggers on: "backlog 정리", "우선순위 정해줘", P1이 너무 많아", "what to build next", "how do we decide", "backlog grooming", 피처 순위 매겨줘".
type
workflow
theme
pm-strategy
best_for
["Scoring and ranking a large backlog with RICE or MoSCoW","Resolving stakeholder disagreements about what to build next","Trimming scope for a specific cycle or quarter"]
scenarios
["P1이 너무 많아. 이번 분기에 뭐부터 해야 할지 모르겠어.","We have 50 items in the backlog. Help me figure out what to cut.","두 팀이 서로 다른 기능을 원해. 우선순위 기준을 만들어줘.","Score these features using RICE and give me a ranked list.","백로그에서 이번 분기 스코프를 잘라줘.","How do I explain to my VP why we're not building feature X?"]
estimated_time
45-90 min
compatibility
{"recommended":["think-tool"],"optional":["sequential-thinking","mcp-reasoner"],"remote_mcp_note":"think-tool이 있으면 RICE 점수의 근거와 트레이드오프 논리를 검증하는 데 도움이 됩니다. Claude 설정 → MCP Servers에서 remote SSE 엔드포인트를 추가하세요."}
Standing Mandates
ALWAYS make scoring criteria explicit and agreed-upon before scoring anything.
ALWAYS separate impact estimation from effort estimation to avoid anchoring bias.
NEVER let stakeholder volume or seniority substitute for data in prioritization decisions.
NEVER prioritize a backlog without first defining 'priority toward which goal this cycle'.
Feature Prioritization
Deciding what to build first — with a process that's defensible, data-informed, and repeatable.
When to Use / When Not to Use
Use
Do Not Use
Backlog has more items than team capacity
Deciding what goals to set (use okr-planning)
Stakeholders disagree on feature priority
Communicating the resulting roadmap (use roadmap-communication)
Trimming scope for a specific cycle
Writing a PRD for a single feature (use prd-development)
Need scoring rubric stakeholders can agree on
One-off small feature that needs no justification
Core Principle
Prioritization is not ranking by enthusiasm. It is making trade-offs explicit, using consistent criteria, and being willing to say what you are NOT building and why. A prioritized list with no reasoning is just a to-do list. A prioritized list with shared criteria is a team decision.
Framework 1: RICE Scoring
Use when you have a backlog of features and need a quantitative ranking to compare across initiatives.
Use the same time horizon (quarter) for all features when calculating Reach
If confidence is below 50%, consider running a discovery spike before scoring
RICE scores are relative, not absolute — a score of 3,200 only means something when compared to other scores in the same backlog
Recalculate after new evidence changes your confidence or impact estimates
Framework 2: MoSCoW for Scope Decisions
Use when scoping a release, sprint, or MVP — you need to draw a clear in/out line.
Label
Meaning
Criteria
Must Have
Launch is impossible without this
Legal, safety, core user flow, contractual
Should Have
Important but launch is viable without it
Significantly improves experience; can follow in v1.1
Could Have
Nice to have if time and effort allow
Delighter, edge case, minor improvement
Won't Have (this time)
Explicitly out of scope for this release
Future roadmap, deprioritized, not now
How to run a MoSCoW session:
List every item under consideration
Timebox the "Must Have" sorting: if everything is Must Have, challenge each item — "what breaks if we don't ship this?"
Sort remaining items into Should/Could/Won't as a group, not solo
Document the Won't Haves with brief rationale — this is as important as the Must Haves
Output format:
Release: [Name] | Target date: [Date]
MUST HAVE
- [ ] Core checkout flow (no payment = no revenue)
- [ ] Email confirmation (regulatory requirement)
SHOULD HAVE
- [ ] Saved payment methods (reduces friction for returning users)
- [ ] Order history page (high-demand user request)
COULD HAVE
- [ ] Dark mode
- [ ] CSV export
WON'T HAVE (this release)
- [ ] Mobile app (separate initiative — Q3)
- [ ] Third-party integrations (dependencies not ready)
Framework 3: Value-Risk-Effort Grid
Use when you need a visual, fast way to prioritize without scoring — good for workshops and backlog grooming sessions.
Two-step process:
Step 1 — Plot on a 2×2: Value (Y-axis) vs. Effort (X-axis)
Quadrant
Label
Action
High value, low effort
Quick Wins
Do first — no debate
High value, high effort
Strategic Bets
Plan carefully — these are your roadmap anchors
Low value, low effort
Fill-ins
Do when capacity allows; never let these block Quick Wins
Low value, high effort
Time Sinks
Deprioritize or kill — defend this quadrant ruthlessly
Step 2 — Add a Risk overlay
For Strategic Bets only, add a risk score:
Technical risk (do we know how to build it?)
Market risk (do we know users want it?)
Dependencies (does it require another team or vendor?)
High-risk Strategic Bets should be preceded by a discovery spike before full commitment.
Handling "Everything Is P1"
This is the most common prioritization failure mode. Use these approaches:
Technique 1 — Forced ranking
"I understand everything feels urgent. If you could only have ONE of these shipped in the next 6 weeks, which one would move your most important goal the most?"
Repeat until you have a ranked list. People find it much easier to choose between two options than to rank ten.
Technique 2 — Show the trade-off explicitly
Create a table: [Feature A] vs. [Feature B]. For each, show estimated reach, impact, and effort. Ask stakeholders to agree on criteria before seeing the scores.
Technique 3 — Capacity constraint as an anchor
"We have 4 engineer-weeks until the end of the quarter. These 7 features total 22 engineer-weeks of work. Which 4 weeks of work do we ship?"
Making the constraint concrete shifts the conversation from "what's important" (everything) to "what fits" (a real choice).
Technique 4 — Defer with a commitment
"Feature X isn't in the next cycle. It IS in the planning horizon for Q3. I'll put it in the backlog with your context attached so it's not lost."
Documentation as commitment reduces the emotional stakes of being deprioritized.
Connecting Prioritization to Evidence
Strong prioritization decisions are evidence-backed. Gather input from:
Competitive pressure data:../competitive-analysis/SKILL.md — is a competitor shipping this?
Customer demand evidence:../customer-research-synthesis/SKILL.md — how many users asked for this? How painfully?
Metric evidence:../metrics-interpretation/SKILL.md — does data show this problem is real and large?
OKR alignment check:../okr-planning/SKILL.md — does this feature directly move a current Key Result?
Stakeholder conflicts from prioritization:../stakeholder-management/SKILL.md — when "everyone wants P1," the real problem is often stakeholder misalignment
Output: Prioritized Backlog Format
Priority | Feature | RICE Score | Rationale | Quarter | Owner
---------|---------|-----------|-----------|---------|------
P1 | Guided onboarding | 3,200 | Directly drives activation KR; high confidence from user research | Q2 | [Name]
P2 | Saved payment methods | 2,100 | Reduces checkout friction; validated in usability sessions | Q2 | [Name]
P3 | Dark mode | 420 | Community request; low effort but low impact on KRs | Q3 | [Name]
Deferred | Third-party integrations | — | Dependency on vendor API not ready; revisit Q4 | Q4 | [Name]
Include in every prioritized list:
The criteria used (RICE, MoSCoW, or explicit trade-off reasoning)
What is NOT being built this cycle and why
The OKR or goal each prioritized item serves
Review date (when will this list be revisited?)
What Claude Does / What You Do
Claude
You
Applies RICE, MoSCoW, or Value-Risk-Effort to provided items
Supplies the reach, impact, and confidence inputs
Generates scored, ranked backlog table with rationale
Validates effort estimates with engineering
Drafts "why not this" explanations for deprioritized items
Makes final priority call and owns stakeholder conversations
Surfaces anti-patterns (everything is P1, no OKR alignment)
Aligns cross-functional team on the final ordering
Connects items to OKRs and evidence sources
Provides the customer research evidence and business context
Quick Diagnostic
Signal
Problem
Action
Every item is P1
No shared criteria for priority
Run forced ranking or capacity-constraint exercise
Backlog keeps growing but nothing ships
Items added but never removed
Institute a "one in, one out" rule or quarterly backlog pruning
Stakeholders disagree on ranking
Misaligned on goals or criteria
Align on OKRs first; then re-run prioritization with shared criteria
High-RICE items keep getting bumped
Political pressure overriding data
Document each override; make the pattern visible to leadership
Team disagrees on effort estimates
Estimation variance is high
Run planning poker; break large items into smaller ones
Nothing in the backlog maps to a current OKR
Backlog is reactive, not strategic
Audit backlog against current OKRs; anything that doesn't map needs explicit justification
Related Skills
../competitive-analysis/SKILL.md — competitive pressure data for RICE impact scoring
../customer-research-synthesis/SKILL.md — insight cards as customer demand evidence
../metrics-interpretation/SKILL.md — metric data to validate problem size
../okr-planning/SKILL.md — OKR alignment check for each backlog item
../roadmap-communication/SKILL.md — communicate the prioritized list to stakeholders
../stakeholder-management/SKILL.md — resolve political conflicts when "everything is P1"
