6 Steps to Prioritizing a Prolific List of Customer Feature Requests

Today someone asked me how I prioritize customer feature requests, when there an actual boatload of customer feature requests.

I fumbled through a disjointed response. How did I prioritize customer requests for new features? Although I prioritized large lists of customer feature requests frequently and often, I hadn't ever thought about my methodology for doing so. 

I thought about this question for the rest of the day, and wrote this post this morning.

Here are 6 steps I use when prioritizing a boatload of customer features.


1 - Make sure all feature requests on the list are actual customer asks.

At my company, I receive customer feature requests in a few different ways - Sales people and customer service reps enter feature requests into Jira on behalf of the customer, and product managers also receive requests directly. All of these requests end up in one big bucket labeled "Customer Feature Requests."

Unless you took the request from the customer yourself, and the rest of the feature requests contain an insane amount of extremely detailed information (unlikely!), you should validate each of these requests with the customer before prioritizing them. Some of these asks may have been offhand comments from a customer during a sales process that the sales rep took literally, or something a customer said on a particularly bad day to a customer service rep. Talk to the customer who made the request and make sure you understand the details of what they're asking for, and that the ask is definitely a real and ongoing problem for them. 

2 - Look at the actual problem customers are trying to solve.

Look beyond the specifics of what the customer asked for and focus on the job to be done, or the problem to be solved. It may not seem like there's any correlation between Customer A's ask for a bicylce, Customer B's ask for an electrified scooter, and Customer C's ask for a pink polka dot skateboard, but if you dig a little deeper, you'll realize that they're all just looking for a mode of local transportation. Look for these commonalities and you may be able to combine some asks into a single feature that solves for all. 

3 - Eliminate anything that's not technically possible within the next year.

A customer may have a great idea for a forward-looking feature - so forward-looking, in fact, that technical limitations render it impossible with the current architecture or tech stack. If you have a feature request with such a technical limitation that building the feature is not possible within the next year, close the ask, inform the customer, and start looking for a workaround. 

 I keep these features documented in an external 'wishlist' of future features (meaning, external to Jira). 

4 - Look at how closely the requests align with the product vision.

If you're building a car, and the feature request asks for a better ski rack, the ask is relevant to your product, but it's not really core to your product vision. (Alternatively, if you're getting thousands of requests for a better ski rack, and car sales have plummeted, it might be a good opportunity to pivot, but that is a different discussion entirely...)

There may be differences of opinion among the team of what is actually relevant to the product vision, since that vision may go through consistent evolution. I don't have any hard and fast rules to answer how you know if something is relevant to the core product vision, but rather this is something honed in a PM's intuition over time.

When I worked on TV apps, there was a feature idea floating around of incorporating fitness data and other health functionality into the app. While this is (still) an interesting idea, and perhaps something to keep on the 'future feature list,' it wasn't part of my core product vision for that year. At the end of the day, your team's time is limited, so a PM must keep vision and accompanying feature goals focused.


5 - Gauge the LOE from UX, engineering, and any other dependent teams.

(ACRONOMICON: LOE = Level of Effort)

One more step before prioritizing your refined feature request list, is to talk to your engineering and design teams to get a high-level level of effort. Some features involve a huge lift from engineering teams and little UX; others may require a ton of design time, but are simple to implement. If your design team has little or no backlog at the moment, it could be an opportunity to get the design-heavy feature done quickly.

Be sure to answer the question, "Are there any other teams I'm dependent on to get this feature out?" I recently had a feature request that seemed very simple - until I noticed I would have to involve an engineering team that worked on our billing software for a small piece of that feature. That engineering team had a ton of high-level priorities for the next 6 months, and I knew my feature wasn't going to be more important to them, so I had to lower the priority of the feature because of the dependency on that team.

6 - Talk to your team, and take into account other factors you may have missed.

If your company takes into account customer ARR, sales goals for specific industries, or any other business objectives, you may need to take these factors into account. This will vary from company to company. Make sure you understand these goals as they may impact how you prioritize.

Another tip if prioritizing with a team: Try putting each item on a 2x2. Here's how to use a 2x2 decision making diagram. I find it a helpful tool when the answers for priority are not immediately obvious.