Chapter 1

7 product prioritization frameworks for product managers

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 is one of the most challenging parts 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 matrices 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.


1. Scoring

This simple approach to prioritization involves taking your list of features and initiatives and quantifying them using importance vs difficulty scores (see the chart below). Scorecards can be something as simple as:

  • Value vs. effort/value vs. complexity scores
  • Weighted scorecards
  • RICE
  • Lean prioritization/prioritization matrices

We go over these methods in more detail in our guide to prioritization using weighted and unweighted scorecards. Check it out here.

The final scores are always an estimation. A lot of guesswork and opinions (backed with as much applicable data as possible) are involved in the process of quantifying the big question prioritization aims to answer: “Will this feature/update push our goals and metrics forward if we build it and can we feasibly build it with the resources we have?”

The final scores are always an estimation. A lot of guesswork and opinions (backed with as much applicable data as possible) are involved in the process of quantifying the big question prioritization aims to answer: “Will this feature/update push our goals and metrics forward if we build it and can we feasibly build it with the resources we have?”

product prioritization

Scoring methods like RICE (which we’ll cover below) give product teams a quick and easy way to visualize a set of quantified priorities.

This method of prioritization makes room for healthy discussions among stakeholders on what they believe value and effort means, which in turn helps product managers find the strategic alignment holes and fix them. Here's what a value vs. effort scorecard can look like:

product prioritization

Pros of using these prioritization frameworks

  • What constitutes value or effort is flexible. For some organizations, effort could just mean development effort, in others it could be the implementation cost. A flexible prioritization framework can be used by any type of company, industry or type of product.
  • It’s a good tool for alignment. By encouraging teams to quantify and numerically score features, product teams can agree on which initiatives have more weight than others. It leaves vague guesswork and assumptions out of the prioritization discussions.
  • In companies where resources are extremely limited, something as simple as a value vs. effort analysis allows teams to focus only on the things that will have the biggest impact on their business and product goals.
  • It’s easy to use because it doesn’t involve any complex formulas or models. All it requires is an agreed-upon numerical value that gets added into one overall total number.

Cons of using these prioritization frameworks

  • Like all prioritization exercises, it’s a game of estimation and guessing. This leaves a lot of room for cognitive bias at the hands of the people doing the estimating. The final score for each feature might be too inflated, or not accurate enough.
  • When it’s time for product and development to vote on how high or low the value/effort scores should be, the disagreements can take a while to resolve.
  • It can be hard to use with large teams with multiple product lines, components, and product teams that oversee each of those.


This method of scoring gets its own honorable mention in the list. Known as Intercom’s internal scoring system for prioritizing ideas, RICE allows product teams to work on the initiatives that are most likely to impact their goals.

This scoring system measures each feature or initiative against four factors: reach, impact, confidence and effort (hence the acronym RICE). Here’s a breakdown of what each factor stands for and how it should be quantified:

RICE scoring prioritization

Then, those individual numbers get turned into one overall score using a formula. This formula gives product teams a standardized number that can be applied across any type of initiative that needs to be added to the roadmap.

RICE scoring prioritization

After running each feature by this calculation, you’ll get a final RICE score that you can then use to rank the order in which you’ll build the features. Here’s an example:

RICE scoring prioritization

Pros of using this prioritization framework

  • It requires that product teams make their product metrics SMART before they quantify them. SMART stands for specific, measurable, attainable, relevant and—as seen in the parameter for the Reach score—time-based.
  • By adding a confidence dimension in the calculations, prioritization moves away from attempting to predict success to measuring the level of assertion each team member has for the features. This shifts the prioritization discussions from “Here’s how much this feature is worth“ to “Here is how we are quantifying our level of confidence for each of these qualitative, speculative scores.”

Cons of using this prioritization framework

  • RICE scores don’t take dependencies into account. There are times when an initiative with a high RICE score needs to be deprioritized over something else, so product teams need to treat the score as an exercise, rather than the end-all, be-all answer to “What should we build next?”
  • Estimations will never be 100% accurate. RICE prioritization is simply an exercise in quantifying features in a way that takes into account the level of confidence teams have on their estimations.

3. 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.

Kano model - product prioritization framework


  • The Kano model questionnaire can teach teams not to overestimate excitement features and to stop underestimating must-haves.
  • It can help teams make better product decisions and market predictions for feature success 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.

4. 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.

story mapping - product prioritization framework


  • 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.

5. 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.

Moscow - product prioritization framework


  • 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.

6. 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.

opportunity scoring - product prioritization framework


  • 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.

7. 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:

  1. 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.
  1. Ask your participants (in this case, your customers) to write some potential features on sticky notes. These will be the leaves of your tree.

  2. 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.

product tree - product prioritization framework


  • 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.

8. 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.

cost of delay - product prioritization framework


  • 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.

9. 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:

  1. 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.

  2. 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.

  3. 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.

  4. 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.

Qualitative prioritization

Before settling for a prioritization framework, product teams need to quantify a number of qualitative values that will inform the direction of the product. This includes estimating feature value based on:

  • Product goals (strategic alignment)
  • The competitive landscape (feature competitive analysis)
  • The number of feature requests/customers with the same problem (customer demand)

Prioritizing features by strategic alignment

Regardless of which framework you use to prioritize your initiatives and features, there’s one dimension they should all be measured against: how much they contribute to the overall product strategy and vision. And the best way to do that—as well as bring visibility to the features and initiatives that will keep the product on track—is by ranking features along a strategy scorecard.

Let’s say your product is a financial management and budget planning application whose vision is to help everyone take charge of their finances in one place (like Mint). You’d then score your initiatives based on each goal that, once achieved, will push the product closer towards that vision.

So if the goals for the quarter revolve around improving accessibility, improving UX, and decreasing churn, you’d use a simple score to rank each feature idea based on how closely it pushes each of those goals forward. Like so:

product prioritization

By bringing the focus of the prioritization back to those goals, it removes any risk of prioritizing features based on the loudest stakeholder in the room or competitive pressure. Keeping the strategy front and center during the prioritization phase gives product teams the confidence that they’re building a valuable product that solves only the most relevant customer problems.

Prioritizing using a feature competitive analysis

When you look at how your competitors are (or aren’t) tackling a feature, you can get a sense of your their weaknesses and strengths. By seeing ranking features based on which competitor offers it and which doesn’t—and at what quality—product teams can find underserved needs they can then exploit and grow into.

product prioritization

Check out our in-depth guide to conducting a product feature competitive analysis here.

Prioritizing by customer demand

Customer demand is simply the number of times a feature has been requested by your users. These requests come in via support, CS, sales, product marketing and even social monitoring. While it’s definitely not a reliable way to prioritize features (strategy and vision should always come before customer demand), it’s a factor that can’t be ignored.

The number of times a feature is requested—as well as the customer insights gathered from qualitative user research methods like interviews, experiments and tests—can have a tectonic effect on product strategy. So it’s worth it to keep track of this information (i.e. the needs expressed by your users), especially in new products that are still looking for ways to stand out in a saturated market.

Wrapping up

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.

Try Roadmunk for free

14-day trial | No credit card required | Get started in minutes