How to say no to product feature requests

· 9 min read
How to say no to product feature requests

Figuring out how to say “no” to a customer is never easy. It’s especially hard to say no to product feature requests.

Many companies make it clear that they value user feedback. Being committed to building a product based on it is an even bigger promise.

This can make customers a little too hopeful that whatever they ask for will be done.

How to say no to customers & feature requests

The sad reality is that some features will never be built. This is a hard blow for people who have suggested them.

They’re asking for something they think would add value to your product or solve a big issue. You’re telling them they can’t have it.

You should never build something just because a customer is upset. But, the right attitude and choice of words can make a huge difference between saying no and saying no.

Today, we’re going to talk about how to say no to a feature request the right way.

New call-to-action

Manage expectations around product feature requests in your messaging

You’ve made it clear that customer feedback is an integral part of building your roadmap. This is a great message that makes your customers feel important and involved.

However, you have to be careful with how you phrase these statements. It’s obvious to you that you can’t build every single feature someone asks for. It might not be obvious to your users.

If you’re asking for feature ideas (for example, with feature request software like Canny), make it very clear that you still have to analyze every single one of them. Even better—tell them straight up that not all of them will be built.

SansMagic has a great “formula” for how customer expectations and reality affect the outcome:

Saying no to customer feature requests

A feature voting tool like Canny can also help with managing expectations naturally. Customers can see that product feature requests are also being voted on by other users. Seeing a list of features ordered by votes makes it more obvious that requests with only a few advocates will most likely not be built.

This will keep expectations reasonable, and everyone will be on the same page.

Instead of saying:

We build what our customers want! Post a feature request and we’ll make it happen.


We’re committed to involving our users in building our product roadmap. Let us know which features you’re missing, and we’ll get in touch about the options.

Make sure you’re on the same page

This needs to happen before you even begin to say yes or no.

Some people are not great at communicating their issues or requests. They also might not be too familiar with your product or its current capabilities.

All of the above means that you might not even know what the customer is really asking for. Often what they really need is not what they are communicating.

Make sure you ask specifying questions before making decisions:

Always ask questions before saying no to feature requests

Asking questions to determine what they really need will eliminate confusion and disappointment on both sides.

Instead of saying:

Thanks for the feedback. We’re not going to be building this feature at this time.


Thanks for the feedback. Could you tell me more about why this feature is important to you? What is the problem that it is causing around your usage of our product? What benefits would you see from having this built?

Explain, a lot

If you have to say no, don’t just say no. Explain why you’re saying no.

When a customer requests a feature, they’re already convinced that it is crucial for their success with your product. It’s way more important to them than it is to you.

You just know you’re not going to do it. If you don’t explain it, they won’t understand why. They’ll just feel like their input isn’t important to you. It’s not a good feeling.

It’s perfectly fine to share the real context behind why you can’t build a feature they want. This will help them understand that it’s nothing personal, and that there are real reasons behind it.

Instead of saying:

Thanks for the feedback. We will not be building this feature at this time.


Thanks for the feedback. We will not be building this feature at this time. Since we’re a fully bootstrapped company, our development resources are limited until Q4 of 2019.

We have decided to tackle features X and Y as a priority, because the majority of our customers have heavily requested them.

These features will also be beneficial to you because of reasons X, Y, and Z. We’re happy to revisit this request with you after our resources have become available again.

Watch your tone

Always reply with the exact same amount of understanding, politeness, and depth to every user.

No matter how many times you’ve heard it, how many times you’ve said no, or how tired you are—act like it’s the first time you’ve seen this request.

Stay away from phrases like: 

  • This is a bad idea
  • It’s never going to happen
  • We hear this all the time

Remember that you don’t want to damage your relationship with the customer. If you come across too harsh, your customer will feel scorned—and they won’t come back to you next time they have a feature idea or request.

Instead of saying:

Thanks for the feedback. We hear this very often, but unfortunately, we don’t think it’d be a good idea at this point.


Thanks for the feedback. Other customers have also expressed their interest in this feature, and we can see why. We understand how building feature X would save a lot of time doing Y for your company, especially since you have a small team.

Our development resources are currently limited until Q4 of 2019, but we’ve added your vote to the request, and will revisit it as soon as we have the capability. Please do let us know of any other requests you might have now—we’re here to listen!

Don’t give false hope

If you’re 100% never going to do something, don’t give customers any hope that you will. This will just cause more disappointment.

Some customers will interpret “We’ll think about it in the future” as “We promise we’ll do it in the future.” This will not only upset them when you don’t, but also keep them in a limbo of not knowing what is happening.

Saying no and being concrete about it is better. It can be hard, but it eliminates any chance of misunderstanding or false hope.

Instead of saying:

Thanks for the feedback. We’re not going to build this feature at this time. We’ll maybe think about it in the future, but we’re not sure.


Thanks for the feedback. We don’t see this feature being included in our roadmap, since it doesn’t align with our basic functionality and use cases.

Offer alternatives

Not being able to build a new feature doesn’t mean the customer doesn’t have an issue or that the issue is invalid.

Make the effort of finding out the real problem your customer is having. There’s a chance it can be fixed with something else. You don’t want to just say no and leave it at that. Always offer something.

Intercom makes a great point with this graphic, about “focusing on the job, not the no”:

Focus on the job, not saying no

Suggest anything at all—whether it’s a workaround, a tip, an integration they can use, or an offer to revisit the idea in the future.

This will tell them that even though you’re not going to build a feature, you still deeply care about fixing whatever problem the customer has.

Instead of saying:

Thanks for the feedback. We’re not planning on building this feature in the near future, so you will not be able to do what you’re asking for with our product.


Thanks for the feedback! We’re not planning on building this feature in the near future because of reasons X, Y, and Z. However, we have a workaround that might solve this issue for you. Would you be interested in trying that?

Know how to compromise

We’ve made the point several times about how important it is to ask questions and have a conversation.

A conversation might reveal things you didn’t think about before. You might even reconsider not building a feature in the end.

If the request is low effort but high value for a valuable customer (or a few customers), maybe you should do it!

product feature request effort vs impact

We’re not saying that you should feel pressured to rethink your decisions. It’s always your call, and it’s always fine to say no.

However, keep an open mind—sometimes it makes sense to say yes instead.

Be nice, be transparent, and keep an open mind

There’s a big difference between saying no, and saying no.

You always have the right to decline customer feature requests. Your product is your creation, and some requests just don’t make sense sometimes. You shouldn’t feel bad or guilty about it.

However, you do have to make an effort to not make your customers feel disregarded, confused, or discouraged. They are trying to help, and their feedback is still immensely valuable.

Be nice, open, positive, and explain the real reasons behind why you’re saying no.

Your users will get clarification, even if it’s not the answer they want to hear. Plus, they won’t feel discouraged by being rudely denied—which will make them more likely to share more feedback in the future, too.


Elen Veenpere

Marketer at Canny. Elen enjoys drinking unnecessary amounts of coffee, typing words, and filling out marketing spreadsheets.

All Posts

Canny is a user feedback tool. We help software companies track feedback to build better products.
Notify of
Inline Feedbacks
View all comments
September 4, 2019 1:55 am

This is a great article to handle customers

August 31, 2020 3:42 pm

These are really good pieces of advice, thanks a lot!

February 4, 2021 9:13 pm

thanks a lot Elen!

© Canny 2024
Privacy · Terms · Security