메뉴
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", 피처 순위 매겨줘".
기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.
설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
직접 명령은 검토 Prompt를 거치지 않습니다. 실행하기 전에 소스를 확인하세요.
npx skills add https://github.com/newkayak12/claude-skills --skill feature-prioritization명령은 한 줄로 유지됩니다. 복사하기 전에 가로로 스크롤해 전체 내용을 확인하세요.
로컬 사본을 원하시나요? SkillsMP에서 현재 제공할 수 있는 파일을 다운로드하세요.
SKILL.md 표시 중
SOC 직업 분류 기준
| name | feature-prioritization |
| effort | high |
| description | 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 엔드포인트를 추가하세요."} |
Deciding what to build first — with a process that's defensible, data-informed, and repeatable.
| 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 |
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.
Use when you have a backlog of features and need a quantitative ranking to compare across initiatives.
Formula:
RICE Score = (Reach × Impact × Confidence) ÷ Effort
| Factor | Definition | Scale |
|---|---|---|
| Reach | How many users affected per quarter | Absolute number (e.g., 5,000 users/quarter) |
| Impact | How much it moves the target metric per user | 3 = massive, 2 = high, 1 = medium, 0.5 = low, 0.25 = minimal |
| Confidence | How confident are you in the estimates | 100% = high evidence, 80% = medium, 50% = low |
| Effort | Total person-months of work | Absolute number (e.g., 2 person-months) |
Walkthrough example:
Feature: In-app guided onboarding tour
RICE = (3,000 × 2 × 0.80) ÷ 1.5 = 4,800 ÷ 1.5 = 3,200
Tips:
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:
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)
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:
High-risk Strategic Bets should be preceded by a discovery spike before full commitment.
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.
Strong prioritization decisions are evidence-backed. Gather input from:
../competitive-analysis/SKILL.md — is a competitor shipping this?../customer-research-synthesis/SKILL.md — how many users asked for this? How painfully?../metrics-interpretation/SKILL.md — does data show this problem is real and large?../okr-planning/SKILL.md — does this feature directly move a current Key Result?../stakeholder-management/SKILL.md — when "everyone wants P1," the real problem is often stakeholder misalignmentPriority | 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:
| 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 |
| 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 |
../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"