Saying No to a Customer Feature Without Losing the Customer
Most early stage founders eventually receive a specific kind of request from a customer that they are afraid to refuse. The customer is one of the more valuable ones, they have asked for a feature that the founder knows would not actually help the product, and the fear is that saying no will damage the relationship. So the founder either says yes and builds something they should not have built, or says a soft version of no that leaves the customer confused about what will actually happen, and the situation quietly degrades over the following weeks in ways that are worse than an honest no would have been at the start.
The good news is that saying no to a customer, when done well, tends to strengthen the relationship rather than damage it, since customers respect founders who have clear thinking about their product more than they respect founders who agree with everything. The bad news is that saying no well is a specific skill, and most founders have to learn it by making the mistake of saying no badly a few times first.
Do not decide on the call
The first move is not to say yes or no on the call itself, since decisions made in the moment tend to be reactive, and you owe the customer a considered response rather than a reflex. Say something like, "that is an interesting request, let me sit with it for a day and get back to you with a thoughtful response, since I want to think about whether it fits with where we are taking the product". This buys you time, and it also signals to the customer that you take their input seriously, both of which help the eventual conversation regardless of what you decide.
Understand what they were really asking for
The second move, once you are off the call, is to think carefully about what the customer was actually asking for, since the surface request is often not the real request. A customer asking for a specific feature is usually experiencing a specific frustration, and the feature is their proposed solution to that frustration, but there are often better solutions to the same frustration that do not require you to build what they asked for. Spending an hour understanding the underlying problem often produces a response that gives the customer what they actually need without requiring you to build something misaligned with your product direction.
The structure of the no
When you go back to the customer, the response should have three parts.
First, name what you heard them describe as the underlying problem, and check whether you understood it correctly.
Second, explain what you have decided not to build and why, in terms of the company's direction rather than in terms of your personal preferences.
Third, offer whatever alternative you can, whether that is a different feature you are working on that might address the same underlying need, a workaround they can use in the meantime, or an honest acknowledgement that you are not the right product for this particular need and a recommendation of what else they could try.
The specific words matter less than the structure, but a version might sound like, "you had asked about being able to do x, and I have been thinking about it. The underlying thing you are trying to do is y, is that right? We are not going to build x, because it would take us in a direction that would slow down the rest of the product, but I want to give you a useful path. Have you tried z, which handles the y part reasonably well, or would it help if I walked you through a different workflow that we already support?"
Why this works
This works because you have taken the customer seriously, explained your reasoning without being defensive, and offered them something rather than leaving them empty-handed. Customers who receive this kind of no tend to leave the interaction with more respect for you than they had before, and many of them will come back to you months later with better feedback because they trust that you actually think about your product rather than just building whatever anyone asks for.
What if they leave?
Sometimes the customer will decide that your product is not right for them and will leave, and this is not the end of the world. A customer who was going to leave because you would not build one specific feature would have found another reason to leave eventually, and letting them go with a clean explanation is better for both of you than trapping them in a product that does not really fit their needs. The customers who stay after receiving an honest no are the ones who become the most valuable in the long run, since they trust you, and trust is worth more than any single feature.
Comments