It's straightforward: the most important things come first. But the water becomes murky when figuring which features are more important than other features.

This post lists some commonly used prioritization frameworks and how to implement them. Click to skip into the main content:

RICE

Value vs. Effort

The Kano Model

The MoSCoW Method

Product Tree

Cost of Delay

RICE

What is RICE?

In the RICE framework, features are prioritized according to reach, impact, confidence, and effort. It was first developed by the American software company, Intercom.

Reach: Estimate how many users can benefit from a feature over a given period. For example, 50 customers requested a particular feature. You can assume that these 50 customers represent many more who want the feature but did not request it.

Let's say 150 customers will use the feature each month. You can also assume that the feature will increase your user base by 20 each month. In one quarter, the feature can impact 230 users.

Impact: How much will a feature increase customer retention?

How much will it increase conversions or buy-ins?

How much will it increase customer delight?

Impact relies mostly on intuition. To measure impact, team members can assign a scale of 1 to 3, three being the highest.

Confidence: How sure are you about the impact and reach of a proposed feature? Do you have data to back it up?

Confidence weighs in between empirical data and gut feeling. You can assign a number or percentage point to measure how confident you are that something is based on data.

For example, Intercom uses the following percentage system:

• 100% = sufficient data proves that the estimated impact and reach are accurate.
• 80% = there is some data but it is not sufficient enough to inspire full confidence.
• 50% = not enough data to build a strong hypothesis on.

Effort: How many team members will need to work on a proposed feature? How much time will it take them? You can measure effort in human hours. Add all the human hours that everyone has to put in to make the product.

When to use RICE

Use the RICE framework to:

• Make a thorough evaluation of proposed features.

• Decide between two equally important features.

How to implement RICE

Multiply reach, impact, and confidence. Divide their product by effort.

The higher scored features get priority in development.

Pros of the Rice Framework

It evaluates ideas more thoroughly.

It prioritizes customers.

It is especially useful when working with apps that contain massive feature sets.

Cons of the Rice Framework

It is time-consuming because you need to measure ideas against four different metrics.

The data for reach and impact are not always available.

Value Vs. Effort

What is Value vs. Effort?

In Value vs. Effort, a feature is prioritized based on its projected business value and the resources required to implement it.

Effort refers to the number of people, technological resources, hours, and added investment.

Unlike RICE, Value vs. Effort is a lean prioritization framework. With only two metrics, it helps teams prioritize features quickly.

How to categorize features

There are four ways to categorize features when using this framework:

Quick wins. Big value, low effort, and resources required to build.

Big bets. Great value, massive resources required to build.

Maybes. Low value but easy to implement. Can be done at a later time.

Time sink. Low value and difficult to implement. Can be skipped.

When to use Value vs. Effort

Use the Value vs. Effort framework to:

• Prioritize features in a minimum viable product (MVP).
• Prioritize features early in the development stage of a product.
• Identify low-hanging opportunities.
• Trim down tasks to meet deadlines.
• Manage small backlogs.
• Prioritize product feedback.

How to implement Value vs. Effort

1. Establish a goal so that the valuing of a feature can be constrained within the goal. Some of the goals can be:

2. Increase revenue.

3. Maximize retention or decrease churn rates.

4. Acquire new customers.

5. Score a feature's value:

   Minimal = 1

   Low = 5

   Medium = 8

   High = 13

   Super high = 20

3. Score a feature's effort based on the required resources using the same scale (1, 5, 8, 13, and 20).

4. Divide value by effort.

5. Prioritize products based on the score. Lower-scored features get priority because they bring the highest value compared to the effort required.

Alternatively, you can use a matrix to categorize tasks into quick wins, big bets, maybes, and time sinks.

Pros of the Value vs. Effort Framework

Prioritization can be done quickly.

The metrics are easy to customize. You can replace "effort" with risks, time, costs, or feasibility.

Cons of the Value vs. Effort Framework

The scoring is highly subjective since there are no scoring guidelines in place.

The scope of the effort variable is too broad. It needs to be broken down further before a score can be assigned to it.

It does not work well in projects the require accurate calculation.

The Kano Model

What is the Kano Model?

The Kano Model was proposed by Noriaki Kano, a Japanese researcher who published studies on customer satisfaction.

This model describes the connection between product features and the customers' level of satisfaction.

The Kano Model is used to group features according to these categories: basic, performance, attractive, and indifferent.

Basic

These are must-have features in an app. Examples of features in this category are: login, password reset, push notifications (for mobile apps), security, and privacy.

Performance

These features determine how well an app works. If an app does not meet performance expectations, it can directly cause dissatisfaction to users.

Some examples of performance features are speed, responsiveness to screen sizes, battery consumption, and memory usage.

Attractive

Attractive features are an app's unique selling propositions. End-users do not expect an app to have these features. But if an app does, it increases customer satisfaction. It also increases the likelihood that someone will pay for an app. This is why many software products put attractive features behind a paywall.

Examples of attractive features are offline use, unlimited downloads, or the ability to see street view images on a map app.

Over time, attractive features become more common. They then become features that customers expect. For example, real-time online collaboration on Google Docs was an attractive feature the first time it was introduced. Now, customers expect online document processors to have a collaboration feature.

When to use the Kano Model

• When customer opinion is easy to access.
• Use it to quickly identify the features that customers will want.

How to Implement the Kano Model

There are two axes in a Kano Framework. The intersection of these axes determines if a product is basic, performance, attractive, or indifferent.

The Vertical Axis

To categorize a feature, customers answer the question: "How would you feel if you had this feature?" or "How would you feel if you did not have this feature?"

The possible responses are:

• I expect it.

• I like it.

• I am neutral.

• I can tolerate it.

• I dislike it.

The Horizontal Axis

The horizontal axis represents how well a feature is implemented.

• None
• Some
• Basic
• Good
• Best

Pros of the Kano Model

• Customer-oriented
• Easy to implement

Cons of the Kano Model

• It does not account for business impact.
• It can end up being extremely subjective.
• It does not examine feature cross.
• It does not answer the "why" behind a response.
• It describes only the desirability of a feature, not how customers use it.

The MoSCoW Method

What is the MoSCoW Method?

The MoSCoW Method classifies features into four categories:

• Must have: features that a product cannot function without.
• Should have: features that are important but a product can do without. These are implemented only after all the must-have features are implemented.
• Could have: features that add attractiveness to a product but do not provide much value to customers.
• Won't have: features that do not add value or attractiveness to a product in its current iteration. These should be kept because they can add value later on.

When to use the MoSCoW Method

• When you need to ruthlessly trim down a massive list of proposed features.
• To analyze projects that have completed the discovery phase. The following should have already been identified before using this framework: user needs, business objectives, technical stack/requirements, UX design, and regulatory specifications.

How to Implement the MoSCoW Method

• Ask team members, clients, and all stakeholders to submit a list of their proposed features. These proposals need to be printed and cut into strips of paper. This makes the prioritization a physical and more collaborative process.
• Use a self-adhesive board to pin ideas on. A table may also work.
• Take a feature proposal and ask everyone in the room where it should go.
• If you are building an MVP, attach a budget estimate (in terms of development hours or the capital required) to each feature. Pruning features help meet the budget and timeline.

Pros of the MoSCoW Method

• It encourages a more transparent discussion because of its simplicity.
• It fosters collaboration, which can result to out-of-the-box ideas.

Cons of the MoSCoW Method

• The framework is not specific enough to include the sequencing of tasks.
• It is often hard to differentiate between "must have" and "should have."

Product Tree

What is Product Tree

A product tree is a visual and hands-on method of prioritizing features. In this framework, a tree is used to represent a product roadmap, with each part of the tree representing a category for features.

When to Use Product Tree

• When you need to organize feature ideas quickly.
• When you need to spark conversations through collaborative group work.

How to Implement Product Tree

Explain the parts of the product tree beforehand:

Trunk: Contains the features that a product already has or is being worked on.

Branches: Represents the features that will be added in the next release.

Roots: Represent the tech stack required to implement the proposed features.

Seed basket: Stores the list of proposed features that cannot make it to the next release.

1. Gather team members to write proposed features on post-it notes.

2. Post the feature ideas on the tree branches. You may need to rearrange the notes so that each branch contain features that share the same theme or category.

   Label branches as you go so participants can think more broadly.

   Draw lines on features that are dependent on each other.

3. Rearrange features to decide which can be implemented first. Place low-priority features on the outer ends of the branches.

4. Once all the ideas are posted, encourage the group to share their observations:

   • Are some branches heavier than others?
   • Are some categories under-represented?
   • Are there too many features close to the tree trunk (near-term priorities)?
   • Is the organization or team equipped with the tech stack required to complete those features?
   • Which proposed features should be moved to the seed basket?

Pros of Product Tree

• It is a quick way to analyze and rearrange priorities.
• It encourages collaboration because teams are gathered around a small focal point and are able to manipulate physical notes.

Cons of Product Tree

• Does not give provide a tool or method to rank each feature based on value.
• It requires other frameworks to analyze priorities with more depth.

Cost of Delay

What is Cost of Delay?

In the Cost of Delay framework, features are prioritized according to how much an organization loses while a feature is not implemented.

When to Use Cost of Delay

Cost of Delay is a flexible framework that can be used for small or big projects.

How to Implement Cost of Delay

Start by estimating how much revenue a feature may bring in.

For example, you can assume that a feature will bring $1,200 each week in revenue if it is implemented. By delaying its implementation, an organization stands to lose $4,800 each month.

This framework can also factor in the development time needed to complete a feature. This is known as Cost of Delay Divided by Duration (also known as CD3).

To compute for CD3, estimate a feature's weekly revenue and divide it by the number of weeks required to complete its development.

For example, a project that has an estimated cost of delay of $1,200 that requires four weeks to complete has a CD3 score of 300.

On the other hand, a project that has an estimated cost of delay of $2,400 that requires six weeks to complete has a CD3 score of 400.

The project that has a higher CD3 score gets priority because it presents a faster ROI.

There are three courses of action a development team can take after calculating the cost of delay:

1. Prioritize the project that is fastest to complete.
2. Prioritize the project that has the highest cost of delay.
3. Prioritize the project with the highest CD3 score.

Pros of Cost of Delay

• It is practical, especially for companies that need to tightly manage their revenue.
• It focuses on maximum business value.
• It decreases "wait waste."

Cons of Cost of Delay

• Some costs are difficult to quantify. Costs are not only in terms of revenue lost. It can also represent the number of customers who will churn if a feature is not implemented or fixed. It can also represent the number of customers who could potentially subscribe to a product.
• It emphasizes the impact of time, a nuanced aspect of product management. How does one choose between releasing buggy features early to stay ahead of competitors and delaying the release to safeguard brand reputation?

When prioritizing, you need to consider many things: customers, business impact, tech stack, and the ability of a development team. To learn more about prioritizing features, contact one of our CTOs.