Product Prioritization Frameworks: Optimize Decision-Making

Have you been constantly chipping away at customer interviews to understand market needs, gathering insights on competitor features, and analyzing user behavior data?

Got a big old list of product features to plan, develop and release?

You can’t do everything at once, and biting off more than you can chew is a recipe for a product riddled with half-developed features that never get adopted.

You also want to avoid the product being one of the 40% introduced each year that fail.

So, where to start?

You need a product prioritization framework to determine what to work on first and what to leave for later…

When it comes to product management prioritization frameworks, you’ve got a few options to choose from, and we’re going to dive into each of them here. 

In this article, we’ll explore nine of the most helpful product prioritization frameworks for determining what features and functions to build out first and which are “nice to haves” that can bear to wait a little.

What are product prioritization frameworks? 

Product prioritization frameworks help you and your product team determine what to build next.

You’ve probably got a long list of product features you’d like to build out based on your:

• Competitive research and monitoring
• Conversations with customers and sales leads
• Your long-term product vision

You can’t build everything at once, so a product prioritization framework helps decide what should come first, what should come next, and so on.

Why use product prioritization frameworks? 

Having established that you can’t do everything at once (don’t we know it), the important question is:

What should we do first?

This can quickly devolve into a battle of interests. 

The CEO has their idea of where the product should go, sales reps want the product team to build features that competitors who are preventing them from winning deals have, and customer success has their wishlist that would help them reduce customer churn.

A formal framework for determining what feature to build next helps solve this debate.

It's even more important when multiple teams are working on different products. 

Using the same prioritization framework helps align all teams toward the same business goal and make prioritization decisions based on the same values.

Our 9 favorite product prioritization frameworks

Let’s take a look at the nine most important product prioritization frameworks for product managers.

1. ICE 

‍

‍

ICE helps teams prioritize products based on three facets:

1. I - Impact. The potential impact of a given feature on the product’s overall goals.
2. C - Confidence. The level of certainty the product team has in their ability to assess the impact.
3. E - Ease. How easy it is to complete, in terms of effort or resources required.

Here’s how it works:

Imagine you’re building a new mobile app for a retailer.

You’ve got a few features in mind that you need to put in order of priority:

• In-app messaging
• Loyalty program
• Personalized recommendations

First, you assess the impact of each feature on important metrics like revenue generation. For instance, what is the potential for new revenue generation from a loyalty program vs. personalized recommendations?

Next, you evaluate your level of confidence in that decision. If you have solid data and a lot of experience launching similar features, your confidence score might be high.

Finally, you can estimate the resources and effort required for each feature.

You then rank the features from highest to lowest using the same scoring method for each feature (for example, a score out of 10 for each category).

ICE is a great framework in that it's super simple and easy to implement. The main drawback is there is a lot of subjectivity involved. The confidence factor attempts to control for that, but this is still a subjective assessment, so it's kind of moot.

2. RICE 

The RICE framework is ICE but with an added factor: Reach.

Reach speaks to the number of customers who the implementation of that feature will impact.

Say you have two features that would otherwise have the same ICE score. One will impact 10,000 users, and the other will impact only 2,000. 

The prior would have a higher RICE score (because it has a great reach) and should, therefore, be prioritized.

The RICE framework is still burdened by the subjectivity problem that ICE has, but it at least adds one more layer of quantitative data, which makes it a slightly more reliable and accurate framework.

3. Kano model 

‍

‍

The Kano model product prioritization framework, developed by Professor Noriaki Kano, looks at customer preferences across five categories:

1. Basic: Must-have essential features that customers consider standard (stability, for example).
2. Performance: Features that have a demonstrable direct correlation with customer satisfaction (e.g., increased storage capacity)
3. Excitement: Unexpected features that can delight customers (like unique design elements)
4. Indifferent: Features that customers don’t care about (different from basic features in that they also don’t care if the feature isn’t present)
5. Reverse: Features that negatively impact customer experience (for example, excessive notifications or intrusive ads).

The Kano model involves categorizing features into one of the above boxes, building features in the order of priority listed above (start with basic features considered necessary, then progress to performance functions, etc.).

This is a simple model for aligning feature development with customer satisfaction. It's a little too basic to be super practical, however. Once you’ve built all the Basic features, for example, how do you decide how to prioritize between various Performance features? 

4. Value vs. Effort 

The Value vs. Effort framework is pretty straightforward.

It asks, “How hard is this to build, and what will we get out of it?”

Then, you plot the various potential features on a Value vs. Effort matrix. Value is on the y-axis, and effort is on the x-axis.

‍

‍

High-value, low-effort features should be built first, followed by medium-value, low-effort (or high-value medium-effort) features, and so on.

This is a great framework for focusing on return on investment and can help you build a ton of easy-to-implement but valuable features quickly rather than burdening your team with high-effort builds.

Of course, these assessments are subjective, which can create inconsistencies between teams.

5. MoSCoW method 

‍

‍

The MoSCoW method comes from Agile project marketing management. It breaks potential features into four categories:

1. M - Must have. Features that you consider to be essential to meet MVP (minimum viable product) criteria.
2. S - Should have. Your product won’t necessarily be unusable without these features, but they might be common industry standards that are highly important to a given use case.
3. C - Could have. These features are desirable, but they aren’t necessary.
4. W - Won’t have. Features that would actually have a negative impact (like ads) or that are unable to be implemented within the given scope.

Say you’re developing a new mobile banking app.

You might determine, for instance, that funds transfer is a must feature, bill payments are a Should, investment tracking is a Could, and crypto holding is a Won’t have for now.

The MoSCoW method is especially effective when planning out an initial product launch. 

Its fairly simple to apply, and though its effectiveness can be hampered by the use of subjective assessments, this can be improved through customer feedback, market research, and in-depth customer interviews.

6. Product tree 

The product tree is a visual tool. It's a hierarchical structure that looks something like a tree.

The various components of the tree represent levels of importance for given features:

• Root. This represents the broad vision of the product, to which all features should align.
• Trunk. This represents the core features that are essential for achieving that goal.
• Branches. These represent various categories or aspects of the product. Sub-branches can stem from these main branches for specific features or user stories.
• Leaves. These represent individual features or ideals. They are the smallest units of functionality that contribute to the broad vision represented by the root.

The product tree framework is unique in that it is highly visual, which can be a great tool for communication and inter-team alignment.

While broadly speaking, one can prioritize feature development based on that framework (trunk features first, for example), it doesn't really provide enough detail to prioritize beyond that. For example, it doesn’t offer a framework for deciding how to prioritize between different branches.

7. User story mapping 

‍

‍

User story mapping is another technique that is popular in the Agile product development world.

It's designed to represent the user’s journey through a product, so you can prioritize features based on needs.

A user story is a brief, user-centric description of a given feature from the user’s perspective.

It usually looks like this:

“As a [user type], I want [goal] so that [reason].”

The mapping part of the framework is about representing the sequence of journey steps across the horizontal axis and the importance or priority of these across the vertical axis.

You then focus on the highest-priority user stories, building the features that relate to these stories first.

This is a good framework for remaining customer-centric and for visualizing product prioritization.

It's one of the more complex approaches, however, so it might be overkill for simpler projects.

8. Cost of delay 

The cost of delay framework is a unique one that, rather than examining the benefits of building a feature, looks at the consequences of not doing so.

It basically looks to quantify the cost of delaying the delivery of that feature (which is what you’d be doing if you choose to build another feature instead).

In determining the cost of delay for a given feature, you’ll review facets like:

• Lost revenue
• Missed market opportunities
• Increased risk exposure
• Potential customer dissatisfaction

All of these need to be put into dollar terms, which can, of course, be a little subjective. You’ll also want to consider the impact of time, measuring the cost of delay per week so that you can assess opportunities effectively alongside each other.

The cost of delay framework is a great option for those looking for more financial-based, quantitative alternatives to some of the highly-qualitative options listed here. 

9. Weighted scoring prioritization 

The weighted opportunity scoring prioritization framework sets out predefined criteria or factors used to evaluate the features you’ll score and prioritize.

For example, you might set criteria such as customer impact, feasibility, importance to business goals, etc. 

You’ll score features on each of these criteria (for example, out of 5 or out of 10).

The trick here is that each criterion receives a different weighting. For example, while customer impact might get a 1x weighting, feasibility might get a 2x weighting (since you’re low on manpower, say).

Consider the impact of this on two features, scoring those two criteria out of 10:

1. Feature 1: Customer impact 5, Feasibility 8
2. Feature 2: Customer impact 8, Feasibility 5

Without a weighting factor, both would be worth 13.

But with the weighting as applied above, Feature 1 is worth 21, while Feature 2 is only worth 18 (so Feature 1 should be built first).

This is a super structured, systematic, and qualitative framework that uniquely integrates the idea that more attention or weight should be given to certain factors over others.

Critical to using this framework is careful research, analysis, and construction of the criteria, weighting, and scoring methodology (which can be kind of time-consuming). 

While each of the prioritization frameworks for product managers discussed here is useful and has a place in a given context, what’s most critical is that the product prioritization framework you choose can be tied to revenue.

Using revenue opportunities to drive product prioritization 

Each of the nine product management prioritization frameworks we’ve discussed above has its merits, and any one of them might be the best fit for your organization.

Our take on the whole thing is that your product roadmap should be revenue-driven. Ask yourself: what’s going to create the biggest dollar impact when you go-to-market?

That is, the overarching goal of driving up revenue (whether through churn reduction or greater new client acquisition) should steer the product development process.

We’re so bullish on this idea that we’ve gone as far as building our own AI-powered revenue-based roadmapping functionality. 

Sound like what you’re after? Learn more here: Introducing Revenue-Based Roadmapping.