Updated: April 3, 2024 - 26 min read
One of the most challenging aspects of Product Management is prioritization. If you’ve transitioned to Product from another discipline, you might already think you know how to do it. You choose which task to work on first, which deadline needs to be met above all others, and which order to answer your emails in.
Priorities, right? Wrong!
In product management, prioritization is on a whole other level! The engineers are telling you that Feature A will be really cool and will take you to the next level. But a key stakeholder is gently suggesting that Feature B should be included in V1. Finally, your data analyst is convinced that Feature B is completely unnecessary and that users are crying out for Feature C.
Who decides how to prioritize the features? You do.
Prioritization is absolutely essential for Product Teams and product development. It can feel daunting, but for a successful launch, it has to be done.
Luckily, a whole community of Product experts has come before you. They’ve built great things, including some excellent prioritization frameworks!
Quick summary
Here’s what we’ll cover in this article:
The benefits and challenges of prioritization
The best prioritization frameworks and when to use them
How real Product Leaders implement prioritization at Microsoft, Amazon, and HSBC
Common prioritization mistakes
Frequently Asked Questions
Benefits and challenges of prioritization
Before we dive into the different prioritization models, let’s talk about why prioritization is so important and what holds PMs back.
Benefits of effective feature prioritization
Enhanced focus on key objectives: Prioritization allows you to concentrate on tasks that align closely with your product's core goals. For example, when Spotify prioritized personalized playlists, it significantly boosted user engagement, aligning perfectly with its goal of providing a unique user experience.
Resource optimization: You can allocate your team’s time and your company’s resources more efficiently. Focusing on fewer, more impactful projects can lead to greater innovation and success.
Improved decision-making: When you prioritize, you're essentially making strategic decisions about where to focus efforts. This clarity in decision-making can lead to more successful outcomes, avoiding the pitfalls of cognitive biases like recency bias and the sunk cost fallacy.
Strategic focus: Prioritization aligns tasks with the company's broader strategic goals, ensuring that day-to-day activities contribute to long-term objectives.
Consider the example of Apple Inc. under the leadership of Steve Jobs. One of Jobs' first actions when he returned to Apple in 1997 was to slash the number of projects and products the company was working on.
Apple refocused its efforts on just a handful of key projects. This ruthless prioritization allowed Apple to focus on quality rather than quantity, leading to the development of groundbreaking products like the iPod, iPhone, and iPad.
Stress reduction: From customer interactions to executive presentations, the responsibilities of a PM are vast and varied, often leading to a risk of burnout if not managed adeptly. For more on this, check out this talk by Glenn Wilson, Google Group PM, on Play the Long Game When Everything Is on Fire.
Challenges of prioritization
Managing stakeholder expectations: Different stakeholders may have varying priorities. For instance, your engineering team might prioritize feature development, while marketing may push for more customer-centric enhancements. Striking a balance can be challenging.
Adapting to changing market conditions: The market is dynamic, and priorities can shift unexpectedly. When the pandemic hit, Zoom had to quickly reprioritize to cater to a massive surge in users, emphasizing scalability and security over other planned enhancements.
Dealing with limited information: Even in the PM & PMM world, having a strong data-driven team is more often a dream rather than a current reality. Even when there is data, you can’t know everything. Amazon’s decision to enter the cloud computing market with AWS was initially seen as a risky move, but they prioritized the gamble and it paid off spectacularly.
Limited resources: Smaller businesses and startups don’t have the luxury of calmly building lots of small features, hoping that some of them will improve the product. The less funding a company has, the fewer mistakes (iterations) it can afford to make when building an MVP or figuring out Product-Market Fit.
Bias: If you read The Mom Test book, you probably know that people will lie about their experience with your product to make you feel comfortable. This means that product prioritization can be influenced by biased opinions, having “nice-to-have” features at the top of the list.
Lack of alignment: Different teams can have varying opinions as to what is “important”. When these differences aren’t addressed, product prioritization can become a fight between what brings Product-Led Growth, more leads, higher Net Promoter Score, better User Experience, higher retention, or lower churn. Lack of alignment is not the last issue startups face when prioritizing features.
Prioritization Frameworks
There are a lot of prioritization models for PMs to employ. While it’s great to have so many tools at your disposal, it can also be a bit overwhelming. You might even ask yourself which prioritization framework you should…prioritize.
In reality, each model is like a different tool in your toolbox. Just like a hammer is better than a wrench at hammering nails, each model is right depending on the type of prioritization task at hand. The first step is to familiarize yourself with the most trusty frameworks out there. So, without further ado, let’s get started.
The MoSCoW method
Known as the MoSCoW Prioritization Technique or MoSCoW Analysis, MoSCoW is a method used to easily categorize what’s important and what’s not. The name is an acronym of four prioritization categories: Must have, Should have, Could have, and Won’t have.
It’s a particularly useful tool for communicating to stakeholders what you’re working on and why.
According to MoSCoW, all the features go into one of four categories:
Must Have
These are the features that will make or break the product. Without them, the user will not be able to get value from the product or won’t be able to use it. These are the “painkillers” that form the why behind your product, and often are closely tied to how the product will generate revenue.Should Have
These are important features but are not needed to make the product functional. Think of them as your “second priorities”. They could be enhanced options that address typical use cases.Could Have
Often seen as nice to have items, not critical but would be welcomed. These are “vitamins”, not painkillers. They might be integrations and extensions that enhance users’ workflow.Won’t Have
Similar to the “money pit” in the impact–effort matrix framework, these are features that are not worth the time or effort they would require to develop.
Pros of using this framework: MoSCoW is ideal when looking for a simplified approach that can involve the less technical members of the company and one that can easily categorize the most important features.
Cons of using this framework: It is difficult to set the right number of must-have features and, as a result, your Product Backlog may end up with too many features that tax the development team.
RICE scoring
Developed by the Intercom team, the RICE scoring system compares Reach, Impact, Confidence, and Effort.
Reach
Reach centers the focus on the customers by thinking about how many people will be impacted by a feature or release. You can measure this using the number of people who will benefit from a feature in a certain period of time. For example, “How many customers will use this feature per month?”
Impact
Now that you’ve thought about how many people you’ll reach, it’s time to think about how they’ll be affected. Think about the goal you’re trying to reach. It could be to delight customers (measured in positive reviews and referrals) or reduce churn.
Intercom recommends a multiple-choice scale:
3 = massive impact
2 = high impact
1 = medium impact
0.5 = low impact
0.25 = minimal impact
Confidence
A confidence percentage expresses how secure team members feel about their assessments of reach and impact. The effect this has is that it de-prioritizes features that are too risky.
Generally, anything above 80% is considered a high confidence score, and anything below 50% is unqualified.
Effort
Considering effort helps balance cost and benefit. In an ideal world, everything would be high-impact/low-effort, although this is rarely the case. You’ll need information from everyone involved (designers, engineers, etc.) to calculate effort.
Think about the amount of work one team member can do in a month, which will naturally be different across teams. Estimate how much work it’ll take each team member working on the project. The more time allotted to a project, the higher the reach, impact, and confidence will need to be to make it worth the effort.
Calculating a RICE score
Now you should have four numbers representing each of the 4 categories. To calculate your score, multiply Reach, Impact, and Confidence. Then divide by Effort.
Pros of using this framework:
Its spreadsheet format and database approach are awesome for data-focused teams. This method also filters out guesswork and the “loudest voice” factor because of the confidence metric. For teams that have a high volume of hypotheses to test, having a spreadsheet format is quick and scalable.
Cons of using this framework:
The RICE format might be hard to digest if your startup team consists mainly of visual thinkers. When you move fast, it’s essential to use a format that everyone will find comfortable. When there are 30+ possible features for complex products, this becomes a long spreadsheet to digest.
Impact–Effort Matrix
The Impact-Effort Matrix is similar to the RICE method but better suited to visual thinkers. This 2-D matrix plots the “value” (impact) of a feature for the user vs the complexity of development, otherwise known as the “effort”.
When using the impact–effort matrix, the Product Owner first adds all features or product hypotheses. Then the team that executes on these product hypotheses votes on where to place the features on the impact and effort dimensions. Each feature ends up in one of 4 quadrants:
Quick wins
Low effort and high impact are features or ideas that will bring growth.Big bets
High effort but high impact. These have the potential to make a big difference but must be well-planned. If your hypothesis fails here, you waste a lot of development time.Fill-ins
Low value but also low effort. Fill-ins don’t take much time but they still should only be worked on if other more important tasks are complete. These are good tasks to focus on while waiting on blockers to higher priority features to be worked out.Money pit
Low value and high effort features are detrimental to morale and the bottom line. They should be avoided at all costs.
Pros of using this framework: It allows quick prioritization and works well when the number of features is small. It can be shared across the whole startup team, as it’s easy to understand at first glance.
Cons of using this framework: If two product hypotheses are “quick wins”, which should go first? For this reason, it’s not the best framework when there are a lot of features. Also, beware of “fill-ins”, as they can take much more time and resources than expected and create loss of focus.
Kano model
Professor Noriaki Kano, a Japanese educator and influential figure in quality management, developed the Kano model in the 1980s. Since then, it has been widely used by organizations seeking to prioritize customer satisfaction.
Delighters: The features that customers will perceive as going above and beyond their expectations. These are the things that will differentiate you from your competition.
Performance features: Customers respond well to high investments in performance features.
Basic features: The minimum expected by customers to solve their problems. Without these, the product is of little use to them.
The main idea behind the Kano model is that if you focus on the features that come under these three brackets, the higher your level of customer satisfaction will be.
To find out how customers value certain features, use questionnaires asking how their experience of your product would change with or without them.
As time goes along, you may find that features that used to be delighters move down closer towards ‘Basic Features’ as technology catches up and customers have come to expect them, so it’s important to reassess periodically.
Pros of using this framework: Because the model differentiates between basic needs and features that can delight customers, it prioritizes more customer-focused products and services.
Cons of using this framework: The categorization of features into Kano’s categories can be subjective, leading to inconsistencies. It doesn't directly address other crucial aspects like cost, time-to-market, or feasibility, which can also significantly impact product success.
Feasibility, Desirability, and Viability scorecard
Developed by IDEO in the early 2000s, this scorecard takes three core criteria — feasibility, desirability, and viability. It scores each criterion from 1 - 10 for every feature and takes a total to decide on the priority.
Feasibility
Can we build this feature with the skills and resources available? Is it possible to make this particular product hypothesis fast and without hiring extra people? Do you have an available tech stack/tools/cloud storage to do it?Desirability
Does this solve the pain for the customers? Do they want this feature enough to consider paying for it?Viability
How much will users pay for this feature? What’s the (ROI)? Is there any unit economy behind this feature?
Using this framework, your team creates a spreadsheet with product features and puts a score for each parameter. Another way to use this framework is to evaluate MVP ideas for feasibility, desirability, and viability via a team discussion.
Ideas that have the most support from the team on those parameters can go right into the design sprint. Use the relevant people to help with the evaluation. For example, developers to look at feasibility or Product Marketing Managers to discuss desirability. This scorecard is pretty straightforward with clear pros and cons:
Pros of using this framework: The flexibility of the FDV scorecard means it can be used for evaluating marketing initiatives, hypotheses for customer success teams, or MVP concepts. It works well for teams that don’t find rigid frameworks helpful or for a workshop, or discussion on the executive level.
Cons of using this framework: This approach relies a lot on knowledge of what the customer wants and how complex new features are. That is not always data that is readily available.
Weighted Scoring Prioritization
This method follows a similar pattern to other frameworks on this list but with the significant addition of weighting how much of each category counts towards the final total.
The process starts by selecting the criteria/categories you’ll be using to rate the features. For example, you might select “user experience”, “sales value”, “strategic impact”, “user adoption” or any of the Acquisition, Activation, Retention, Referral, Revenue (AARRR) metrics.
Next, you need to decide what importance you give to each category, adding a percentage value to each criterion (up to 100%). For example, during the early stages, you might focus on UX features that make an MVP usable. Each feature will have a score in those categories, from 1 (min impact) – 100 (max impact). Then you can now calculate the final score for each feature.
Pros of using this framework: The framework is customizable, which allows you to utilize the framework throughout an organization’s lifetime.
Cons of using this framework: Sometimes the weighting percentages can be hard to decide on. It requires PMMs & PMs to understand how each feature will influence user adoption across the whole product ecosystem.
Cost of Delay
This framework is unique in that it focuses exclusively on monetary value. The framework is designed to calculate the cost of not producing the feature immediately. It’s relatively straightforward to understand, although the calculation itself does require careful consideration.
The calculation is as follows:
Estimated revenue per unit of time, for example, how much could be billed over a month-long period if the feature existed.
Estimated time it will take to complete the development of the feature.
Divide the estimated revenue by the estimated time to give you the cost of delay.
Pros of using this framework: This is a highly effective way of prioritizing feature backlogs. It is also useful in helping team members align around the value of features in terms of ROI.
Cons of using this framework: For new companies or brand-new features, the revenue estimate is very much based on a gut feeling as there is no hard data to base the estimates on.
Product Tree
Luke Hohmann introduced the concept of ‘Prune the Product Tree’, in his book Innovation Games: Creating Breakthrough Products Through Collaborative Play. During a Product Tree session, stakeholders use stickers, markers, or digital equivalents to place features, ideas, and enhancements on different parts of the tree according to where they think they belong in terms of product development priorities.
Roots: Represent the core technologies, systems, and cap
abilities that support and enable the product's basic functions. These are fundamental aspects without which the product cannot function.
Trunk: Symbolizes the product's main functionalities or the current set of features. It is the stable and established part of the product that supports further growth.
Branches: Illustrate different areas of the product that can grow and expand, such as new feature sets, product lines, or major enhancements.
Leaves: Stand for specific features, ideas, or small enhancements that can be added to the product. These are often more visible to the end-users and can directly contribute to user satisfaction and product value.
Which model should I use?
Knowing which prioritization framework to use is tough! The Kano model is useful for making customer-centric decisions and focus on delight, but it can take time to carry out all the questionnaires needed for your insights to be accurate and fair.
Many people like the RICE scoring system as it takes confidence into account in a qualitative way, but there are still a lot of uncertainties.
MoSCoW focuses on what matters to both customers and stakeholders, which is particularly useful for Product Managers who struggle with managing stakeholder expectations. However, there’s nothing stopping you from putting too many items in ‘Must have’ and overextending your resources.
Of course, these aren’t the only prioritization techniques out there, and many talented Product Managers have their own ways of doing things. All you can do is test, test, and test again!
How to prioritize individual tasks: Tips from busy product leaders
Microsoft: Applying the Eisenhower Matrix to a busy inbox
Microsoft Product Manager Anusha Bahtnagar, uses a prioritization technique called The Eisenhower Matrix to prioritize what comes into her inbox. As a Product Manager working with cross-continental teams, it’s common to wake up to a full inbox.
The Eisenhower Matrix effectively sorts your tasks/emails into four categories, and presents a solution.
Important and Urgent: Top priority tasks that require your urgent attention (eg, crisis management tasks.)
Urgent and Not Important: Time-sensitive tasks that could be handled by someone else. Delegate these tasks.
Important and Not Urgent:
Tasks that you definitely need to do, but they can wait. Schedule these for the future.Not Important and Not Urgent: Declutter and eliminate tasks.
Amazon and Google: Making customer-focused prioritization decisions
A common theme across many companies is that the customer comes first. The same goes for prioritization.
Asal Elleuch, a Senior Product Manager for Amazon Prime, calls prioritization “a never-ending and iterative process.”
Focusing on the customer gives you an incredibly useful yardstick for prioritization. After all, your company’s values should already be customer focused. And most of your stakeholders should also be aligned on The Why.
The Product vision should also be heavily influenced by customer needs.
Being customer-focused in your prioritization will help keep your decisions aligned with everything else. Like one big customer-centric puzzle!
Google product teams achieve this by using North Star Metrics. Your North Star Metric can be any metric or action that provides the most value to the customer. For instance, Spotify’s North Star Metric might be clicking ‘play’ on a song. Google Search’s North Star Metric might be clicking on a search result.
You can then base your prioritization decisions around that metric. Whichever updates/features/bug fixes will have a greater impact on that metric has priority.
HSBC: The art of making impossible product decisions
To help make decisions, with so many outside influences and an interlocking web of things to consider, Product Leader Mariano Capezzani came up with his own prioritization system.
Broken down into 4 steps, it gives you a solid footing for making quality prioritization decisions.
Know the context. Understand things like how this task/feature fits with the KPIs of the company, the market trends, and related upcoming regulations.
Understand the need. Learn to differentiate between what customers are asking for and what they really need.
Consider the execution. Are you aware of the intricate network of dependencies and their interlock that are needed to deliver something?
Arrange the sequence. Apply a quick acid test to ensure it fits your criteria (contributes to company goals, benefits a market, etc.)
Common Product Prioritization Mistakes
Mistake 1: No agreed-upon scoring guide
What does an impact score of “5” mean? A 1% growth or 10%? In conversion rate or MRR? Do other teammates think the same?
Without an agreed-upon scoring guide, you can’t make an apples-to-apples comparison between initiatives. This makes prioritization pointless. To make matters worse, it increases the likelihood of conflicts between team members, as you are essentially disguising opinions as objective decisions.
How to fix it
Develop a shared scoring guide for your prioritization criteria. Define what each level entails with a concrete description and examples. Here’s an example guide for determining the confidence level:
A scoring guide can be created for any prioritization method, as long as it is:
Specific to your product and team context
Objective and clear
It’s important to point out that even with a guideline, there will still be disagreements — and that’s okay. Team members should be comfortable explaining their decisions and giving feedback to others. These discussions will help your team uncover blind spots and build alignment.
Mistake 2: Mixing discovery and delivery
Software development isn’t the only thing that takes time when building a product. So do problem analysis and solution design, commonly referred to together as product discovery.
However, discovery tasks usually get either:
Lumped in with development work → Creates messy dependency issues.
Left out of the prioritization process → Introduces a selection bias from the start.
How to fix it
Divide your product development into discovery and delivery, and prioritize the two backlogs separately. This is called Dual Track Development.
Do note that having separate tracks doesn’t mean you should have separate teams. For any given project, the same team should carry out both discovery and delivery work to maximize quality and velocity.
Mistake 3: Recency bias
Your team will always add items to the backlog faster than it will clear them. Over time, you will build up a long backlog with items from the previous century (year). Because it’s human nature to favor shiny new ideas (a.k.a. recency bias), old items tend to get forgotten for no good reason.
How to fix it
As new evidence emerges, situations change, and your team’s estimation skills improve, you must constantly review old items to correctly prioritize the backlog.
Track the “freshness” of each item. When something has not been updated for longer than X period of time, groom it again using the latest information. If it’s no longer relevant, it’s time to remove it permanently.
Mistake 4: Not considering constraints
Product development is inherently messy. Besides the core value-vs-cost consideration, there are also dependencies, deadlines, skill fit, strategic fit, and other constraints that influence your prioritization decisions.
No matter how ruthless you are with prioritization, you can’t simply dismiss these constraints. However, you also shouldn’t let them override your core prioritization criteria every single time.
Teams that lack a good system to deal with these external factors often end up losing confidence in their prioritization processes altogether.
How to fix it
Define a set of rules to work with these constraints, and make them part of your prioritization system.
Here are a few examples:
Time-sensitive projects → Set aside a fixed amount of resources each month to fast-track projects with non-negotiable deadlines (e.g., scheduled launch events, seasonable campaigns). Everything else will follow the regular process, even if it means not getting done at all.
Dependencies → A project blocked by other tasks will resume its position in the backlog as soon as the blocker is removed. However, it shouldn’t interrupt projects that have already started.
Strategic alignment → Assign more weight to projects that align with the company’s strategic priorities. This can be done with the Weighted Scoring method.
When you have consistent guidelines, people will trust the system, knowing that every decision is made objectively.
Mistake 5: Over-complicating the process
Perfect prioritization does not exist. The information you use for prioritization is simply a set of estimations and estimations are always wrong. There is no need to treat your prioritization process like you’re planning a rocket launch.
Prioritization is an exercise that helps you maximize your execution value. If you constantly direct more resources toward prioritization than execution, you are doing it wrong.
Sometimes product teams spend months debating the relative value between small features when they could have shipped them all in the time lost.
How to fix it
Timebox your prioritization discussion. If your team gets stuck comparing initiatives, introduce a tie-breaker rule. For example, items that entered the backlog first go first.
The point is, trivial differences will not matter in the long run, and if you never decide what goes first you’ll never get started.
Mistake 6: Not iterating the prioritization system
No one gets prioritization right the first time. Even if you are satisfied with your current system, there will always be room for improvement if you look hard enough. Additionally, just because something works today doesn’t mean it’ll continue to work as the company scales. It’s dangerous to think you can create a prioritization system that requires minimal iterations.
How to fix it
Treat your prioritization system (and other internal processes) like your product. Monitor how it’s working and iterate continuously. Because the “users” in this case are your team members, there should be an open channel for everyone to give feedback.
Generally speaking, frequent and small iterations are better than drastic revamps. However, be aware that:
It takes time for a new process to show its effects.
A new process can hurt productivity in the short term.
Not every problem has an easy solution.
To avoid interrupting team momentum with ad-hoc fixes, I recommend doing a quarterly or bi-yearly process review to go over all the feedback and discuss solutions as a team.
Bonus: Management interference
Having to rearrange your backlog due to management input, usually without a convincing reason, is one of the most frustrating yet common things that can happen to a product team. This is often due to a disconnect between company strategy and product strategy.
How to fix it
Such a discrepancy exists for a combination of reasons:
Management mistakes tactics for strategies. It dictates solutions instead of creating a direction for potential solutions.
Management doesn’t explain the “why” behind a strategy.
There is no clear process for teams to share learnings and evidence (both horizontally and vertically).
There is no agility in the company strategy, even when it no longer makes sense.
If you are a product leader (CPO, director, team lead, etc.), you have a critical responsibility here to bridge the gap between individual teams and senior management. Make sure to communicate information bi-directionally and fix misalignment proactively. A good way to start is by examining:
How are we sharing insights other teams should know?
Does every team have the same access to key information (ICP, positioning, data dashboard, etc.)?
What information does my team want to know but is out of their reach?
FAQs
What is the best framework for prioritizing product features?
There is no ‘best framework’. There is only the best framework for a given prioritization task. Now that you’re familiar with the frameworks that product experts use day-to-day, look back at your OKRs and decide which model will turn your backlog into the right product at this moment in time.
Who prioritizes the backlog?
The Product Manager is typically responsible for finalizing the prioritization, balancing stakeholder interests, user value, and feasibility.
Developers provide input on feasibility and effort estimates to help the PM. Stakeholders help PMs and developers understand business value and promote strategic alignment.
What is the best prioritization tool?
There are tons of great prioritization tools out there, like our free template pack, which includes templates for 5 prioritization models.
Whatever tool you use, the most important thing is to align around the model you’ll use and make sure everyone is using the same model in pursuit of the same OKRs, and make sure to clarify priorities within the timeline of your product roadmap so everyone is aligned.
What are the steps involved in using a prioritization framework?
Follow these general steps whenever using a prioritization model:
Identify the moment: Identify the tasks in the backlog, strategy, and current OKRs.
Decide on a framework that will help you reach your team’s goals and apply it to the tasks in the backlog.
Try other frameworks and see if the same features came in first place.
How often should you review your prioritization framework?
Your team should review its priorities regularly. The cadence of that review depends on your team’s needs. How often is not important as long as it’s consistent. Always re-evaluate your prioritization framework if business objectives change.
Can you use multiple prioritization frameworks?
Yes! In fact, some frameworks pair together as well as a nice chablis and fresh oysters:
Pair subjective and quantitative frameworks for contrast. For example: Cost of Delay + Kano model will balance revenue and customer delight.
Pair bird’s eye views with detailed analysis. Some frameworks are based on a general sense of the market and user trends while others on careful research. Cover your bases by using both. For example: Weighted Scoring + MoSCoW.
Prioritization in product management is less about ticking off tasks and more about leading your product in the right direction. It is a crucial part of framing the priorities within your product roadmap. It is a continuous process of assessment, reassessment, and realignment with your product goals and market needs.
Product Roadmapping Micro-Certification (PRC)™️
Product School has partnered with Productboard to create a micro-certification on how to build and maintain effective Roadmaps. Enroll for free to learn how to communicate the product vision and strategy to your stakeholders and customers.
Enroll for Free
Updated: April 3, 2024
