Product prioritization isn’t just about making a stack of features in a certain order—it also involves juggling the many inputs and opinions of stakeholders. Narrowing that list of demands and feature requests for a sprint or a product roadmap can be the most challenging part of a product manager’s job.
Another prioritization challenge product managers face is knowing how many team members, stakeholders and customers they should involve, and to what degree they should vote on which features, tasks and updates you’ll work on next.
"The most popular feature and the second most popular feature don't necessarily belong together in the same product. You've got to have a deliberate strategy where you go: We have a particular type of customer that we're trying to serve and we are trying to solve their biggest problems in a way that makes us money. That's a complex problem of finding the overlap in multiple different areas, not to mention things that a team can reasonably do technologically.”
- Bruce McCarthy, Product Manager and author of Roadmaps Relaunched
Ideally, good product prioritization frameworks allow you to silence the voice of the loudest person in the room using quantitative rankings, charts, and matrixes with values that are directly tied to the product strategy.
For this guide, we rounded up a list of the most commonly used and popular product prioritization methods, as well as the pros and cons of using each one. We read through a ton of prioritization resources, books, forums and spoke to a few product managers about which methods they prefer and why.
Give one of our product roadmap templates a whirl.
1. The Kano Model
The Kano model plots two sets of parameters along a horizontal and a vertical axis. On the horizontal axis, you have the implementation values (to what degree a customer need is met). These values can be classified into three buckets:
- Must-haves or basic features: If you don’t have these features, your customers won’t even consider your product as a solution to their problem.
- Performance features: The more you invest in these, the higher the level of customer satisfaction will be.
- Delighters or excitement features: These features are pleasant surprises that the customers don’t expect, but that once provided, create a delighted response.
On the vertical axis, you have the level of customer satisfaction (the satisfaction values). They range from the needs not being met on the left, all the way to the needs being fully met on the right (the implementation values). The way you get this customer insight is by developing a Kano questionnaire where you ask your customers how they’d feel with or without any given feature.
The core idea of the Kano model is that the more time you spend investing resources (time, money, effort) to create, innovate and improve the features in each of those buckets, the higher the level of customer satisfaction will be.
- The Kano model teaches you not to overestimate excitement features and to not underestimate must-haves.
- It can help you make better product decisions and market predictions around your features and your audience’s expectations for those features.
- The Kano questionnaire can be time-consuming. In order to get a fair representation of all your customers, you need to carry a number of surveys that are proportionate to the number of customers you have.
- Your customers might not fully understand the features you’re surveying them about.
If you're an agile product team, check out our guide to creating an agile roadmap.
2. Story mapping
The beauty of this product prioritization framework is in its simplicity. It also puts the focus on the user’s experience, rather than on the internal opinions of your team and stakeholders.
Along a horizontal line, you create a series of sequential buckets or categories that represent each stage of the user’s journey through your product. This allows you to think about the way your customers navigate your product from signing up, to setting up their profile, to using specific features.
Along a vertical line, you then place these tasks in order of importance, from top to bottom. This allows you to prioritize the order of the features you’ll work on. In some cases, the bottom part of the axis is labeled “Backlog items” for the tasks that you decide to put on hold.
Finally, you draw a line across all these stories to divide them into releases and sprints.
- It helps you quickly—and efficiently—identify your MVP.
- It’s centered around the user’s experiences. You get to write user stories.
- It’s collaborative. Story mapping is a group activity that involves the whole team.
- It doesn’t take into account external product prioritization factors like business value and complexity.
3. The MoSCoW Method
The MoSCoW method allows you to figure out what matters the most to your stakeholders and customers by classifying features into four priority buckets. MoSCoW (no relation to the city—the Os were added to make the acronym more memorable) stands for Must-Have, Should-Have, Could-Have, and Won’t-Have features.
- Must-Have: These are the features that have to be present for the product to be functional at all. They’re non-negotiable and essential. If one of these requirements or features isn’t present, the product cannot be launched, thus making it the most time-sensitive of all the buckets.
Example: “Users MUST log in to access their account”
- Should-Have: These requirements are important to deliver, but they’re not time sensitive.
Example: “Users SHOULD have an option to reset their password”
- Could-Have: This is a feature that’s neither essential nor important to deliver within a timeframe. They’re bonuses that would greatly improve customer satisfaction, but don’t have a great impact if they’re left out.
Example: “Users COULD save their work directly to the cloud from our app”
- Won’t-Have: These are the least critical features, tasks or requirements (and the first to go when there are resource constraints). These are features that will be considered for future releases.
The MoSCoW model is dynamic and allows room for evolving priorities. So a feature that was considered a “Won’t-Have” can one day become a must-have depending on the type of product.
- It’s good for involving stakeholders without a technical background in the product prioritization process.
- Quick, easy and intuitive way of communicating priorities to the team and the customers.
- It allows you to think about resource allocation when you classify your features and requirements into each bucket.
- It’s tempting for teams and stakeholders to overestimate the number of Must-Have features.
- It’s an exercise in formulating release criteria more than a prioritization method.
4. Opportunity scoring
Also known as opportunity analysis, this prioritization method comes from Anthony Ulwick’s Outcome-Driven Innovation concept. His theory states that customers buy products and services to get certain jobs done. The idea is that, while customers aren’t very good at coming up with the solutions to their problems, their feedback is still important. This feedback is what the product team will use to come up with the desired outcomes for a product or feature.
Opportunity scoring uses a Satisfaction and Importance graph to measure and rank opportunities. After you come up with a list of ideal outcomes, you then survey your customers to ask them the following questions:
- How important is this outcome or feature? Ask your customers to rank them.
- How satisfied is the customer with the existing solutions?
After you plot these answers along the chart, you should be able to see the features that matter the most to the customers (the outcomes) yet currently have low satisfaction scores within your product. These are the features you’ll prioritize for your next sprint.
- It’s a simple framework for quickly identifying the most innovative solutions to a common problem.
- It’s easy to visualize and categorize on a graph.
- In the survey or questionnaire, customers might overestimate or underestimate the importance of a feature.
5. The Product Tree
Also known as pruning the product tree, this collaborative innovation game was developed by Bruce Hollman. The focus of this activity is to shape the product so it matches the customer outcomes that will bring the highest value to the company. The game aims to prune product backlog items to ensure that innovative ideas aren’t being left behind.
Here’s how it goes:
- First, draw a large tree with a few big branches on a whiteboard or a piece of paper.
- The trunk of your tree represents the features your product already has.
- The outermost branches represent the features that will be available in the next release.
- The other branches represent the features that aren’t available yet.
Ask your participants (in this case, your customers) to write some potential features on sticky notes. These will be the leaves of your tree.
Then, ask your customers to place their feature leaves on a branch.
By asking customers to place their desired features on the tree, you can identify the biggest clusters or branches. This will allow you to determine which areas of your product need more work, which features need to be changed, and what product feature areas can be deprioritized from all immediate future releases.
- It gives you a visual sense of how well balanced your product’s features are.
- It’s highly collaborative, allowing you to tap directly into the insight of your customers without relying on a rigid survey.
- This method doesn’t give product managers any quantitative values for how to rank each feature, only a general visual guide.
- Features aren’t separated into any sort of grouping bucket, making the exercise time-consuming.
6. Cost of Delay
Joshua Arnold defined Cost of Delay as “a way to communicate the impact of time on the outcomes [the company wishes] to achieve.” Specifically, cost of delay allows you to ask the questions:
- What would this feature be worth if the product had it right now?
- How much would it be worth it if this feature gets made earlier?
- How much would it cost if it was made later than planned?
The way you assign this monetary value to each feature is by calculating how much time and team effort they will take to build. You and the team can also assign value to the features in terms of how much they will be worth after they’re built.
So, let’s say you have one feature that costs you $30,000 per each week that it’s delayed, and it will only take three months to build. On the other hand, you have a feature that costs $10,000 per each week that it’s delayed and it will take you the same amount of time to build. Within this prioritization framework, the first feature would be the one your team focuses on first.
- It allows you to quantify your product backlog in terms of money.
- It helps product managers make better decisions based on the value that matters the most to the company.
- It changes the team’s mindset around features from cost and efficiency metrics, to speed and value.
- The parameters for determining the monetary value of a feature are based on gut-feel and intuition. This can lead to internal disagreements regarding the arbitrary value of any given feature.
7. Buy a feature
Buy a feature is an innovation game that can involve customers and stakeholders (it’s up to you and the needs of your product). When you use it as an exercise with your customers, this method can quantifiably tell you how much a feature or an idea is worth to the people who’ll end up using it.
The game goes like this:
Choose a list of features, ideas, or updates and assign a monetary value to each one. This value isn’t arbitrary—it should be based on how much time, money and effort each feature will cost you and the team.
Put together a group of people (up to 8 customers or your own internal team). Give them a set amount of money to “spend” on these features.
Ask your participants to buy the features they like. Some customers will put all of their money on only one feature they’re passionate about, others will spread their cash around multiple different features. Ask the participants to explain why they spent money on the feature they picked.
Then, reorganize that list of features in order of how much money your customers were willing to spend on them.
Innovation games suggests that you price some of the features high enough that no one can buy them. This forces your customers to team up and negotiate which feature they’d be willing to pool their money on.
- If you believe in that Steve Jobs quote (“People don't know what they want until you show it to them”) but you also would like to tap into the wisdom of your customers, this method is perfect.
- It replaces the stuffy, old-schooled customer questionnaire with a collaborative, fun exercise that forces your customers to rationalize why they think they need a feature.
- This prioritization method can only include features that you’ve already decided to include in a product development roadmap—the results just tell you what features customers value the most.
- Ideally, the activity requires you to get a group of customers in one place at the same time, which can be difficult to coordinate.
Product prioritization methods shouldn’t replace human input in decision-making. A good framework should be a tool to get everyone on the same page in terms of what the greater goals are for the product. Prioritization methods are an exercise in assessing the many possible decisions that can be made around any given feature or idea. They’re not meant to give you the final decision on a silver platter.
Ideally, a prioritization method should do a few things:
- It should be a collaborative process that involves multiple team members, stakeholders, and, depending on the framework, your customers.
- The framework that you choose should give you the results that will drive the product strategy forward.
- It should motivate the team to position their prioritization reasoning in terms of how each idea contributes to the greater goals of the company.
Your prioritization method should push your team to get rid of the “idea noise”—it should completely weed out the ideas that are useless or worthless.
Product managers are managers of the “why”. Good product managers know how to back up their reasoning for why a feature should be next in the pipeline. In order to get buy-in, product managers have to use qualitative and objective data. The parameters for those results should be based on a combination of the product strategy, the product vision, the common goals of the company, and a prioritization framework.
Create + share beautiful roadmaps: try Roadmunk's free 14 day trial by signing up here.