Estimated reading time: 8 minutes

How does your team do product feature prioritization? Everyone has their ideas for potential features—from the product team to marketing to engineering to customers—and they all go to bat for them. Hard.

I’ve even heard stories of the CEO playing golf with an influential customer and coming back with a product feature that wasn’t on anyone’s radar. Then decisions are often made based on who speaks the loudest or has the most clout instead of what will actually benefit the customer.

Which usually means frustration. Waste of money. Waste of time. And disappointment when the product fails to live up to expectations. So much for creating a product that generates market excitement.

If you want a more efficient and reliable way to prioritize product features, start with a clear and defined set of customer needs.

This post will cover why you need a new approach to product feature prioritization, why current frameworks don’t work, and how you can align your teams with a common set of needs.

The problem with Motorola’s product feature prioritization

Years ago, I worked with the product teams developing two-way radios for Motorola. These radios were designed for first responders—and it seems that just about everyone knows a police officer, firefighter or EMS provider. So, everyone thought they had valid insight into what this customer needed in a two-way radio.

The radio frequency engineers were advocating new features to improve connectivity.

The battery engineers wanted bigger batteries for longer talk times.

The mechanical engineers argued for stronger housings to improve durability.

If you’ve worked in an engineering-focused company, you know that there is never a shortage of good ideas. And everyone has their data point to prove that their idea will make the product a success.

This wasn’t uncommon at Motorola. The company was known for some market-changing products—but the products that created real market excitement were often the ones that were initially rejected. Conversely, those products and features that generated initial support and resources ended up providing only incremental improvements in value to our customers.

Motorola’s original Razr flip phone was one of the products that failed to initially generate the internal support needed to commit resources for development. A few dedicated people had to cobble together resources to work on the Razr, whereas other products that competed more closely with Nokia’s designs were fully funded.

But it’s not just Motorola.

Prioritizing products and product features this way is all too common. It’s a challenge to gain consensus on which features should be included and which should be excluded from a product concept.

Like most companies, we didn’t lack good ideas at Motorola. What we did lack was a prioritization process based on a set of needs that were designed to identify which features best align with what our customers wanted.

Without a feature prioritization method anchored around a well-defined set of customer needs, you often end up with feature creep—more and different features than what you originally planned. So, it’s not too surprising when the product is late to market, costs more than planned, and/or incorporates features that your customers don’t really care about.

Why your feature prioritization framework doesn’t work

I’ve seen product teams attempt to put a framework behind this challenge in a variety of ways. Using financial or business case projections, looking at competitive pressures, prioritizing features from key customers or stakeholders within the company, prioritizing new technologies—I’ve seen all of these justifications used for determining which products or features get funded for development.

Then there are prioritization frameworks like RICE, Value vs. Effort, Kano model, etc. These existing feature prioritization frameworks lack the information needed to quantifiably assess the benefits a feature will deliver to your customer. 

For example, the RICE scoring model is based on Reach, Impact, Confidence and Effort. The decision makers are asked to determine the likelihood that the product will generate market interest (Reach) that will lead to product adoption (Impact). But this approach provides no insight into which customer needs each product feature idea will satisfy. It also provides no insight into whether the customer actually wants a better solution to what’s currently available. The Reach and Impact scores are just gut feel driven, and therefore, the Confidence score should not be high. Effort is the only objective score in this prioritization method.

The Value vs. Effort and the Kano model both present similar problems. If you don’t have a systematic way to measure feature value to a customer, then how can you confidently determine which features will be delighters, satisfiers, or just meet basic expectations?

Instead, you need a prioritized list of customer needs that reflect the criteria your customers are using to assess the value of the product. These customer needs should be the metrics that the customer uses to judge value—and therefore the metrics the product team should use to assess the value of a feature.

How to prioritize product features for reliable outcomes

Let’s take a look at Motorola again.

We knew our two-way radio needed to be easy to use. This is precisely what users told us they wanted.

But it wasn’t until we adopted Outcome-Driven Innovation (ODI) that we realized many of us had different interpretations of what “easy to use” meant to our two-way radio users in public safety roles. The ODI framework defines needs from the customer’s perspective – it’s how the customer measures value when getting a job done. By using a combination of customer interviews, surveys, and statistical modeling, we were able to identify the metrics that customers use when trying to communicate with others via two-way radio. This allowed our product team to create the optimal product feature prioritization list and enabled the team to understand which solution would satisfy the most outcomes(customer needs).

How to prioritize product features for reliable outcomes

The first step in the ODI process is to talk to users. At Motorola, we had them explain how they determined if one product was easier to use than another, which allowed us to understand exactly what “easy to use” meant to this group of people. Our interviews revealed over 20 unique needs related to ease of use (and about 50 additional needs related to other functionality like battery life and durability).

Following the next step in the ODI process, we quantified these customer needs to see which were important to our customer and which were unmet. This meant surveying more two-way radio users on the importance of each and their level of satisfaction with their current solutions.

The results of this survey gave us the statistically valid data we needed to prioritize a list of customer needs. It turned out that only three of the 20+ ease-of-use needs rose to the top of this list (important and unmet).

These unmet needs were:

• Reduce the time/steps to identify current radio settings
• Make intentional radio setting changes without looking at the controls
• Reduce the time/steps to manually initiate/maintain a transmission.

This is what making a radio “easier to use” meant to our public safety users. The other 20+ customer needs related to easy to use didn’t require new or better features.

The insight gave us exactly what we needed to prioritize the right product features.

We needed to focus on these three unmet customer needs related to ease of use—and several other priorities we identified related to battery life, etc. Our industrial design team was able to quickly prototype design changes to the radio’s control and gain valuable feedback that these feature changes were, in fact, “exciters and delighters.”

Align everyone around a common set of customer needs

Can you imagine having a prioritized list of each thing your customer wants from your product? Based on hard data? It’s game-changing.

Everyone wants to create a winning product. The uncertainty comes from not knowing which of your customer needs are unmet by a sizable portion of the market.

The feature that the influential customer recommended to the CEO may satisfy an unmet for that single customer—but if that unmet need is not shared by enough product users, it’s not worth the resources to design it into the product. Having a prioritized dataset of unmet needs in hand that is based on 200 interviews instead of a few ad hoc stories goes a long way in getting people on the same page.

When you use ODI for product feature prioritization, it unifies the team around a single version of the truth. You have confidence that you’re solving the right problems, everyone is working toward solving the same specific set of problems, and everyone knows their role in the process. No one is distracted by side projects or arguing for a different set of features—because they’re all bought into your quantified priorities.

Yes, this feature prioritization framework adds some time up front in making sure you understand your customer’s needs—and the right needs to go after. But the overall process from product development to launch becomes faster, more efficient, and eliminates waste in time/materials/resources when you develop the wrong thing.

Are you ready to align your teams—and launch the next big thing? This is your new starting point. See how ODI works in this ODI overview webinar lead by Innovation pioneer Tony Ulwick.