4 Essential Feature Request Prioritization Frameworks

Which features are most important to the user?

Which ones will have the greatest impact on your bottom line?

Should you listen to your users or to management shot-callers?

How you answer these questions can make or break your product, and if the product is a critical component of your services mix, it can make or break your company.

Deciding which features to include and which to exclude in your new product or in the latest iteration of an existing product can be very challenging.  

It is impractical to leave such decisions to chance, and established players, as well as new market entrants, should not attempt to answer these questions haphazardly. You will never have the time, resources, or even justification to build every feature you can, and anything less than a quantified approach to feature request prioritization can detrimentally affect your ability to stay in operation over the long run.

In this article, we present a few ways (ten, to be exact, broken into four different categories) that you can implement a methodical, step-by-step system for determining which features you should include in your product and which can be postponed or cast aside altogether.

1. Priority Scores

There are many numerical approaches to deciding which of several features to work on.

For example, you can compare the value that accrues from having a certain feature against the complexity of developing that feature to decide whether or not the feature is worth the investment. This is the value versus complexity approach.

Alternatively, you can compare customer satisfaction against must-haves, shouldn’t-haves, and nice-to-haves. Two models, the Kano model, and the MoSCoW model, both measure customer satisfaction against specific features to determine if they absolutely should be included in the product, if they would be nice to have but are not necessary, or if they actually bring down the utility of the product.

A final numerical approach to feature request prioritization is the RICE approach. This involves determining how many people will be affected by the feature in a given period of time (the reach factor), the effects that that feature will have (the impact factor), the probability that the outcomes we expect to see will actually come to pass (the confidence factor), and how much time, effort, and resources will be needed to develop and release the feature (the effort factor).

Notice how calculating the effort factor may once again require the use of other feature selection systems already discussed, such as the value versus complexity approach to calculating return on investment.

The benefit of these approaches is that it allows companies to determine value on their own terms.

They can assign higher values to monetary investments, man-hours, complexity, customer satisfaction, or time to market, based on their unique circumstances. It is also easier to reach consensus on such metrics; all that is needed is an agreed-upon starting point of what the decision-makers deem to be the most important constraint in place.

On the other hand, some of these approaches involve a fair amount of guesswork, and large teams that have multiple products or service lines can find it hard to agree on which metric or metrics to use for a given feature inclusion or exclusion decision.

2. Story Mapping and Opportunity Scoring

These approaches take the focus away from metrics and data that the product team has and places it on the customer.

What steps does the customer go through when using the product or service?

How satisfied are they with current features, and how likely would they be to endorse a change in a specific feature?

Which features delight the customer and which are of little benefit?

By creating a visual that breaks down customer journey maps into a flowchart of steps, or by grouping specific features into categories based on customer satisfaction, a clear picture arises for which of many features you absolutely must work on first and those which don’t really impact the user’s experience.

Examples include a login page that the customer has to go through to use your product or a feature that all respondents to a feedback questionnaire said they would absolutely love to have.

The great thing about these approaches is that they help you quickly and efficiently identify what your MVP will look like, and it ensures that you create a product that is centered around the experiences of your users. The only issue is that it does not take into account internal product team constraints so you may face certain challenges in following a certain path once your feature request priority is defined.

3. Cost of Delay

If the revenue impact of a certain feature is positive reinforcement for the company to create that feature, you can think of the cost of delay as negative reinforcement for developing the same feature.

In this approach, instead of trying to determining how much you will benefit in the long run from having a certain feature, it attempts to determine what you are losing now by not having it, or how much it will cost if you do not develop it in the future (or simply develop it later than planned).

The great thing about this approach is that it helps you put a price tag on your feature backlog in actual dollar terms, and it helps decision-makers base their feature request priorities on what matters most to the company.

On the downside, estimates of lost revenue or future costs that will be incurred are just that: they are estimates, and they are often based on the gut feeling of the decision-maker in question.

4. Qualitative Prioritization

There are a few interesting ways to determine which features to work on that do not involve calculations or guesstimates as such, but some market research.

Consider the following scenarios:

Scenario 1:

Let’s say you are building an app that is designed to show users what they spend and where. Clearly, the UI of such an app would be a key feature to have, next to intuitive graphics and, say ease of use to reduce churn. You could add more features, but if they do not align with what you want the product or service to do, you discard them.

Scenario 2:

After surveying the competitive landscape, you identify a feature that has benefit but no one is providing (or they only provide a sub-par version of the feature). Armed with such data, it becomes easy to identify which feature to work on: the one no one else does a good job of providing.

Scenario 3:

Instead of identifying features that no one else is providing, things become easier if you can identify, based on customer demand, features that everyone wants. These are things that customers know they want but cannot find in the market.

The fine line between this and identifying market gaps is that customers, in some cases, may not know what they want; if they know and tell you, you can develop those features, but if they do not know what they want, you will have to conduct the competitor analysis outlined above to determine which features would make existing products that much better.

The feature request prioritization system you choose should be based on your strengths and needs.

For example, a startup running low on funds will likely adopt an approach different from an established player with money to burn, and a niche company that cannot easily find resources will likely place a higher premium on man-hours than anything else.

Similarly, if you are unable to conduct competitor research but have high-quality data on your own customers, you may prefer to tweak your existing features based on customer feedback rather than develop a new feature that no one else has on a hunch of what the competition is doing.

Regardless of your approach, as long as you base it on your strengths and needs and follow the system, you will be able to streamline the feature decision process and shorten the times to market.

You need to have your users fully adapt to your new feature release immediately. Click here to read all about Feature Adoption!