April 12, 2022

Why You Need a Feature Prioritization Framework – Part 1

The pros and cons of 9 leading tools.

By Daniel Lunski, Senior Product Manager, 3Pillar Global

(note: This is the first article of a series)

One of the challenges of digital product development is determining exactly what to build. It’s important to have a development process, like our Product Mindset, that minimizes time to value and recognizes that products evolve. Feature prioritization is essential for product teams and product development. Choosing the highest priority can feel intimidating. A product manager has to juggle requests from different sources and manage political stakeholders.

It’s also a fact of life that you cannot make everybody happy all the time. But you can make most of the people happy most of the time. This is important to keep in mind at the time of grooming the backlog. Features may come from many sources.

For example, internal teams—such as sales, marketing and customer success, and development—like to have their voice and can be good contributors. Then there are external teams to consider, such as customers. And of course, there’s also the analytics—Oh Yes! We love analytics for its ability to allow us to interrogate what the data says.

For now, imagine your developers tell you Feature A will be really cool and take you to the next level. But a key stakeholder gently suggests Feature B must be included in the first release. Finally, your data analyst is convinced Feature B is completely unnecessary. And the data says users are crying out for Feature C.

Sorting through these inputs and deciding which feature to prioritize is not what you are hired to do; it is something you have to do to achieve your real goal: create successful products that bring value to your customers and the business while also utilizing developers in the most efficient way.

The need to prioritize comes from two very simple facts:

  • You don’t have unlimited resources.
  • You want to allocate developers to work on what is most essential and efficient for your business.

Therefore, you need a process to determine the sets and sequences of things that should be done on the product. This will deliver the most value at each point in time, given your constraints.

If you break this statement down, a core group of questions needs to be answered:

  • How can we know what’s valuable?
  • How valuable is each feature?
  • Who is each feature valuable to?
  • Which features can wait?

Once you answer the questions, probe further to determine if your assumptions are correct. Check to be sure you are also on the right track and if you are delivering value. And then keep asking, can we do better?

9 Common Prioritization Frameworks

To help you prioritize features, there are dozens of frameworks, but let’s take a close look at a few while also listing the pros and cons of each (examples taken from Roadmunk).

These frameworks provide guardrails for decision-making. The product manager still needs to make thoughtful choices about what to prioritize.

1. RICE

Known as Intercom’s internal scoring system for prioritizing ideas, RICE allows product teams to work on the initiatives most likely to impact any given goal. This scoring system measures each feature or initiative against four factors: reach, impact, confidence and effort (hence the acronym RICE). Here’s a breakdown of what each factor stands for and how it should be quantified:

RICE Overview

Using this formula, the individual numbers then turn into one overall score. The formula gives product teams a standard number that can be applied across any type of initiative that needs to be added to the roadmap:

RICE Formula

By running each feature through this calculation, you get a final RICE score. You can then use that final score to rank the order in which you tackle the idea, initiative or feature.

Here’s an example:

RICE Example

Pros of the RICE Method

  • Requires product teams to make product metrics SMART before quantifying them. SMART stands for specific, measurable, attainable, relevant, and—as seen in the parameter for the Reach score—the metric is time-based.
  • Lessens the influence that inherent biases have on prioritization.
  • Adds a confidence dimension in the calculations to move prioritization away from attempting to predict success to measuring the level of assertion each team member has for the features.
  • Sifts prioritization discussions from “Here’s how much this feature is worth,” to “Here is how we quantify our level of confidence for each of these qualitative, speculative scores.”

Cons of the RICE Method

  • Does not take dependencies into account for the scoring. There are times when an initiative with a high RICE score needs to be deprioritized over something else, so product teams need to treat the score as an exercise rather than the end-all/be-all answer to “What should we build next?”
  • Does not always generate 100% accurate estimations. RICE prioritization is simply an exercise in quantifying features in a way that takes into account the level of confidence teams have in their estimations.

2. Value vs. Effort

This simple approach to prioritization involves taking your list of features and initiatives, and then quantifying them using value and effort scores. With this method, it’s important to keep in mind that the final scores are just an estimation.

A lot of guesswork and opinions (backed with as much applicable data as possible) are involved in the process of quantifying the big question that prioritization aims to answer: “Will this feature/update push our goals and metrics forward? Can we feasibly build it with the resources we have?”

Value vs Effort Overview

Scoring methods like Value vs. Effort give product teams a quick and easy way to visualize a set of quantified priorities. This method of prioritization also makes room for healthy discussions among stakeholders on what they believe value and effort mean. This, in turn, helps product managers find strategic alignment holes and fix them.

Here’s what a Value vs. Effort scorecard looks like in Roadmunk:

Value vs Effort Example

(Pssst! Value vs. Effort is one of two prioritization templates available in Roadmunk. You can also create your own custom prioritization criteria and use any factors that are relevant to your company.)

Pros of Value vs. Effort

  • Provides flexibility for what constitutes value or effort. For some organizations, the effort could just mean development effort, in others, it could be the implementation cost.
  • Offers a flexible prioritization framework that can be used by any type of company, industry or type of product.
  • Helps align priorities by encouraging teams to quantify and numerically score features.Enables product teams to agree on which initiatives have more weight than others.
  • Leaves vague guesswork and assumptions out of the prioritization discussions.
  • Allows teams to focus only on the things that will have the biggest impact on their business and product goals; this is key in companies where resources are extremely limited.
  • Offers an easy-to-use tool because it doesn’t involve any complex formulas or models. All it requires is an agreed-upon numerical value that gets added into one overall total number.

Cons of Value vs. Effort

  • Leaves a lot of room for cognitive bias at the hands of the people doing the estimating.
  • Generates final score for each feature that might be too inflated, or not accurate enough—like all prioritization exercises, it’s a game of estimation and guessing.
  • Extends disagreement timelines—when it’s time for product and development to vote on how high or low the value/effort scores should be, the disagreements can take a while to resolve.
  • Can be hard to use with large teams with multiple product lines and components and the product teams that oversee each of those areas.

3. Kano Model

The Kano Model plots two sets of parameters along a horizontal and a vertical axis. On the horizontal axis, you note the implementation values to which degree a customer need is met. These values can be classified into three buckets:

  • Must-haves or basic features: If you don’t have these features, your customers won’t consider your product as a solution to their problem.
  • Performance features: The more you invest in these features, the higher the level of customer satisfaction.
  • Delighters or excitement features: These features are pleasant surprises that customers don’t expect, but that once provided, they create a delighted response.

On the vertical axis, you chart the level of customer satisfaction (satisfaction values). They range from <needs not met> on the left, all the way to <needs fully met> on the right (the implementation values). The way you get this customer insight is by developing a Kano questionnaire where you ask your customers how they would feel with or without any given feature.

The core idea of the Kano Model is that the more time you spend investing resources (money and effort) to create, innovate and improve the features in each of those buckets, the higher the level of customer satisfaction.

Kano Illustrated

Pros of the Kano Model

  • Leverages the questionnaire to teach teams not to overestimate excitement features and to stop underestimating must-haves.
  • Helps teams make better product decisions and market predictions for feature success and the audience expectations for those features.

Cons of the Kano Model

  • Uses time-consuming questionnaires.
  • Requires you to carry a number of surveys that are proportionate to the number of customers you have to get a fair representation of all your customers.
  • Confuses customers who do not fully understand the features you’re surveying them about.

In the next posts in this series, we’ll cover other prioritization frameworks, including Story Mapping; Opportunity Scoring; and “Buy a Feature”. If you need help prioritizing features on your next product development project, we would be glad to help. Contact 3Pillar today to learn more.