Feature prioritization techniques

Framework for thinking about prioritization:

  1. Think about the company’s mission/purpose and vision for that mission
  2. Think about the long-term and short-term goals set by the company to achieve that vision
  3. Prioritize products, features, etc. based on their potential to achieve those goals
  4. Define metrics to measure the performance of your prioritized products, features, etc.
  5. Monitor metrics and iterate to re-prioritize to stay aligned to the company’s mission


Before you start your prioritization activity:
– Approach prioritization as a team activity. That gets buy-in from the team and you get different perspectives.
– Understand customer value for each initiative. Customer value should be rooted in evidence gathered from customers.
– Understand business value for each initiative. Business value can be strategic, monetary, etc.
– Have an estimate of cost for each initiative.

1. Value vs Complexity Quadrant
Value vs Complexity Quadrant

2. Weighted Scoring
Weighted Scoring

3. Story Mapping
Create a story map of your product in Popplet and always keep it current. Use the story map to prioritize horizontally first. Horizontal prioritization will give you what you need include in the next release. Then go into each vertical and prioritize features in each vertical.

4. BUC framework
B – Business advantage of the initiative
U – user advantage of the initiative
C – Cost to build the initiative

5. Feature categorization
– Metrics Movers
– Customer Requests
– Delight
– Strategic
Organize the features in categories and prioritize based on what you want to focus on.

6. MoSCoW framework
Must Have
– Cannot deliver on target date without this
– No point in delivering on target date without this; if it were not delivered, there would be no point deploying the solution on the intended date
– Not legal without it
– Unsafe without it
– Cannot deliver the Business Case without it

Should Have
– Important but not vital
– May be painful to leave out, but the solution is still viable
– May need some kind of workaround, e.g. management of expectations, some inefficiency, an existing solution, paperwork, etc.

Could Have
– Wanted or desirable but less important
– Less impact if left out (compared with a Should Have)

Won’t have this time
These are requirements which the project team has agreed it will not deliver.