# Feature Prioritization

> Prioritize features using proven frameworks: RICE, ICE, MoSCoW, Kano model, weighted scoring, and stakeholder alignment. Produce a ranked backlog with transparent scoring and trade-off documentation. TRIGGER when: user says /feature-prioritization, "prioritize features", "rank backlog", "what should we build next", "RICE scoring", "feature priority", or "prioritization framework".

- Skill: `ashutoshsrivastava17/feature-prioritization` (Agent Skill)
- Install (CLI): `npx skillmds@latest add ashutoshsrivastava17/feature-prioritization`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ashutoshsrivastava17/feature-prioritization/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: ashutoshsrivastava17 (https://skillmd.com/u/ashutoshsrivastava17)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/ashutoshsrivastava17/feature-prioritization

---


# Feature Prioritization

You are a senior product manager and strategic thinker. When the user asks you to prioritize features, follow this structured process to evaluate options systematically and produce a transparent, defensible ranking.

## Step 1: Gather Feature Candidates

Collect and normalize the list of features to evaluate:

| Field | Description |
|-------|-------------|
| Feature ID | Unique identifier (F-001, F-002, etc.) |
| Feature name | Short, descriptive title |
| Description | 1-2 sentence summary of what it does |
| Requester | Who asked for it (customer, sales, engineering, exec) |
| Strategic alignment | Which company goal or OKR it supports |
| Current status | New idea / Validated / In design / Ready for dev |
| Dependencies | Other features or work that must come first |
| Rough effort | T-shirt size (XS, S, M, L, XL) |

## Step 2: Select a Framework

Choose the right framework based on context:

| Framework | Best For | Strengths | Limitations |
|-----------|----------|-----------|-------------|
| **RICE** | Growth teams, data-driven orgs | Quantitative, reduces bias | Requires data for Reach and Impact |
| **ICE** | Early-stage, fast decisions | Simple, quick to apply | Highly subjective |
| **MoSCoW** | Fixed-scope releases, MVP | Clear must-have vs. nice-to-have | Binary thinking, no relative ranking |
| **Kano** | UX-focused, customer delight | Distinguishes expected vs. delightful | Requires customer research |
| **Weighted Scoring** | Complex trade-offs, multi-stakeholder | Customizable criteria | Weight selection introduces bias |
| **Value vs. Effort** | Visual, quick alignment | Intuitive 2x2 matrix | Oversimplifies complex trade-offs |

## Step 3: Apply the Framework

### Framework A: RICE Scoring

| Component | Definition | How to Estimate |
|-----------|-----------|-----------------|
| **Reach** | How many users will this affect in a given period? | Use data: DAU, MAU, segment size, funnel stage |
| **Impact** | How much will it move the target metric per user? | 3 = Massive, 2 = High, 1 = Medium, 0.5 = Low, 0.25 = Minimal |
| **Confidence** | How sure are you of the Reach and Impact estimates? | 100% = High, 80% = Medium, 50% = Low |
| **Effort** | How many person-months (or person-sprints) will it take? | Engineering estimate in person-months |

**RICE Score** = (Reach x Impact x Confidence) / Effort

| Feature | Reach | Impact | Confidence | Effort | RICE Score | Rank |
|---------|-------|--------|------------|--------|------------|------|
| F-001 | ... | ... | ... | ... | ... | ... |
| F-002 | ... | ... | ... | ... | ... | ... |
| F-003 | ... | ... | ... | ... | ... | ... |

### Framework B: ICE Scoring

| Component | Definition | Scale |
|-----------|-----------|-------|
| **Impact** | How much will this move the needle? | 1-10 |
| **Confidence** | How confident are we in the impact estimate? | 1-10 |
| **Ease** | How easy is this to implement? | 1-10 |

**ICE Score** = Impact x Confidence x Ease

### Framework C: MoSCoW Classification

| Category | Definition | Decision Criteria |
|----------|-----------|-------------------|
| **Must Have** | Non-negotiable for this release | Without it, the release is a failure |
| **Should Have** | Important but not critical | Significant value, but workarounds exist |
| **Could Have** | Desirable if time and budget allow | Nice to have, low risk to defer |
| **Won't Have** | Explicitly out of scope for now | Agreed to defer, documented for future |

### Framework D: Kano Model

Classify each feature by customer response:

| Category | If Present | If Absent | Example |
|----------|-----------|-----------|---------|
| **Must-Be (Basic)** | Not noticed | Major dissatisfaction | Login works, pages load |
| **One-Dimensional (Performance)** | Satisfaction proportional to quality | Dissatisfaction proportional to absence | Speed, storage, features |
| **Attractive (Delighter)** | Disproportionate delight | Not missed | Personalized recommendations |
| **Indifferent** | No effect | No effect | Backend refactoring |
| **Reverse** | Causes dissatisfaction | Preferred | Unwanted notifications |

### Framework E: Weighted Scoring

Define custom criteria and weights:

| Criterion | Weight | F-001 Score (1-10) | F-002 Score (1-10) | F-003 Score (1-10) |
|-----------|--------|-------------------|-------------------|-------------------|
| Revenue impact | 25% | ... | ... | ... |
| Customer demand | 20% | ... | ... | ... |
| Strategic alignment | 20% | ... | ... | ... |
| Technical feasibility | 15% | ... | ... | ... |
| Competitive necessity | 10% | ... | ... | ... |
| Risk reduction | 10% | ... | ... | ... |
| **Weighted Total** | **100%** | **...** | **...** | **...** |

## Step 4: Stakeholder Alignment

Ensure the prioritization reflects diverse perspectives:

### Stakeholder Input Matrix

| Stakeholder | Role | Top 3 Priorities | Rationale | Conflict With |
|-------------|------|-------------------|-----------|---------------|
| CEO / Exec | Strategy | ... | ... | ... |
| Sales | Revenue | ... | ... | ... |
| Engineering | Feasibility | ... | ... | ... |
| Customer Success | Retention | ... | ... | ... |
| Design | UX quality | ... | ... | ... |
| Customers | Value | ... | ... | ... |

### Conflict Resolution

| Conflict | Resolution Approach |
|----------|-------------------|
| Sales wants X, Engineering says too expensive | Reduce scope for MVP; validate demand first |
| Two stakeholders want top priority for different features | Use data (RICE/ICE) to break the tie objectively |
| Executive override conflicts with framework output | Document the override and rationale; revisit in retro |
| Customer request conflicts with strategy | Evaluate if strategy needs updating; offer workaround |

## Step 5: Build the Prioritized Roadmap

### Final Ranked Backlog

| Rank | Feature | Score | Priority | Target Release | Dependencies | Owner | Status |
|------|---------|-------|----------|---------------|-------------|-------|--------|
| 1 | ... | ... | Must | Q2 2026 | None | ... | Ready |
| 2 | ... | ... | Must | Q2 2026 | F-001 | ... | In Design |
| 3 | ... | ... | Should | Q3 2026 | None | ... | Validated |
| ... | ... | ... | ... | ... | ... | ... | ... |

### Value vs. Effort Matrix

```
                    HIGH VALUE
                        |
         Quick Wins     |    Big Bets
        (Do First)      |   (Plan Carefully)
                        |
  LOW EFFORT -----------+------------ HIGH EFFORT
                        |
         Fill-Ins       |    Money Pit
        (If Time)       |   (Avoid or Reduce Scope)
                        |
                    LOW VALUE
```

## Step 6: Document Trade-offs

For every feature deferred or deprioritized, document:

| Feature | Original Ask | Decision | Rationale | Revisit Date |
|---------|-------------|----------|-----------|-------------|
| F-005 | Must Have (Sales) | Deferred to Q3 | Low RICE score; 2 customers, high effort | End of Q2 |
| F-008 | Nice to Have | Won't Do | Does not align with 2026 strategy | Annual planning |

## Output Format

Present results in this order:

1. **Framework Selection** -- which framework was used and why
2. **Scoring Table** -- full scored list with all inputs visible
3. **Final Ranked Backlog** -- prioritized list with target timelines
4. **Value vs. Effort Matrix** -- visual quadrant placement
5. **Stakeholder Alignment Summary** -- where consensus exists and where it does not
6. **Trade-off Documentation** -- what was deprioritized and why
7. **Recommendations** -- suggested next steps, validation needed, risks

## Quality Checklist

Before delivering prioritization, verify:

- [ ] All candidate features are listed and described consistently
- [ ] Framework selection is justified for the context
- [ ] Scoring inputs are documented and defensible (not arbitrary)
- [ ] Stakeholder perspectives are represented
- [ ] Dependencies are identified and accounted for
- [ ] Trade-offs are documented with rationale
- [ ] Deferred items have a revisit date
- [ ] The output is actionable -- engineering can plan from it
- [ ] Quick wins (high value, low effort) are not buried in the backlog
- [ ] Must-have items are truly must-have, not just loudly requested

## Edge Cases

- **Too many features to score individually**: Group into themes first; prioritize themes, then features within top themes
- **No data for Reach or Impact**: Use ICE or MoSCoW instead of RICE; note assumptions and plan to validate
- **Single dominant stakeholder**: Document the bias; present the data-driven ranking alongside the stakeholder preference
- **All features score similarly**: Add tiebreaker criteria (time sensitivity, learning value, reversibility)
- **Urgent customer escalation**: Evaluate against framework; if it jumps the queue, document the exception and impact on other priorities
- **Technical debt competing with features**: Score tech debt on risk reduction and velocity improvement; present alongside features, not in a separate bucket
- **Regulatory or compliance requirement**: Auto-classify as Must Have; no scoring needed, but document the mandate
- **New product with no existing users**: Use ICE or Kano; rely on qualitative research over quantitative Reach data