What is feature prioritization?

Choosing what to build next is probably the most important part of a product manager’s job. Yet this job is often considered more an art than a science.

This however, is not very surprising considering there are always a handful of things to juggle between before making prioritization decisions.

Why do product managers have to prioritize?

The need for feature prioritization arises from the fact that product managers will almost always not have enough resources to work on all their product requirements.

In addition to this, there are almost always multiple stakeholders with varying priorities trying to pull the product in different directions.

While trying their best to make the right decisions, PMs are faced with the task of selling their vision and bringing the team on the same page while satisfying customer needs and fulfilling business outcomes at the same time.

Because there are so many different people and requirements to juggle, product prioritization often turns into decisions driven by intuition rather than being driven by data and conscious choices.

Choosing the right Prioritization method

Most product managers struggle to make a decision when it comes to choosing the right prioritization method. One of the best ways to go about this step is to have an overview of the different types of frameworks and their strengths and weaknesses.

Quantitative Prioritization Frameworks:

These frameworks focus on bringing objectivity to the decision making process by associating customer needs and business targets to specific numbers that are used to drive product decisions.

1. Action Priority Matrix

This is often the default “first” quantitative prioritization technique that most product teams choose to use : and for good reason. The value vs effort chart is the best way to establish a direct relationship between customer value and development effort.

Prioritization Matrix
Priority Matrix - Source

Step 1: Capture a list of features or user stories that need to be built.

Step 2: Score each of these features by their engineering difficulty.

Step 3: Try to capture the perceived amount of value in each of these features from a customer standpoint.

Step 4: Plot each feature or user story on these two attributes.

Step 5: Each feature can now be categorized into one of four categories.

  • Quick Wins
  • Major Projects
  • Fill-Ins
  • Thankless tasks

When deciding the roadmap for the next weeks (or months), product teams usually need a good mix of quick wins, fill-ins and one or two major projects based around big bets that the company wants to make for their customers.

2. QFD Prioritization Matrix

The QFD method can be used to create a quantitative relationship between the voice of the customer and the voice of the company. This way any prioritization decision can have both customer and company goals represented.

QFD Prioritization table
QFD Prioritization - Source

Here’s a step by step guide to getting started with the QFD method -

Step 1: Identify customer requirements.

Step 2: Identify customer priorities.

Step 3: Identify company goals.

Step 4: Create a relationship between customer and company.

Step 5: Generate Ranks for requirements.

Step 6: Examine the ranks.

3. ScoreCard

The scorecard is a rather straightforward method of trying to prioritize feature requirements. This method establishes a relationship between features and business outcomes (pre agreed with stakeholders) and tries to bring out a ranked order of features to be built.

Scorecard for feature prioritization
Prioritization Scorecard - source

Step 1: Identify feature requirements

Step 2: Identify internal criteria that need to be considered when choosing a feature

Step 3: Meet with stakeholders and fine tune the criteria and weights for each.

Step 4: Score each feature on various business criteria

Step 5: Generate Priorities for the various features

This is a simple method that can add objectivity to any prioritization effort. It however comes with some drawbacks:

  • The score of each feature request is subject to be impacted by the opinions of the product manager
  • The prioritization results may often lack any sense of product direction
  • It often doesn’t take into consideration the risk of failure of any of these features (even though that can be one of the criteria that features can be scored by)

4. Theme Screening

Some of the drawbacks of the scorecard method can be overcome by using a theme screening method of feature prioritization. The method is similar to the scorecard method, however, some small changes are made to help eliminate the bias of the product manager while trying to incorporate product themes and directions onto the numbers.

Feature theme screening
Theme Screening for features

Step 1: Identify feature requirements from customers

Step 2: Identify internal themes that need to be considered when choosing a feature

Step 3: Meet with stakeholders and fine tune the criteria. In this method, the criteria are product themes rather than prioritization criteria.

Step 4: The scoring mechanism is different from the scorecard method. This is to eliminate bias and bring a little more objectivity to the process. For starters, the score of each feature is restricted to 3 options

  • (+) for positive impact
  • (-) for negative impact
  • (0) for neutral impact

Step 5: Based on the impact that each feature has on the various internal product themes, the feature requirements are ranked by order of importance.

Qualitative Prioritization Frameworks:

These are frameworks that focus on capturing the intuition of the various stakeholders of the product development process and bringing some method to the decision making process.

Some of the most common frameworks of the qualitative type include:

5. Buy a feature

The buy a feature method is a simple method that can be used by internal teams (or customers) to understand the comparative importance of a set of feature requests.

It is inspired from an innovation game and can be a fun alternative to feature prioritization. The sequence of arriving with a prioritized set of outcomes is as follows:

Step 1: A set of feature requests is presented to the stakeholders

Step 2: Each stakeholder is given a budget of money to be spent on the various features. The total budget for every player should be less than half of the cost of all the features together

Step 3: The stakeholders are forced to spend their budget on features individually.

The amount of money spent in total for each feature will be a fair indicator of how important the feature is to the group.

The buy a feature method suffers of being heavily biased in favour of the cohort of stakeholders. Thus the effectiveness of this method depends on the stakeholders being a fair representation of the product's customer base.

6. Prune the product tree

This method of feature prioritization approaches feature prioritization from a feature parity stand point. The general idea of this method is that a product is like a tree with various features being main branches of the tree with smaller sub features and user stories coming out of the main branches.

Creating a visual tree representing the product will show how each branch of the product has progressed from a feature development standpoint.

Mature product "branches" will have a large number of sub-branches or user stories while newer initiatives may be a lot smaller in comparison.

This visual method of breaking down your product will help product managers understand product areas that need improvement.

While this method is a great visual aid to help with feature prioritization, more elaborate quantitative techniques are usually needed on top of this to validate problems surfaced by pruning the product tree.

7. MoSCoW:

The MoSCoW method is a common prioritization technique that is used in various fields. It has also found a place in the modern software product management.

The overall approach of this method is to break down feature requests into several buckets:

  • Must have features - These are critical features that form a core of the product's value proposition. Not having any of these features when the product is taken into market will severely impact the product's chances of market success.
  • Should have features - These are features that are considered extremely important but not critical. Features that are characterised under this bucket can be picked up in subsequent releases while the engineering team focuses on knocking off some of the Must have features.
  • Could have features - These include the "nice to have" features that do not make or break the core of the product. Any feature that is characterised into this bucket will serve as a vitamin rather than a pain-killer for the customer.
  • Won't have features - These are features that do not fit the current product strategy or are not being considered for the immediate product roadmap.

The MoSCoW method offers a simple method of bucketing and prioritizing feature requests. This often helps very early stage products plan and release features iteratively but becomes a bit harder to use once products become more mature.

8. Story Mapping


Story mapping or user story mapping is a qualitative technique used to visualise user stories from a customer journey point of view.

Story mapping begins with creating a set of activities in a chronological order of the user's journey in the product. For instance, sign up and onboarding is often the first activity which is later followed by core activities and then peripheral ones. These activities are placed on a horizontal axis in a whiteboard.

The next step is for the product owner to map user stories to activities. This way every user story in the project management system is bucketed under a particular activity.

The last step to arriving at a story map is to prioritize the user stories in a vertical axis within their respective activity. The most important user stories are placed on top while the smaller, less important user stories are placed further down.

The story map represents a prioritised, visual view of the user stories mapped to various user activities in the user journey. Once problem areas are identified (through product analytics, surveys or any quantitative methods) in the product, the product manager can use the story map to identify which set of stories to choose for the next release to best solve the customer's pain points.

Ensuring that all bases are covered

One of the biggest challenges for product managers is to make sure that every aspect of the decision making process is covered when coming up with a prioritized product roadmap for the future.

Every prioritization technique brings with it its own set of biases and weaknesses. It is important for teams to recognize these weaknesses and cover for them. This is often done by choosing a combination of frameworks to have multiple perspectives of the same feature requirements. It is also important to incorporate a mix of quantitative and qualitative frameworks to ensure that your intuition is also captured adequately.

Great products are built not only by solid metric driven prioritization but also by great market insights from product leaders. It is important to factor all of these in while trying to prioritize before creating a product roadmap.