Due to having limited time and resources, every product manager must make difficult trade-off decisions when prioritizing their roadmap. Inspiration for new product features may come from a myriad of sources and as the list grows, it gets increasingly difficult to separate the best ideas from the rest. Fortunately, there are several product prioritization frameworks that enable product managers to create customer love and achieve the best business outcomes.
In this article, we’ll focus on the RICE, MoAR, MoSCow, and Kano product prioritization frameworks with examples of how to use each.
The RICE Model
The RICE model is a simple prioritization model created by the team at Intercom that has since been adopted by many product teams. It’s calculated as (Reach x Impact x Confidence)/ Effort.
When you prioritize your roadmap with RICE, the key is to be consistent across the portfolio or against goals.
Let’s break down the different components of the RICE prioritization model:
“Reach” denotes how many people you believe your initiative will touch within a given timeframe of your choice.
When choosing the Reach value, teams may use the absolute value of x number of customers, or use a score range between 1-100. We recommend using a 1-100 total user base.
“Impact” represents some sort of goal to be achieved by this initiative. Initiatives can be anything, including something quantitative like conversions or qualitative like customer satisfaction.
When choosing the Impact score, use 0-3 to denote the amount. This will represent no impact, low impact, medium impact, and high impact.
“Confidence” is chosen based on the assumptions of the idea. It demonstrates whether or not you believe that it will deliver on the Reach and Impact. That way if you have data to support the Reach score you predicted, but no data to support the Impact score, you can reflect this in your Confidence score.
A Confidence score ranges from 1% to 100%. A good practice is to break it down into 50%, 80%, and 100% to represent low, medium, and high confidence. That way you do not have to spend too much time deciding a Confidence score.
When you prioritize your roadmap, there are going to be costs and benefits. As the numerator of the RICE model, “Reach”, “Impact”, and “Confidence” create an idea of your benefits. As the denominator of the RICE model, “Effort” creates an idea of your costs or your T-shirt size.
“Effort” is often measured in “person-months” or the number of months it will take for one person to complete. So if a project will take 1-2 weeks of planning and 2-3 weeks of engineering, we can score it in 2 person-months. This estimate will likely be imprecise, but we recommend keeping the numbers whole for ease of use.
Now Let’s Take a Look at an Example:
If Project 1 has Reach = 50, Impact = 3, Confidence = 80%, and Effort = 12, then the RICE score is 10:
(Reach x Impact x Confidence)/ Effort
(50 * 3 * 80%)/ 12 = 10
The MoAR Model
The MoAR model stands for “Metrics over Available Resources.” Among the different product prioritization frameworks, this one is unique to responsive product portfolio management, replacing the traditional ROI model.
When you prioritize your roadmap with MoAR, you’re able to directly map to company goals and strategies while also accounting for any urgent resourcing needs.
Let’s Take a Closer Look at What MoAR Means:
What you choose for “Metrics” can vary based on the initiative. Popular “Metrics” are often measures of product benefits such as user growth, referral rate, retention, or net promoter score. These are good ways to gauge future monetary returns and, if your company has adopted goal frameworks like OKRs, you can align these goals with your roadmapping.
“Over Available Resources” refers to the number of resources readily available or the effort needed. It takes scarcity into consideration, therefore you can adjust as needed.
How to Calculate MoAR
MoAR is calculated as MoAR = Benefit / Effort
In this case, “Benefit” demonstrates how much a given initiative contributes towards your organization’s strategic objectives. When using MoAR correctly, these initiatives will be mapped to an objective. Therefore, the Benefit score will prioritize all ideas mapped to that same objective.
When choosing a “Benefit” score, we recommend using a value between 1% to 100%.
Similar to “Effort” in the RICE model, here it refers to an initiative’s cost in terms of resources. Effort is most commonly determined by the estimate of weeks needed to complete an initiative by the resource chosen.
Now, Let’s Take a Look at an Example:
Let’s say you are trying to prioritize a number of features towards a specific goal.
Feature A is expected to contribute to 40% of your goal and requires 8 weeks of front-end resources. The MoAR for Feature A is 40/8 = 5.
Feature B is expected to contribute to 10% of your goal and requires 4 weeks of front-end resources. The MoAR for Feature B is 10/4 = 2.5.
Feature C is expected to contribute to 20% of your goal and requires 5 weeks of front-end resources. The MoAR for Feature C is 20/5=4.
You would then compare these features for your goal and prioritize based on your MoAR scores.
Feature A > Feature C > Feature B. Therefore, you would cut Feature B even though it takes the least amount of resources. You can then address that Feature A and C only make up 60% of your goal so you can either reduce the target by 40% or create a new feature to cover the gaps.
When you prioritize your roadmap with the MoAR framework, you’re able to be responsive and proactive in addressing gaps.
Recommended for you: Effective Feature Prioritization with Product Portfolio Management
The MoSCoW Model
The MoSCoW model is another way you could prioritize your roadmap, which primarily focuses on ranking the importance of requirements. Created by Dai Clegg at Oracle, MoSCoW is an acronym for four categories: “Must-Have,” “Should-Have,” Could-Have” and “Won’t-Have” (at least not in the short term) or alternatively, “Wish-to-Have.”
To use the framework, it’s first important to be clear on the team’s objectives and factors for prioritization. You’ll need to come up with a way to settle any disputes you may have about which category is best for each feature or initiative.
Let’s Look Closer at the Four MoSCoW Categories:
Must-Have: These are the product needs that the team absolutely must work on since they are critical to the product’s success.
Should-Have: These initiatives are not critical, yet would provide significant business and customer value.
Could-Have: Once the “Must-Haves” and “Should-Haves” are taken care of, these are the initiatives to prioritize next that would add value if they existed, but aren’t absolutely needed.
Won’t-Have: These are the initiatives that the team forgoes prioritizing in the current timeframe or in the future. Including items in this category helps to prevent scope creep and keep the team focused.
Let’s say a team is working on an MVP for a new social media app with a very limited budget and timeline. Here is an example of how it might prioritize its proposed features:
The MoSCoW model can be applied by any team, for example, the QA team could use it to decide which test cases to prioritize in the next sprint. However, there are some potential drawbacks to just using MoSCoW for product prioritization. For instance, it might be susceptible to bias and scoring could be imprecise due to a lack of the proper inputs to make the right decisions.
The Kano Model
Where the MoSCoW model focuses on the degree to which features are necessary, Kano is one of the product prioritization frameworks emphasizing features that maximize customer satisfaction and delight while weighing their costs. It argues that more is not always better. It also recognizes that some features might even lead to negative customer outcomes. On the other hand, it points out that, over time, features that were once considered a “nice-to-have” become a given.
You can use the Kano model to categorize features based on their predicted customer reaction. For best results, make sure to do some customer research ahead of time in order to bring data to the decision-making process.
Categories in Kano
Excitement: Features in this category are those that contribute to the “wow” factor for customers. Using a hotel as an example, this could be offering guests complimentary tours and transportation.
Performance: Also known as “satisfiers,” these features are noticed and appreciated by customers. Returning to the hotel example, offering free beverages in the room is an added benefit for the customer, but not necessarily expected.
Basic: These are the features that your product needs in order to be competitive yet are so fundamental that customers wouldn’t think to request them. For example, hotel guests would expect to receive a room that has a bed with clean sheets. However, if a hotel fails to provide this feature, it would soon be out of business!
Indifferent: These are the features that most customers would not have a strong preference for or against. In a hotel, this might be having stairwells in addition to elevators. While most customers might be satisfied with just using the elevator, the hotel owner needs to make sure to have adequate stairwell access in order to comply with fire safety standards.
Dissatisfaction: These features, if implemented, would cause customers to be less satisfied with the product. For example, a hotel that has a clock tower, while perhaps architecturally pleasing, might wake up customers in the night and worsen their experience.
To put this model into practice, first formulate a simple customer questionnaire that consists of two basic questions regarding each feature:
- How would you feel if the product had X feature?
- How would you feel if the product lacked X feature?
For the answer options, you can use a Likert scale with five responses that correspond to the five categories. Based on their answers, you should be able to categorize the feature ideas into the different categories of customer delight.
Product Prioritization Frameworks for Better Decisions
While there are several useful prioritization and product management frameworks, you should now be able to use any of these four to inform your product roadmap.
For outcome-driven teams, we recommend starting with MoAR since it directly addresses how to prioritize your roadmap by objectives.
Remember that for every ideal way, there is an equally wrong way to prioritize your product. Evaluate how your team is making decisions today and be honest if some things need to change. Is everyone’s opinion heard or is it only the most vocal team member’s? Is data involved or are you only working off a hunch?