Skip to content
Back to Idea Validation

Feature Prioritization

Rank features by impact on the core hypothesis and effort, using a framework like RICE or MoSCoW.

Why

After the MVP ships, you have 20 features users asked for and capacity for 3. Feature prioritization frameworks prevent the two failure modes: building the loudest-user features (squeaky wheel wins) and building the most interesting features (engineer bias). RICE (Reach × Impact × Confidence /!RICE (Reach × Impact × Confidence / Effort) scores each feature on four dimensions that together estimate value-per-unit-effort. MoSCoW (Must/Should/Could/Won't) forces explicit categorization. The framework matters less than the discipline of scoring before building — the act of ranking surfaces assumptions you would otherwise act on silently.

When

After MVP launch, when you have a backlog of user requests. Takes half a day per prioritization round. Re-rank every 2-4 weeks.

How

1. List all candidate features
   - From user requests, your vision, and analytics observations
   - Each as a one-liner: "what" + "which user" + "what outcome"

2. Choose a framework
   - RICE: quantitative, good for comparing dissimilar features
   - MoSCoW: categorical, good for release planning
   - Impact/Effort matrix: visual, good for small sets

3. Score each feature (!Score each feature (RICE example)
   - Reach: how many users benefit? (1 = few, 5 = all)
   - Impact: how much does it help them? (1 = nice, 5 = unlocks use)
   - Confidence: how sure are you? (1 = guess, 5 = data-backed)
   - Effort: how many person-weeks? (1 = quick, 5 = major)
   - RICE = (Reach × Impact × Confidence) / Effort

4. Sort and draw the line
   - Sort by score descending
   - Draw a line at your capacity (e.g. top 3 for next sprint)
   - Everything below the line waits

5. Sanity-check the top and bottom
   - Top: does the highest-score feature actually serve the core hypothesis?
   - Bottom: is the lowest-score feature there for a reason you should respect? (strategic, not just score)

6.!Bottom: is the lowest-score feature there for a reason you should respect? (strategic, not just score)

6. Communicate the ranking
   - Share with the team and key users
   - Explain why top features won and bottom ones wait
   - This builds trust and prevents re-litigating every sprint

Example

Product: AI changelog generator, 2 weeks post-launch.
Backlog (12 features from user requests):

  Feature                          |!Feature                          | R  I  C  E  | RICE
  Custom templates                !Custom templates                  | 2  4  4  2  | 16
  Multi-repo support               | 3  5  4  3  | 20
  Slack auto-publish               | 2  3  3  2  | 9
  Semantic versioning              | 4  4  5  1  | 80  ← #1
  Custom sections (!Custom sections (grouping)        | 4  5  4  2  | 40  ← #2
  PDF export                       | 1  2  4  2  | 4
 !PDF export                       | 1  2  4  2  | 4
  API access                       | 1  4  3  4  | 3
  Team workspaces                  | 2  3  2  5  | 2
  AI tone adjustment               | 3  2  2  2  | 6
  Webhook on publish               | 1  3  4  1  | 12
!Webhook on publish               | 1  3  4  1  | 12
  Changelog hosting                | 2  4  3  4  | 6

Top 3 (next sprint):
  1. Semantic versioning (80) — high reach, high impact, low effort, data-backed
  2. Custom section grouping (40) — users explicitly asked, improves output quality
  3. Multi-repo (20) — power users hit the 1-repo limit, blocking retention

Deferred: Slack publish (9), API (3), team workspaces (2) — low reach or high effort for current segment.

Common Problems

  • ⚠Scoring confidence as 5 for everything — if everything is "sure", confidence is meaningless; reserve 5 for data-backed and use 2-3 for guesses.
  • ⚠Ignoring effort — a feature with RICE 40 and effort 4 weeks blocks the pipeline for a month; consider effort in capacity planning, not just the score.
  • ⚠Re-litigating every sprint — if the ranking changes weekly, your scoring is inconsistent; set criteria and stick to them for 2-3 sprints.
  • ⚠Prioritizing the loudest user — one user's urgent request is not high reach; score reach by how many users actually have the need.

Best Practices

  • ✓Use RICE for comparing dissimilar features and MoSCoW for release planning — they answer different questions and complement each other.
  • ✓Score confidence honestly — 5 is for data-backed (analytics, A/B test), 3 is for strong user signal, 1-2 is for gut feel; this prevents over-scoring pet projects.
  • ✓Re-rank every 2-4 weeks with new data — features that were low priority may rise as user needs evolve or as you ship the higher-priority ones.
  • ✓Share the ranking with users — "here is our priority and why" turns feature requests into understanding of your constraints, reducing repeat asks.