One of the more iconic phrases in customer service is “give ‘em the pickle,” drawn from a story by Bob Farrell regarding an unhappy customer who couldn’t get extra pickles for his hamburger.
The customer actually wrote a letter detailing the frustration he felt in his inability to get said pickles. The phrase stuck thanks to the important lesson Bob learned that day — a little extra effort in service is often all it takes to make for a great experience. The benefits of fulfilling small requests give truth to another popular idiom: that “the customer is (almost) always right.”
But what about feedback and requests that go beyond personal interactions with your company, and deal directly with your product? Should you listen to customers then? Do they understand their problem well enough to propose feasible solutions?
When it comes to a product’s vision, many will tell you: customers are often poor judges of their own needs. You’ll find yourself having to say “No” most of the time, and it’s for a good reason — in regards to building the best solutions, the customer is mostly wrong.
When listening to feedback, the temptation to follow the customer’s lead is always looming. After all, they know their problem, so they are probably the best person to plot out the solution, right?
Perhaps not. A while back, I outlined Why Steve Jobs Didn’t Listen to His Customers, and what implications that had in regard to internal innovation vs. customer feedback. A mostly tongue-in-cheek headline, it turns out that Jobs and Apple, in reality, didn’t entirely disregard feedback from customers. They were just very selective in how they used it:
Perhaps this is the truth behind Apple's innovation — Steve Jobs did actually listen to customers, but only to find out which problems they faced, and to identify the biggest points of friction they had. He did not listen to customers' proposed solutions because his belief was that the best, most innovative solution had to come from the company.
Customers might help identify the destination, but you can't usually listen to them on how to get there.
Where the customer tends to be consistently “right” is in that ability to point out problems.
In regards to Henry Ford’s supposed observation that people would have asked for “faster horses,” we see where the customer was actually right—identifying the need for quicker transportation.
But you needn’t be disrupting the horse and buggy industry to view feedback the same way. When someone takes time out of their day to contact you, pay attention: their thoughts could shed light on what other customers might be struggling with.
Where paths diverge is in developing with the best, most innovative solution. How do you build the solution of tomorrow around feedback that only consists of the ideas of today?
You can’t. Asking customers what they "want" could identify opportunities in your industry, but it does not necessarily improve or maintain a company's competitive positioning, and following feedback too literally could leave you reacting to problems instead of proactively developing a better solution.
Customer feedback is great for telling you what you did wrong. It's terrible at telling you what you should do next."—Phil Libin, CEO of Evernote
The customer is thus “mostly wrong” because 99% of the time they will suggest faster horses.
This can be misleading: in hindsight, “faster horses” obviously wasn’t the answer, but imagine being bombarded with thousands of similar requests. It is tough to say "No" in the face of such demand, but you have to remember that popularity doesn’t dictate optimal utility.
This is why folks far more experienced in product strategy than I insist that building a great product starts with saying no—even when the suggestion is good (nobody considers bad ideas) and even when many customers ask for it.
Wade Foster describes this as an entrepreneur’s ability to stop chasing problems after their product has found product/market fit:
Once your product has achieved product/market fit (it’s likely well on it’s way when you start getting thousands of feature requests), it’s best to stop chasing problems. There will always be things that other people want your product to do.
Rather than attempting to solve all of them, which will effectively make it impossible to solve any of them, instead focus on any problem that allows the customer to achieve a must-have experience.
This might mean you turn away potentially good customers in the short term, all for the purpose of attracting great customers.
Many would agree that excessive people-pleasing after product/market fit can ruin an initially good product. You have to recognize that most suggestions from customers won't fit your vision. You have to be able to say “No.”
This makes turning customers down a key skill in keeping support standards high, while focusing on building the product people need.
David Bland refers to the impending misery that may occur from doing the opposite as “the Product Death Cycle:”
And yet, saying “No” isn’t always easy. Product people build products because they love solving problems for customers (marketing folks like myself, who focus on customer success, feel the same way).
It’s tough turning people down. We can all use a refresher on how to say “No,” and why it is not the worst thing in the world for a customer to hear.
Learning how to say no isn’t just a necessary skill for support, it’s a necessary skill for life. It may take some practice, but here are a few things to keep in mind.
Realize that “yes” can be selfish. It’s important to acknowledge that there are many folks building products who struggle with the guilt of saying no. The thing to realize is that a misguided “yes” is essentially a selfish gesture towards the rest of your customers.
Bending over backward with new features or building something that is outside of your product’s vision in order to keep a single big customer will lead to a less than stellar product for the majority. “No” can be the most selfless thing you say all day.
“No” sounds better with understanding. Whenever an outcome isn’t in someone’s favor, it’s hard to make it a truly positive situation. But leaving the conversation without providing a reason is like applying for a job and not receiving any feedback: you’d rather just hear the why, even if you didn’t get the position.
Acknowledging the effort the customer put into the request and why you see how it might be useful (if true) is often just the right amount of empathy needed before you explain why it just isn’t a fit for where your team is taking the product.
Give recommendations when appropriate. It’s not uncommon for customers—especially larger customers—to get into an “all-in-one” mindset. Some companies do well building software this way, but they are the exception.
If a customer requests a feature that would bloat your product but would make for a great stand alone product, give a recommendation. We happily recommend fine folks like SproutSocial for providing quick and accurate responses to customer feedback on social media.
Set clear expectations. It is always best to err on the side of caution whenever you get feedback that you might implement. Having a customer follow up every 2 weeks after you’ve lead him or her on is awful for both of you.
If an idea has merit but isn’t on your immediate roadmap, don’t even come close to using the word “soon.” Assure the customer that you’re looking into said feature but that, “At best, it’s quite far out while we work on _____.”
Treat every “No” like the first one of the day. Saying no to so many feature requests can start to affect your empathy toward the customer.
To counteract this, be sure to remind yourself that the customer doesn’t know this is your twelfth no for a certain feature—they are likely getting in touch with you for the first time. It’s your job to make them feel like their contribution, even if it doesn’t get implemented, isn’t just a burden to you: “Really appreciate you taking the time to share these thoughts, Karen!”
Don’t lose your curiosity. Repetition also creates a risk of “seen that before” syndrome. This often results in you giving less and less attention to requests that seem repetitive.
It’s sometimes good, however, to dig into a feature request you’ve turned down before. Why did this person specifically ask for it? Although the default response to a customer question is often “action,” responding with your own questions from time to time can reveal some new insights about a certain feature that you’ve never had before.
To be clear, let us not forget that product excellence is often defined by meticulous evaluation and execution on evolving customer requirements. Knowing what customers need is what keeps a great product great, hence the ongoing utility of feedback.
You just have to remember that a company’s competitive edge often comes from avoiding the “sameness trap,” or by solving problems in ways that other companies and customers themselves never considered. Searching for the best outcome often requires many no’s, before you can finally say yes.
Mark Cuban has offered some pretty blunt thoughts on this issue:
"Cuban contends that asking customers what they want doesn’t improve a company’s competitive positioning. Customers make comparisons with existing products and services. They rarely offer insights for conceiving innovative solutions to compromises that everyone reluctantly tolerates."
Which is fine, because it isn’t the customer’s job to innovate. They don’t decide “what comes next,” you do.
Join 70,000 subscribers and get an original essay twice a week.