Asking the dev team for a feature request is a lot like a kid asking their parents for a new phone. 

You’re hoping--praying--for them to say yes, but they’re more likely to turn it down. The fact that they have a good reason to deny you just makes it more frustrating. 

When I was a CSM, I’d get an average of around ten feature requests from customers each week. All of them would go to the product team. Of those, only one in a hundred would ever get approved, and only one in a thousand would be acted upon immediately. 

It’s easy to take this badly and become adversarial; especially when you’ve got a frustrated customer waiting for an update. But you have to look at it from the product team’s point of view. They have good reasons for saying “no.”

For this article, I enlisted the help of Catalyst’s Head of Product, Cliff Kim. Cliff was kind enough to share the product team’s perspective on feature requests and why yours was probably denied. 

1. Not enough information about “why”

This is probably the most common reason that the product team rejects feature requests. It’s not enough to just want something. You have to communicate why it’s so important. 

Knowing the “why” will influence how the requested feature is built, what the feature will actually do, the timing for launching it, and whether or not it needs to actually be built in the first place. 

For example, in a previous role I once had a very large and important customer request that their system automatically send out reports every Monday morning to the executive team. This feature would’ve required significant engineering time and derailed the project timeline. But when we dug deeper and asked the customer why they needed it, they said it was an idle question by their CFO, not a serious ask. 

Close call!

Other times, knowing the “why” changes the concept of the entire request. The customer isn’t a product designer (usually), so their approach might not be the optimal way to address the issue. 

2. Not enough information about “what”

Product teams hate vague requests. 

Sure, your customer wants a “delete” button on the homepage, but what are they trying to delete? Are they trying to delete multiple things? Which homepage are they even on?

It’s not enough for a CSM to pass on a request verbatim. The CSM should get a clear idea of what the new feature should look like and do, and then present it to the product team in a clear, unambiguous way. That way, the product team has a higher chance of building exactly what the customer wants. 

3. Doesn’t align with the product vision

This article might make it seem like I’m complaining or belittling feature requests. I’m really not. Customers have great ideas, and we at Catalyst place a high value on user feedback. 

However, a lot of time and effort went into crafting the business and product vision. If the request doesn’t align with that vision, it’s not going to get as much traction, no matter how good of an idea it is. 

Let’s use the example of a company that sells full-sized indoor basketballs. They’re great products, but customer requests will inevitably try to pull you away from that vision. Can you sell baseballs? Kid-sized basketballs? Basketball hoops? Air pumps? 

These are all great ideas that can expand the business, but using the wrong ones can distract you from your core vision. It uses up valuable resources that could be better used perfecting your core offering. 

4. Request is specific to one customer

We’d love to take the “no customer left behind” approach, but there just aren’t enough hours in the day. 

Everybody runs their business differently. This translates into differences in how they use a product and what they need it to do. The more widespread a use case is, the higher a priority it’ll be for the product team to solve. The more unique it is, the harder it is to justify. 

We want to help the general customer base, not just one company. 

Unfortunately, customers don’t like hearing this. Their use case is very important to them (which is why they asked for it in the first place), and they don’t care whether other people need it or not. 

You’ll have to exercise your best diplomatic skills in these cases, because the hard truth is that they’re not going to get their edge case resolved. Either work through it, or find a workaround. 

Here’s what Sydney Strader, our Head of Customer Success, suggests:

“We greatly appreciate you leaning in to help us shape the future of our product. We have gone ahead and logged this feature request on your behalf. Upon sharing this with our Product team, they have informed us that at-present this has not been requested in the past. We will continue to keep this logged and if more customers request the same, will strongly consider incorporating this into our future roadmap and informing you at that time. Please keep the requests coming our way! We appreciate your partnership and growing alongside us as a company.”

5. Not enough demand

This point is similar to the previous one. Product teams will often backlog great ideas if they’ve never heard them before, but won’t actually work on them until they have more information on pain points and user demand. 

Timing is everything when it comes to product development, and the developers need to understand the impact of developing a feature as soon as possible so that it could potentially be pulled up or set aside for later.

Adding features without first checking demand often results in a bloated product. Sure, it looks impressive on an RFP or a feature comparison chart, but it means nothing in terms of actual customer value. 

You’ll have wasted development time building and maintaining a feature that few people want or need.

6. Alternative solutions

Not everything has to be a feature request. 

Problems often have multiple solutions; and sometimes those solutions already exist.

As CSMs, our job is to know the product well enough that we can give the customer creative alternatives without having to ask the product team. Yes, the engineers obviously know the product better, but we should always be familiar enough with the product to come up with our own solutions. 

Only contact the product team as a last resort! 

When you investigate potential solutions on your own, you become more familiar with the product and will be in a better position to field requests in case this issue comes up again. Also, you’re saving the product team the effort of having to deal with one more ticket (for which they’ll be very thankful). 

In conclusion

Many feature requests are good--even great ideas, and often It’s not a question of if you should build a certain feature, but when. 

The product team doesn’t have enough time or manpower to use all the great ideas customers give them. They have to triage ideas based on difficulty, value to the user, and how many users will be affected. 

As a CSM, your need to understand this perspective so that you don’t accidentally promise the customer something you won’t be able to deliver. Learn how to handle those requests gracefully so that the customer knows their input is valuable. 

Most important of all, learn the product in and out so that you’ll be able to find workable alternatives and be everyone’s hero.