Why Your Customer Is Not Always Right: Validating Feature Requests
The principle that “the customer is always right” has a sensible origin: in customer service contexts, where the goal is resolving a specific customer’s immediate problem, defaulting to the customer’s judgment creates better relationships than defaulting to organizational policy. In product development, however, the principle leads product teams directly into some of their most expensive mistakes.
In product development, the customer is frequently wrong. Not about what they want — their experience of wanting a specific thing is genuine. But about whether what they want is what they need, whether what they need is what they think they need, and whether addressing their stated request is the best way to address their underlying need.
Why Customers Are Often Wrong About Product Features
They’re optimizing for familiarity: Feature requests are almost always modeled on tools and interfaces the customer already uses. Customers ask for features that look like things they’ve seen elsewhere — which means they’re asking for incremental improvements to existing paradigms rather than genuinely better solutions.
They’re describing symptoms, not root causes: “I need a bulk export feature” describes how the customer is experiencing a problem, not the problem itself. They’re experiencing workflow friction; the bulk export is their imagination of how that friction could be reduced. A different solution might reduce the friction far more effectively.
They’re not thinking about what it costs you or other users: A customer asking for a highly customizable enterprise feature doesn’t know that building and maintaining it would require significant engineering investment that would come at the expense of improvements serving a much larger number of users. Individual feature requests are made without knowledge of the trade-offs they represent.
They can’t imagine what doesn’t exist: Clayton Christensen’s work on Jobs-to-be-Done consistently found that customers ask for what they can imagine, not what would actually serve them best. The most valuable product innovations — the ones that genuinely transform user experience — are almost never suggested by customers, because customers don’t know they’re possible.
The Validation Process
When a customer feature request arrives, the appropriate response is not to reject it but to validate it:
Translate to the underlying problem: What specific workflow challenge is creating this request? What would be different about the user’s experience if this problem were solved?
Test the prevalence: Is this a problem one customer has, or one many customers have? Individual requests that aren’t broadly shared should be treated with much lower urgency than patterns that appear across many users.
Evaluate the proposed solution against alternatives: Is the requested feature the best way to address the underlying problem? What other approaches exist, and how do they compare on impact and cost?
Key Takeaways
Validating customer feature requests is not customer contempt — it’s customer respect. Customers deserve products built with careful attention to their genuine underlying needs, not products that implement every requested feature and become bloated, incoherent tools that serve the loudest requests rather than the most significant needs. The discipline of validation produces better products than the instinct of accommodation.
Soft Skills as Organizational Capability
When an individual PM develops strong soft skills, the benefit is personal effectiveness. When a product team develops strong collective soft skills — when the whole team is skilled at influence, communication, and conflict navigation — the benefit is organizational capability that produces consistently better collaboration outcomes than any individual excellence could produce. Investing in team-level soft skill development through coaching, practice, and mutual feedback multiplies the return on individual development.