9 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 your customer feedback and product strategy.

Here at Roadmunk, we understand this. That’s why we offer two built-in prioritization frameworks in our feedback and idea management suite: RICE and value vs. effort.

We’ll guide you through those two frameworks, plus:

• KANO
• Story mapping
• The MoSCoW method
• Opportunity scoring
• Product tree
• Cost of delay
• Buy a feature

1. RICE

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 any given goal.

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:

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.

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

Pros of using the RICE method

• 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.
• It lessens the influence that inherent biases have on prioritization. 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 the RICE method

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

2. Value vs. Effort

This simple approach to prioritization involves taking your list of features and initiatives and quantifying them using value and effort scores.

With this method, it’s important to keep in mind that the final scores are just 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? Can we feasibly build it with the resources we have?”

Scoring methods like value vs. effort 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 looks like in Roadmunk:

(Pssst! Value vs. effort is one of two prioritization templates available in Roadmunk. You can also create your own custom prioritization criteria and use any factors that are relevant to your company.)

Pros of using value vs. effort

• 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 using value vs. effort

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

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.

Pros of using this 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.

Cons of using this prioritization framework:

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

Pros of using this 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.

Cons of using this prioritization framework:

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

Pros of using this 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.

Cons of using this prioritization framework:

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

Pros of using this 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.

Cons of using this prioritization framework

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

2. Ask your participants (in this case, your customers) to write some potential features on sticky notes. These will be the leaves of your tree.

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

Pros of using this 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.

Cons of using this prioritization framework:

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

Pros of using this 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.

Cons of using this prioritization framework:

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

Pros of using the buy a feature method:

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

Cons of using the buy a feature method:

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

Wrapping up

Product prioritization methods shouldn’t replace human input in decision-making. A good framework is a way 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.

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 actionable results and information that can help you drive your 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” behind a product strategy. Having a standardized prioritization process is only one piece of the strategic puzzle. There are many moving pieces involved in making sure your strategy is driven by solving the most impactful customer problems—as well communicating that strategy across the entire organization.

That’s where an end-to-end roadmapping tool like Roadmunk can help. Using our tool, you can:

• Capture, manage and analyze customer feedback in one organized place
• Create a backlog of customer-validated product ideas
• Systematically surface high-impact ideas using built-in prioritization templates
• Commit to ideas by promoting them to your roadmaps