Prioritizing Feature Requests

Fours steps on how to determine feature priorities

Triage is the process of sorting and prioritizing tasks based on perceived urgency and or importance. It is commonly used in medical settings to help doctors determine which patients need their immediate attention and which patients may have to wait a little longer for help when there are limited resources. In a medical setting, patients are grouped into four buckets of urgency; immediate, delayed, minimal, and expectant.

The concept of triaging can also be applied to non-medical settings. As the product manager you’ll usually get feedback on new features from multiple sources and that can be difficult to manage. Whether it’s from marketing teams, internal stakeholders, customers, or even social media, it becomes critical to have a process in place to triage all requests and prioritize accordingly. In order to prioritize requests, you must truly understand what is being asked. Any product manager can take a customer request and come up with a solution but you’re not just any product manager.

Immediate: These are the new feature requests that address critical issues or solve pressing problems for a large portion of users. Just like in a medical emergency, these requests are given top priority when it comes to resourcing. They might involve fixing critical bugs that are causing major disruptions or implementing features necessary for the basic functioning of the system. Regardless of the feature, if it is immediate, it should be accommodated as soon as possible as it could mean that without this request your product could lose new or existing customers to a competitor.

Delayed: These requests are also pretty serious, but they are not as immediately threatening. You may not lose existing customers, but this is something you should prioritize if you want to gain new customers and keep existing customers engaged. These features should be prioritized after the immediate features since they will still add value to the product through enhanced user experience, efficiency improvements or even additional functionality.

Minimal: These are considered nice-to-have add-ons to your product. These requests may enhance the product’s aesthetics, minor convenience improvements, or cater to a smaller subset of users. While they’re not top-priorities, they can still contribute positively to the overall user experience, but it may not move the needle much to get new customers onboard.

Expectant: Unfortunately, there are requests that are just not technically possible or have a low change of being implemented. These requests could be technically unfeasible, incompatible with the system architecture, or not aligned with the product’s long-term vision. In these cases, the focus might shift from full implementation to providing customers with an explanation of why the feature can’t be accommodated and offering alternative solutions if possible.

Great product managers don’t just process each request but aim to understand the core business end goals that’s needed and the customer pain point that’s preventing them from reaching those goals. Before committing to working on any new feature requests, here are a few questions you should have the answers to:

1. What is the expected outcome?
2. How many customers would this impact?
3. What is the development cost?
4. What are the future maintenance cost?

What is the expected outcome?

Knowing what the customer expects at the end when the feature is released is a step that should never be missed. Communicating effectively with the customer keeps both the product team and customer aligned on what is to be built. By understanding the outcome, you can manage expectations and develop solutions that can meet or exceed the expected outcome. When consistently delivering on their expected outcomes, you foster trust and loyalty, where your customers trust and know that you understand their goals.

How many customers would this impact?

It’s not unusual that a feature one customer desires directly conflicts with the expected outcomes of another. The key to managing this expectation is to understand where most of your customers are today. Would this new feature be something that would boost their productivity and experience? Or would this cause degradation? If the impact of the feature is a net loss for most of your customers, then you may need to rethink it’s implementation. The easiest way to avoid a large negative impact is to make the feature a configurable option (i.e., let the customer choose whether they want to turn this feature on or not).  This question may be less relevant if your product is creating customized solutions for each customer, but if it is something more customers can benefit from, it can also be an enhancement.

What is the development cost?

Now this won’t be 100% accurate information because it’s early in the process, but your team leaders should be able to give you a rough estimate of the work needed. There will be additional costs to any figure they give since they are operating with limited information. However, knowing whether this is a two sprint effort versus a 12 sprint effort is enough to consider where it ranks in your prioritization. If something takes two sprints and has a positive impact for all customers, that’s a great start. However, if it’s a 12 sprint effort, and may require multiple engineers to work on it, you have to evaluate where this would land against all the other priorities and existing work that needs to be completed.

What are the future maintenance cost?

Maintenance cost is a little harder to take into consideration, but it is important and should not be left out of the equation. When a feature requires additional maintenance, that is something you need to understand upfront because it could impact future features if the team needs to take cycles to bug fix or add functionality to this new feature. Another consideration for cost of maintenance is whether this new feature will create more dependencies on other teams or services. Keep in mind, the more dependencies you have on external teams, the harder it is to align prioritization when changes need to be made as those teams will have their own triage process and prioritization for requests.

When categorizing your requests this way, you are better able to efficiently allocate your limited engineering cycles and ensure that the most urgent requests receive immediate attention. Make it a habit to regularly go through and re-triage your requests. This should be done to evaluate if there are any changes in the condition of the requests whether that be customer impatience, competition or even changes in technology. The ability to manage and properly categorize your requests will help increase the overall effectiveness of your team and make it easier to manage expectations with stakeholders. A great way to manage expectations is to create a product roadmap so that others are aware of how you are prioritizing requests and what’s coming soon to your product.

Did you find this article valuable? Stay up to date with more product management insight and resources by subscribing to our newsletter.