Original post at Medium - Product Coalition - Four Methodologies That Can Help Your Product Team’s Prioritization Efforts

Selecting a prioritization methodology for your team is important. Using a shared approach to prioritization helps reduce the pressure your team faces when conducting this exercise while boosting the productivity of your team members.

In this article, let’s take a look at four methodologies that can help your team’s prioritization efforts.

Keys to Success

Prioritization is one of the most challenging activities your product managers go through. A prioritization methodology brings two essential elements:

• a shared vocabulary that your teams can use
• a logical reason for supporting the decisions made

However, there are a few criteria for a methodology to be successfully implemented.

First, all the stakeholders across your organization need to buy in. If key decision-makers are not aligned on the shared methodology, this will fail. Everyone needs to agree on the shared language and logical process.

Second, all the inputs to the methodology need to be backed by data, and any assumptions about the model need to be documented. Garbage in, garbage out. Your team's decision will only be as good as the information they have to work upon.

Now, let’s take a look at four prioritization methodologies that I’ve found helpful — both in B2C and B2B contexts. As with all frameworks, I believe you should feel free to tailor any of them to your organization’s needs and ways of working.

We will take a look at:

1. The MoSCoW method
2. The Kano model
3. The values vs. effort matrix
4. The RICE scoring

MoSCoW Method

This prioritization method was developed by Dai Clegg in 1994 for use in rapid application development. It was first used extensively with the dynamic systems development method from 2002. (Wikipedia — MoSCoW method)

The MoSCoW method helps your team understand what is important and what is not using four categories. These categories are organized in degrees of importance. This method provides a clear framework to communicate with various stakeholders about what your team is working on and why.

The four degrees of importance are:

• Must have: this is an absolute requirement or a mandatory ask from your customers, you cannot launch a product without it, it would be a dealbreaker.
• Should have: it would be better to include this ask as it will have a high positive impact on your customers, but it wouldn’t be the end of the world if it’s left out initially.
• Could have: this is nice to have with a positive although small impact, it is typically considered optional and a good item to add if your capacity allows it.
• Won’t have: this will not be built as it has little to no value for your customers, or it is not aligned with your strategy and would do more harm to add it than anything else.

Your team should organize the backlog items into these four categories and then start allocating the capacity by the degree of importance (ignoring the last one).

Kano Model

The Kano model is a theory for product development and customer satisfaction developed in the 1980s by Professor Noriaki Kano, which classifies customer preferences into categories. (Wikipedia — Kano model)

The model focuses on features that fall into buckets based on the quality aspect of a feature or innovation. We will look at three main categories: expected, performance, and delighters.

Your product team can categorize items by surveying customers. The Kano model recommends capturing feedback by answering two questions for each feature. One question is formulated in a positive way (“how would you feel if the product had [this feature]?”) and the other is formulated in a negative way (“how would you feel if the product did not have [this feature]?”).

Based on the score each feature receives on these two dimensions, we can group them into the following categories*:

• Delighters: a feature or innovation perceived as going above and beyond expectations and not yet well fulfilled by any product. This feature would act as a differentiator from the competition.
• Performance: investing in this feature will yield a positive response from customers and vice-versa failing to satisfy this expectation will result in a negative impact. Also called “one-dimensional” qualities, this feature is directly tied to the performance of your product — the more the better.
• Expected: this feature is the minimum expected by customers to solve their problems and failing to fulfill this need will result in a lot of dissatisfaction. This feature is part of the “must have” threshold and your product will be considered useless otherwise.

The Kano model also provides a temporality to features that are worth keeping in mind: over time, delighters will become another expected feature. This results from broader adoption of the innovation by customers and its replication by competitors.

* I’m simplifying the model here and Kano’s theory organized customer satisfaction into five categories instead.

Value vs. Effort Matrix

This model originates from the lean methodology and positions features in a value vs. effort matrix. The approach encourages your team to evaluate each feature against two dimensions.

How much value will this feature bring? This can be in terms of potential new revenue, increased customer satisfaction, or impact on your goals.

How much effort will this feature take to launch? This can be in terms of pure cost, build time, or complexity to assess the requirement.

Features can then be plotted in a 2 x 2 matrix based on their score against each dimension. The resulting matrix has four quadrants that qualify the features as either:

• Quick wins: these are the features that produce high customer value for minimal effort.
• Big bets: these are the strategic initiatives that requires usually long-term commitments but can yield both high values for customers and differentiation from competitors.
• Maybes: these features will result in small but incremental value at low effort — they are good to fill up the remaining capacity.
• Time sinks: these features require a lot of effort to be launched and render very minimal value — they must be avoided as much as possible.

You will likely come up with a mix of features falling into these four quadrants. Your team’s capacity should be allocated toward features with for instance 60% coming from quick wins, 30% from big bets, and 10% from maybes.

RICE Scoring

Messaging-software maker Intercom developed the RICE roadmap prioritization model to improve its own internal decision-making processes. (ProductPlan)

Intercom’s RICE model assesses features along four factors: reach, impact, confidence, and effort. Your team should evaluate each factor, assign it a value, compute and rank the RICE score with the highest first, and then go down the list. This scoring should be backed by data as much as possible.

The model defines the four factors as follows:

• Reach: measures how many customers will be impacted by the feature.
• Impact: estimates how the customers will be impacted (positively). This factor also ties into your product strategy and goals.
• Confidence: is expressed in the form of a percentage and evaluates your team’s confidence in the data, in the assumptions, and in the model that backs the other factors.
• Effort: measures the amount of work required across all the teams to build and launch the feature.

The RICE score is obtained by multiplying the reach, the impact, and the confidence and then dividing the result by the effort.

Out of the four methodologies we’ve looked at in this article, the RICE model is the most quantitative approach and therefore is adequate for teams that rely on — and have access to — good data.

Wrap up

I believe that defining and using a clear methodology for prioritization is vital for the success of a product organization. Selecting a methodology allows your team to define a shared vocabulary and logic that can be used to communicate with your stakeholders.

We’ve looked at four approaches that help organize your features and backlog items into various categories and dimensions.

It should be your team’s decision and preference to pick the most suitable approach. Methodologies can also be combined and adapted to what resonates the most with your organization, your stakeholders, and mostly your customers.

As with everything in product management, you should test and iterate until you find something that works!