How to Prioritize Software Development Feature Requests

Feature prioritization is an important aspect of product development. Building new features allows you to improve your product by meeting customer demands and keeping ahead of the competition. But it can be a tricky operation.

Prioritizing feature requests is an ongoing process where product teams have to work together to determine which new features they should focus on. The decisions made need to consider market competition, cost, time, and available resources, as well as align with business objectives, of course.

So, how do you make sure you’re making the right decision?

In this article, we’ll show you how to prioritize feature requests by acknowledging the dimensions of each feature, popular frameworks to implement them, and how the process looks from different angles.

7 Dimensions of Feature Prioritization

Deciding which feature requests to prioritize is a balancing act. You have to weigh up short-term wins with long-term growth, and then decide which will be the most beneficial. You also have to consider everyone’s input and ideas, from the developers to the stakeholders, and then settle on the best possible outcome. To help you feel confident with your decision, here are the following dimensions that should be considered with every feature request.

1. Estimated profit

Profit is a huge dimension to consider when determining which features to prioritize. The initial course of action may be to focus on the feature that will cost your team less to build than one that costs more. However, the building cost isn’t the only figure you want to look at. Let’s take a look at an example that breaks down the figures involved in two feature requests:

Cost to build

A: $1,000,000     B: $5,000

Revenue

A: $2,000,000   B: $100,000

Profit

A: $1,000,000   B: $95,000

At first glance, you’ll see that feature A has the potential to yield $2 million, so why wouldn’t it be prioritized over feature B, right? However, if you do a bit of math, you’ll realize that B gives you a better profit margin.

2. Cost

Another factor of feature prioritization to consider is how much it will cost to build a feature. In most cases, if the estimated profit is predicted to be significant, then you would usually continue with building the feature. However, there can be some instances where a feature can cost too much, and therefore, isn’t worth the effort (even if it does have the potential to yield a high profit!).

Asteroid mining, for example, is a project that can reap a huge amount of profit, but, after taking into consideration the costs it will take to carry it out, it may simply be too expensive to tackle right now.

The asteroid mining feature request equivalent may have to take a back seat while other, more attainable features are prioritized.

3. Resource availability

On top of costs, the availability of resources is a dimension that should be considered when prioritizing feature requests. This can include but isn’t always limited to, development work hours, time, and effort.

An example of how this could play out:

Feature A has a duration time of 10 weeks and feature B will take 5 weeks.

You currently have your whole team available right now, but remember that the holiday season is approaching. Will you have the same amount of power available in 10 weeks time? If yes, then perhaps feature A could be a priority, but if no, then maybe feature B would be the one to focus on right now.

Thinking ahead can save you from any issues or delays that could occur if you were to only have half your team available in the final stages of development.

4. Technical risk

Every feature request carries its own set of technical risks. Things that may arise during development include delays, added costs, or a feature inadvertently affecting other parts of your software in unexpected ways. Ideally, you should weigh in on each feature request and focus on one that won’t put too much of a strain on your development team and process.

5. Market risk

If you don’t have concrete profit numbers, you have to estimate the market risk. The market risk can determine where a feature should stand on your priorities list.

It’s not uncommon for features that carry higher technical risks to have lower market risk. For example, a social media app is something that can be built over the weekend, but that means almost anyone can build it, which makes the market risk pretty high. On the other hand, building a teleport device would take much longer than a weekend and involve a lot more effort, however, it poses a much lower market risk.

6. Team risk

There are many different people involved in product development and everybody wants to put their two cents in, which is why team risk is another dimension that needs to be considered when prioritizing feature requests.

Developers, for instance, may not take an idea rejection too lightly if the reasons weren’t explained thoroughly enough. Other stakeholders may be disappointed that their latest brilliant idea can’t be made into reality, due to very valid technical reasons. This is why issues related to the people working on the product can sometimes outweigh technical risks.

7. Team value (aka. “Eating your own dog food”)

“Eating your own dog food” is a saying in the software industry that refers to companies testing out their products internally in real-life scenarios so they can get a feel of how their customers would use them.

Asking the team who created the very product to assess its value is a bit of quality control and great marketing. Think about it, nobody knows the product better than the people behind it. So, if you asked everyone involved what value they place on a potential new feature, it could help you to determine which requests to focus on first and which to push back.

Popular Feature Prioritization Frameworks

We’ve already seen that feature prioritization can get a little tricky. A chunk of that uneasiness can be attributed to having to measure unquantifiable elements such as team value and effort. The following frameworks aim to help reduce uncertainty when it comes to prioritizing feature requests.

Kano Model

The Kano Model is a framework for product development that focuses on improving customer satisfaction. Often referred to as the Kano Model Analysis, its aim is to help you determine which feature to create based on customer preferences.

The model was developed in the 1980s by Professor Noriaki Kano. It groups customer preferences into five categories: basic, performance, excitement, indifferent, and reverse.

Basic (“Must-be quality”)
These are requirements customers expected and often take for granted. In other words, it’s only until one of these requirements stop working properly that the customers will notice they are even part of the product.

Performance (“One-dimensional quality”)
The features categorized in the performance group are associated with the product’s job performance. They have a clear purpose and the better they perform, the more satisfied the customer is.

Excitement (“Attractive quality”)
These are features that unexpectedly delight customers as they do not anticipate them being there. That also means that if they do not work properly, the customers are not overly fussed because they didn’t expect them to be included in the first place.

Indifferent (“Indifferent quality)
The features that fall under this category are ones that customers feel neutral about. They are neither satisfied nor dissatisfied with their inclusion in the software.

Reverse (“Reverse quality”)
These are features that, while they take some effort to achieve, customers aren’t usually satisfied with. They highlight the fact that customers have different requirements and aren’t always alike.

RICE Score Model

The RICE Score Model is a method that can be used to evaluate ideas and priorities. RICE is an acronym that stands for Reach, Impact, Confidence, and Effort, each of which should be considered to help you with your evaluation.

Reach
Reach measures the number of people it will impact in a given amount of time.

Impact
Impact reflects the amount of influence your decision will have. This amount can be quantitative or qualitative.

Confidence
If you’re convinced that the feature will be a valuable asset to the product, but don’t necessarily have the data to back it up, then you can use confidence to support your argument.

Effort
How much work can a team do in a month? The more effort that is required, the lower the feature should be on your priority list.

MoSCoW Method

The MoSCoW method is a prioritization technique used in software development, but also in project management and business analysis.

This method is ideal for involving stakeholders in the product decision-making process and it shows you what is a top priority for them and your customers.

It stands for Must have, Should have, Could have, and Won’t have which are the four prioritization categories. (The Os don’t stand for anything, they’re just for making the acronym more memorable).

Must have
The features that fall under this category are mandatory to the product. Without them, the product wouldn’t be able to operate. The product cannot be launched without all of these features present, making this category the most time-critical.

Should have
The next set of requirements is considered important but not time-sensitive. They can be as important as Must have features, however, they can be delivered during another timebox.

Could have
The Could have features are more desirable than they are essential. They can better enhance the user experience but are usually only given the green light if time and resources allow it.

Won’t have
These features and requirements are the least critical, and can therefore be postponed for future releases instead of the current timebox.

Cost of Delay

Cost of delay is a framework that allows product managers to make decisions based on urgency and value. You can base your decision on a variety of things, but at the end of the day, when it comes down to business, making money is what it’s all about.

Quantifying the cost of delay can help with three key factors in your decision-making process:

1. It highlights the economic trade-offs so product managers are able to make more sensible decisions. Making tough decisions is part of the process, especially when you find that you have to balance many variables.
2. It shifts prioritization from instinct and gut feeling to optimizing value by using the Cost of Delay Divided by Duration (CD3).
3. It enables team members to work based on speed and value instead of cost and efficiency, which can sometimes urge behaviours you don’t want.

The idea behind the cost of delay method is that we can’t do everything at once. So, even when you receive several worthwhile feature requests, there will be a few that need to get pushed back. It basically wants you to consider whether the value of your product will be hampered or enhanced by a delay in building the feature.

The Process of Feature Prioritization

The process of prioritizing feature requests looks a little different depending on which side of development you are on: the product manager side or the development team side. It’s crucial for both sides to work together in order to make the right decisions.

From the product manager’s perspective, their job is to lead the production process from inception to launch. They’re responsible for guiding the development team, managing stakeholder and customer expectations, and making strategic decisions to ensure a smooth-running process.

And on the development team’s side, engineers and developers will have their own ideas as to what they think should be the next feature built, however, their input isn’t always a sure thing. Their planning sessions are greatly influenced by the product manager’s decision on feature prioritization.

Essentially, the reason both sides need to come together can be down to the following:

• The product manager needs the knowledge and insight of the people who create the features in order to come to the best possible outcome.
• The development team run the risk of looking at the product from an inward perspective, which can lead to neglecting the market value of a feature and whether it’s something the customer really wants.

Final Thoughts

Building new features can be an exciting thing, but then if the prioritization process isn’t up to scratch then it can put a strain on the team and take the fun out of development.

Considering the various dimensions of each feature request, as well as implementing a framework and evaluating the process from different outlooks can make feature prioritization a better experience for all involved.

How does your team prioritize feature requests?

Cheers,

Dinnie and the Zenkit Team