"We asked our customers, and they want X." This statement, in a product meeting, is treated as evidence. It's used to justify roadmap decisions, override data, and dismiss alternatives. It feels rigorous. It feels customer-centric. And very often, it's misleading.
Not because customer input is irrelevant, it's essential. But because the value of customer input depends entirely on which customers you're asking, what you're asking them, and what stage of the problem you're at. Get those three things wrong and you'll collect confident data that points you in the wrong direction.
The loudest customers are often the least representative
The customers who respond to feedback surveys, who contact support, who write detailed reviews, and who show up in NPS follow-up interviews, these are not a random sample. They are self-selecting. And they are systematically different from the customers who make up the bulk of your revenue.
The loudest customers tend to be the most engaged, which means they're also usually the most invested in the current product, the most resistant to change, and the most likely to advocate for features that work for their advanced use case rather than the broader customer base.
This is particularly dangerous in product decisions. If you optimise for the feedback of your most vocal 5%, you may be actively making the product worse for the 80% who don't tell you anything, they just quietly churn.
Asking customers what they want produces unreliable answers
The classic problem: you ask customers whether they'd use a feature if you built it. They say yes. You build it. They don't use it.
This is not dishonesty, it's a fundamental limitation of how people reason about hypotheticals. What customers say they'll do and what they actually do are different things. Not because they're trying to mislead you, but because they're answering the question "would I use this?" rather than "will I use this?", which are cognitively very different.
Customers are also remarkably bad at predicting what they need to change their behaviour. They describe their needs in terms of the current product. They can't articulate what would actually make their life better, they can only describe the workarounds they currently use and the frictions they currently feel. Translating that into the right product decision is the team's job, not the customer's.
Stage matters: early signal vs late optimisation
The appropriate use of customer feedback changes dramatically depending on where you are in the product lifecycle.
Early-stage product development is the phase where customer feedback should inform direction, specifically, understanding what problems customers have, how they currently solve them, and what the consequences of not solving them are. This is qualitative, exploratory, and should be conducted with genuine openness to finding out that your current assumptions are wrong.
Late-stage optimisation is the phase where customer feedback should help you refine an existing experience. NPS, CSAT, and A/B test interpretation all make sense here. The direction is already set, the question is which version of the direction works better.
The mistake is using late-stage instruments (surveys, NPS, feature request tracking) at early-stage moments, and treating the output as strategic direction rather than operational signal.
Feedback from customers who've churned is different from feedback from current customers
The most honest feedback you'll ever get is from customers who left. They've already made the decision, they have nothing to lose by telling you the truth. And the reasons they give for leaving are often brutally accurate in ways that current customer feedback isn't.
Most businesses don't conduct systematic churn interviews. The ones that do often find that the stated reason ("too expensive") masks the real reason ("too complicated to get value from"). The difference between those two is a completely different product strategy.
When NPS becomes a vanity metric
NPS is one of the most widely used customer feedback mechanisms and one of the most frequently misapplied. The score is useful as a relative benchmark over time, but it tells you almost nothing about what to do.
The common failure mode: collecting NPS scores, reporting them to the board, and celebrating when the number goes up without having any clear understanding of what's driving the movement. NPS as a lagging indicator of something you haven't measured is just a number that makes leadership feel good.
The useful version of NPS involves a rigorous analysis of the verbatims, the actual responses customers write, segmented by customer type, by cohort, by product area, and tracked against changes in the product or operations. That version of NPS is a diagnostic tool. The number alone is not.
The right use of customer feedback
Customer feedback is signal when:
- You're talking to a representative sample, not just the vocal minority
- You're observing behaviour rather than asking about intentions
- You're asking about problems rather than solutions
- You're at a stage of the process where direction can still be changed based on what you learn
- You're combining it with quantitative data, not substituting for it
Customer feedback is noise when it comes from self-selected respondents, asks hypothetical questions about unbuilt features, or is treated as a substitute for the hard work of figuring out what the data actually shows about user behaviour.
The best product teams treat customer feedback as one input among several, important, but not sufficient, and always interpreted through a lens of who is giving it and why.