Saying No to Feature Requests: Thoughts and Methods from 6 Product and Customer Leaders

When you collect customer feedback and feature requests, there will inevitably be a few that stand out as unfeasible or simply do not align with your product. Making sure you let that customer know that the feature will not be built while also maintaining the relationship is a delicate balance to strike.

We asked six product and customer success leaders about how they turn down feature requests.

Note: Savio helps B2B SaaS Customer Success, Product, and Sales teams organize and prioritize product feedback and feature requests. Learn more about Savio here.

---

Sam Tuke, Chief Executive @ Lightmeter

All our products are open source, so instead of saying "no", we say "you can add it yourself". If the requested is an individual and technical, they can download our product source code and change it as they wish then conveniently submit the changes back, and everybody benefits. If they are a company, then they can pay a freelancer or their own engineers to make the change. Contributing the change back to everyone else benefits them because, just because they make the feature doesn't mean they want to maintain it forever (or be liable for it). So they can do the short term work which solves their immediate issue and we maintain it for them so they continue to benefit.

We don't say "no", we just say "is it worth this much to you?" - there's always a price to be put on new features, and if they're prepared to compensate for the disruption to us then we will usually consider adding it. If the feature contradicts the product vision then we may only add it for them (maintain a separate extension or "fork" of the codebase). Again, if the price is right.

Follow Sam Tuke: @samtuke
Connect on LinkedIn: LinkedIn

---

Kim Chan, Founder and CEO @ DocPro

We often get many document requests and would do templates that would be useful to other customers. We do not provide a very customer-specific template which can only be used by the requester.

On how we turn down a feature request, we would politely inform them that we welcome any requests for documents and features, and would consider them in light of our vision - provide an accessible legal solution to everyone. If the document or feature requested does not fit into our vision, we may not do it.

---

David Galownia, CEO @ Slingshot

All business decisions should be backed by evidence, not assumptions. This is especially true when it comes to feature requests for your software. If you’re in the early stages of development, it’s cheaper and easier to make changes. However, if you wait until you've already launched, the cost and time needed will be astronomical (see our blog on Time vs cost for more info). What this means is that you really need to think hard about whatever features you implement after launch. If your customers, or even your board, are asking for new features, you need to make sure it’s worth it.

You can find out if these new features are worth the time and money via interviews. Talk with unbiased users and colleagues about their thoughts. You also want to make sure your questions aren't biased: don’t access their thoughts on the feature specially, as they’ll usually just say they like it. Get more relevant data by asking about their pain points with the current app, and things they wish they had. Then you should show your findings to your stakeholders. If that data matches with the features being requested, it may be a good idea to add. But if your interviews come back with evidence that the features aren't necessary, you’ve got a good reason to say no.

Follow David Galownia: @heyslingshot
Connect on LinkedIn: LinkedIn

---

Richard Waters, Founder & Managing Director @ Row

There are a few things I keep in mind when responding to feature requests with a “no”. The first thing to do is to understand what the users are requesting. I can capture and grasp what the feature request is about. This way, I might be able to lead them on what they actually need without saying “no” to them. When the situation calls that I really have to say “no” on the request, I always keep in mind to be nice even if what the users requested is not so relevant. I let them understand the reason for non-implementation as well as the implications of the feature will be implemented. I will also thank them for expressing their request and promise to reconsider if a feasible solution will be available. Never say never. I always end by mentioning added features or alternatives that may be of use to them.

---

David Stellini, Co-founder @ AllFront.io

It is very important that you don’t lose your users’ trust when you say “No” to their feature requests. Also, record those requests. You might bump into an effective solution for those requests in the future. Here are some things to note in saying “no” to feature requests:

• Know more about the request – This will help you be aware of a problem or an aspect that needs improvement but the feature the user requested is not so feasible and cost-effective;
• Do not say “no” immediately – Take time to understand the request because you probably won’t need to say “no” because the feature is already there and the user just needs a bit more guidance on how to use it;
• Be thoughtful if you really have to say “no” – Be grateful for the feature request, show that you care about your users, explain the reason why you cannot implement the feature (implications), assure that you will keep the request for future reconsideration, give alternatives or relevant features that may work for the user.

---

Brack Nelson, Marketing Manager @ Incrementors SEO Services

Boost Action. It seems obvious, but be sure to use Responsive to learn more about what your consumers want. If you're building a new product, you can let a lot more questions make it to the awaiting feedback stage to collect more feedback. And when submitting a request to that status, support your teams and consumers to add their use cases by examining particular questions in the status information and/or comments section.

Follow Brack Nelson: @incrementorsusa
Connect on LinkedIn: LinkedIn

---

Some key takeaways from the above:

1. Do not say no immediately – Understand where the user is coming from. There is a reason why they are requesting a feature. Figure out what the feature request is about first.

2. Back your decisions with evidence. If you're saying no, why are you saying no? If you can't answer that question, take another look at the request.

3. Be respectful and polite if you do have to say no. Should be very straight-forward, but you so want to make sure you keep the relationship between customer and company in good standing.

Last Updated: 2022-12-15

Want more articles like this?

Product Leaders from Slack, Zapier, and Appcues read our newsletter to delight customers, lower churn, and grow revenue.

Send me more like this

Unsubscribe anytime.