8 Product Roadmap Prioritization Frameworks You Should Consider

The foundation of product prioritization is talking to your customers.

But while you should always get your users’ feedback, what happens when you’ve got dozens of requests of similar importance going on at the same time? What about when a popular feature request is just too difficult to deliver right now? What about those big bets even customers don't see?

You’ll need to introduce a product roadmap prioritization model.

‍Below, we share the best product prioritization frameworks you should consider and stick to based on the needs of your company and users.

{{resources-component-1}}

RICE (Reach, Impact, Confidence, and Effort)

The Rice Scoring Model is a prioritization framework that helps you evaluate the relative importance of different projects, initiatives, or investments based on a set of criteria. It’s undoubtedly the most popular model is the SaaS space and we also use it at LaunchNotes to guide our own roadmap.

How to use it

This prioritization model allows you to gather input from multiple stakeholders and quickly run an analysis that shows what projects are most important to different people within your organization.

The model has four steps:

1. Identify which features are most important to customers.
2. Fidn out which features are least important to customers (i.e., "nice to haves").
3. Score each feature based on its importance to customers using a 5-point scale (1 = not important, 2 = somewhat important, 3 = important, 4 = very important, 5 = critical).
4. Prioritize features according to their scores and compare them against one another.

MoAR (Metric over Available Resources)

Metric over Available Resources (MOAR) is a prioritization method that helps you identify the most important items in the backlog. It’s similar to the well-known MoSCoW method, but instead of just asking whether something is Must Have or Should Have, it asks how valuable each feature will be and how much it costs to build.

How to use it

First, assign each feature on your backlog with a value between 1 and 5. The higher the number, the more valuable it is. This can be based on market research or just your gut feeling — whatever works best for your team.

Next, assign each feature with an amount of effort required to develop it — this is where you get into specifics about the cost and time required for each feature. You can come up with these estimates yourself or ask someone who knows more about development than you do (like an engineer or product manager).

Finally, compare all of the features against one another using their values and costs so that you can determine which ones are most important to build first (and therefore make sure they get built) and which ones should be put on hold until later.

MoSCoW (must, should, could, and would)

MoSCoW is a prioritization technique product managers use to make decisions on what to work on next by focusing on the most important tasks first. 

The MoSCoW method can be used by teams to help determine which features are most important and how much time should be spent working on each one. It also helps identify which tasks can be deferred until later in the project or even removed from consideration altogether.

How to use it

Consider the following elements when prioritizing your roadmap:

• Must Have: These are must-have features for the product. Without them, the product will not meet its business objectives. They’re critical for the success of the product.

• Should Have: These are important features that the product manager believes should be built into the product but they aren't essential to its success.

• Could Have: These are nice-to-have features that would add value to the product but don't necessarily need to be built right away or might not be necessary at all if other priorities take precedence.

• Would Like To Have: These are wish-list items that may not make sense at this stage in development but could be added later if time allows.

Kano

Kano Model is a customer-centric approach to product prioritization. It helps product managers and marketers in understanding the needs of customers, prioritize them, and deliver them.

How to use it

The Kano model was first introduced by Professor Noriaki Kano in 1984. He identified three levels of customer satisfaction you should also focus on:

• Basic needs: These are basic requirements that must be met in order for the customer to be satisfied with a product. For example, if you get a project management tool and they don’t offer basic task management features, you’ll be quite unhappy.

• Delighters: These are features or capabilities that are not essential to meeting the basic need but they do make it better than expected. For example, if were to start using a tool’s task management features, you’re going to be very happy with any advanced features like task prioritization or time tracking as a lot of tools don’t offer this.

• Exciters: These are features or capabilities that go beyond what is expected by customers and cause excitement or delight them (excite). For example, if your favorite project management tool started offering a CRM module, this would be an exciter for customers because it goes beyond their expectations of a classic project management app.

Weighted scoring

Weighted scoring is a method of prioritizing features and bugs based on the importance of each feature to the person who requested it. This allows you to assign greater importance to requests from your most active users, ensuring that you're building features that are more likely to drive more usage.

Weighted scoring can be used in conjunction with other methods for product prioritization, such as the user experience lifecycle or value-based ranking. It can also be used for bug prioritization if you're working on a new feature rather than an existing one.

How to use it

If you have a product with 10 features listed, and you want to score them from 1 to 10, you can simply multiply all your scores by 10, then add them up. This will give you an idea of how well your product stacks up against other products in the market.

There are two main methods for doing this:

Adding up scores for each feature: This is when you assign a value to each feature in your product and then add them together. This method tends to favor smaller features because they tend to get higher scores than larger ones. For example, if a small feature had a score of 8 while another larger one had 2, the smaller feature would have more weight in its final result compared to the larger one.

Weighting each score by importance: In this method, each feature gets assigned a weight based on how important it is as compared to other features or requirements in the product backlog. For example, if there are 10 features listed out of which 5 are high priority and 5 are low priority.

Story mapping

Story mapping is a new technique for product prioritization. It was developed by Jeff Patton, a consultant and author of User Story Mapping.

The idea behind story mapping is that you use cards to represent features, and then arrange them on a board. Your board can be physical or virtual, but it should have room for enough cards to accommodate your entire roadmap.

There are two main benefits to using story maps:

• It helps you visualize your product roadmap, which makes it easier for stakeholders to understand the big picture. It also makes it easier for you to see where there are gaps in your product vision, so you can fill them with new stories before they become problems.
• It helps prioritize work by focusing on user needs first instead of business needs first (which often leads to short-term thinking).

How to use it

Here's how it works:

1. Write down your product backlog in the center of a whiteboard or paper. This can be as simple as listing out different features and tasks that need to be completed within your product. If you've already been using story mapping, this step may be familiar to you.

2. Ask each member of the team to write down their top three most important features on sticky notes and place them on the whiteboard around the backlog list. You'll want to include both big-picture features (e.g. "integrate with Slack") as well as smaller ones ("add another field for roles"). These are your high-priority user stories.

3. Next, ask each person to identify their top three priorities among their high-priority stories and put them next to each other on the board in a vertical line below their original sticky note. Do this for every person on your team until all of their high-priority stories have been grouped by priority level under one of their own sticky notes.

Once you've determined which features have the highest weighted scores, it's easy to prioritize them for development work and other activities. You can also use weighted scoring to ensure that everyone on your team is focused on what's most important for the business at hand.

Decision trees

Decision trees are a way of representing the decision-making process. They can be used to help you identify and prioritize the different options that you have in your product.

Decision trees are helpful tools for managing a wide range of situations, whether it be prioritizing your to-do list, identifying new business opportunities, or making strategic decisions about your company.

When you use a decision tree to make a decision, you're using information from previous steps in the process to make the new decision. For example, if you're trying to decide which feature should be added next in your app, you might start with one step on the right side of your decision tree and then go backwards towards the left side as you move through each step until you reach the root node at the bottom of the tree (which represents your original problem).

How to use it

Start by figuring out what problem you're trying to solve.

Then, decide on which outcome you're trying to achieve (sell more features, sell better features). Choose which features among these are relevant to achieving that outcome.

Pick a threshold value for each feature (e.g. 0.50). Then sort features by their values in descending order. This will give you your decision tree.

Value vs. effort 

Value and effort are two different concepts. Value is the perceived benefit of a feature, while effort is how much time it took to build the feature, or how much it cost.

For example, you might want to prioritize features that have high value for your users (e.g. features that help users do their jobs better). However, you might not be able to determine exactly how much value a certain feature will have for your users, so you need to estimate its value based on past experience with similar features and what other people report about similar features in their own applications.

Effort refers to how much work was involved in creating or implementing a feature or set of features. This can include tasks such as writing code, testing it, and making sure it works properly when deployed to production.

How to use it

There are two main ways to use this model:

1. To prioritize features by value, or by how much they'll save you time, money, or resources (like time at the end of the day).

2. To prioritize features by effort, or by how difficult they are to implement and maintain (for example, if the feature is complex and requires a lot of development resources).

In practice, you may want to use both perspectives at once. For instance: if one of your top priorities is to reduce wasted effort in order to free up more time for other important work (e.g. new features), then that would be worth prioritizing over other things like reducing costs or improving customer satisfaction.

How to choose the product roadmap prioritization framework that works best for you

One of the first things to consider is how long your product roadmap will be. If it’s short and simple, then a simple prioritization framework may be all you need. If it’s long and complex, then you should probably use a more advanced framework that helps to manage complexity and prioritize features.

Another question to ask yourself: “What kind of features am I building?” If you’re building a single feature or two, then a simple prioritization framework will work just fine. If you’re working on many features at once, then an advanced framework might be more appropriate.

Most companies stick with a single prioritization method to organize their roadmap and feature development. However, besides relying on a core framework, you’ll want to consider additional prioritization frameworks to cater to different development stages, departments, and priorities.