Prioritization Frameworks for Roadmaps

The hardest part of roadmapping isn't deciding what to build; it's deciding what not to build. Without a framework, prioritization becomes a battle of opinions (usually won by the Highest Paid Person's Opinion, or HiPPO). A structured approach removes emotion and focuses the team on value.

1. RICE Score

Best for: Quantitative comparison of features in mature products.

The RICE scoring model was developed by Intercom to make prioritization objective. It uses four factors:

• Reach: How many people will this impact over a given period? (e.g., 1000 users/month).
• Impact: How much will it increase the key metric? (3 = massive, 2 = high, 1 = medium, 0.5 = low, 0.25 = minimal).
• Confidence: How sure are we about our estimates? (100% = high confidence, 80% = medium, 50% = low).
• Effort: How many "person-months" will this take?

The higher the score, the higher the priority. The "Confidence" lever is crucial—it penalizes wild guesses.

2. MoSCoW Method

Best for: Managing scope within a fixed timeframe (e.g., a specific release or sprint).

• Must Have: Critical for launch. If this is missing, the release is cancelled. (e.g., "Users must be able to log in").
• Should Have: Important but not vital. Can be worked around. (e.g., "Password reset via email").
• Could Have: Nice to have. Only if time permits. (e.g., "Dark mode").
• Won't Have: Out of scope for now. Explicitly agreed not to build.

3. Kano Model

Best for: Balancing customer delight and basic needs.

The Kano model categorizes features based on how they affect customer satisfaction:

• Basic Needs (Threshold): Must be there. If missing, users are angry. If present, users are neutral. (e.g., a car has wheels).
• Performance: More is better. Linear relationship with satisfaction. (e.g., faster load times, better battery life).
• Delighters (Excitement): Unexpected features that wow users. If missing, users don't care. If present, satisfaction skyrockets. (e.g., free snacks on a flight).

Warning: Over time, "Delighters" become "Basic Needs." Wi-Fi in hotels used to be a delighter; now it's a basic need.

Conclusion

Pick a framework and stick to it. It doesn't matter which one you choose as much as it matters that you have a consistent language for saying "no." It helps you defend your roadmap against "feature creep" and ensures you are building the right things for the right reasons.