"Build what customers ask for" is sensible advice, and taken too literally it's a trap. Customers are experts on their problems but not on the solutions — and they tend to describe what they want in the vocabulary of tools that already exist. If you only ever build the literal requests, you'll produce a product that's an echo of what's already out there. The features that actually delight people are frequently the ones nobody asked for, because nobody knew to ask.
Here's how to hold "listen to customers" and "lead with vision" at the same time without contradiction.
The best features are often ones customers never requested — because customers describe problems in the language of existing solutions, not future ones.
The nuance:
Listen to the problem, not just the request.
The reason "build exactly what customers ask for" misleads is that customers frame their requests in terms of solutions they already know. They experience a problem, look at the tools available, and ask for a modification to those tools — a faster horse, not a car. The request is real and the underlying problem is real, but the solution embedded in the request is bounded by what the customer can already imagine. Build only the literal ask, and you're constrained by your customers' familiarity with existing solutions rather than by the actual problem.
This is why a product built purely on literal requests tends to be derivative. Every request is shaped by what exists, so the sum of the requests points toward incremental variations on the status quo. The genuinely better solution often lives outside what any customer would think to request, because they don't know it's possible. The error isn't listening to customers — it's listening only to their words and treating the surface request as the full specification, when the request is really a compressed, solution-flavored description of a deeper problem.
The fix is to treat every customer request as a clue to an underlying problem, and to solve that:
| Listening to the request | Listening to the problem |
|---|---|
| "Make the export faster" | "I'm losing time waiting on exports" |
| Build a faster export | Maybe: remove the need to export at all |
| Bounded by what they imagined | Open to solutions they didn't know to ask for |
| Incremental on existing tools | Potentially a better approach entirely |
When a customer asks for X, the valuable question is "what problem is making them ask for X?" The answer often reveals that X is one solution to their problem — and not necessarily the best one. Solve the underlying problem well, and you may deliver something the customer never requested but immediately recognizes as what they actually needed. That's the feature nobody asked for: not a guess pulled from thin air, but a deeper solution to a problem the customer described in narrower terms. This is the same skill as good discovery in sales — understanding the real need beneath the stated one — applied to product. The request is the symptom; the problem is the target.
Understanding the deeper problem sometimes means leading — building a solution the customer wouldn't have thought to request, because solving the problem properly requires going beyond their vocabulary of existing tools. This is where product vision earns its place: not in ignoring customers, but in understanding their problem deeply enough to solve it in a way they couldn't have specified. The best features often come from this gap between what customers can articulate and what would actually serve them best.
Crucially, this isn't license to ignore customers and build whatever you fancy under the banner of "vision" — that's how teams build things nobody wants. The discipline is that leading must be grounded in a real, observed customer problem; you're solving something they genuinely have, just in a form they didn't request. The test is whether customers recognize the solution as right once they see it. If they do, you understood the problem better than their words did. If they shrug, you mistook your preference for their problem. Holding both halves — listen deeply and be willing to lead — is what separates products that delight from products that merely echo. The same balance applies to a roadmap: grounded in real problems, but willing to bet on solutions customers haven't asked for yet.
To build features customers didn't ask for but genuinely need:
The throughline: customers are experts on their problems but describe them in the language of existing solutions, so literal requests point toward incremental echoes of what already exists. Listen for the problem beneath the request, solve that, and you'll sometimes build the feature nobody asked for — the deeper solution they couldn't have specified but instantly recognize. It's not ignoring customers; it's understanding them more deeply than their own words do.
Q: Doesn't "build what nobody asked for" contradict listening to customers? No — it's a deeper form of listening. Customers are experts on their problems but not on solutions, and they describe what they want using the vocabulary of tools that already exist. Listening to their words literally constrains you to incremental variations on the status quo. Listening to the problem beneath the words lets you solve it in ways they couldn't have specified. It's not ignoring customers; it's understanding them more deeply than their surface request does.
Q: How is this different from building whatever I think is cool? By grounding. A feature nobody asked for must still solve a real, observed customer problem — you're addressing something they genuinely have, just in a form they didn't request. Building whatever you fancy under the banner of "vision," with no real problem behind it, is how teams ship things nobody wants. The test is recognition: when customers see your solution, do they immediately know it's what they needed? If yes, you understood the problem; if they shrug, you mistook preference for need.
Q: How do I find the problem beneath a customer request? Ask why they're asking. When a customer requests feature X, treat X as one possible solution and dig for the problem driving it — "what's making them want this?" Often the answer reveals that X is bounded by what they already know exists, and a better solution lies outside their vocabulary. Solve the underlying problem well and you may deliver something they never requested but recognize instantly as what they actually needed. The request is the symptom; the problem is the target.
The best features are often the ones nobody asked for — not because you should ignore customers, but because customers describe their problems in the language of solutions that already exist. Take requests too literally and you build incremental echoes of the status quo, bounded by what customers can already imagine rather than by what would actually serve them.
Listen instead for the problem beneath the request, and solve that. Sometimes solving it properly means leading — delivering something customers wouldn't have thought to request but recognize immediately as right. The discipline is to ground every such bet in a real, observed problem and to test it by recognition. Hold both halves: listen deeply and be willing to lead. That gap between what customers can articulate and what would truly serve them is where the features that delight come from.
No following, no network, no luck. Just an unglamorous system I ran for eighteen months. Here's exactly what I did.
I went from 200 to 11,000 subscribers without hiring anyone. AI didn't write my newsletter — it did everything around it.
I chased big, audacious goals for years and burned out every time. Then I built my whole life around wins so small they felt like cheating.
Comments
Sign in to join the conversation
No comments yet. Be the first to share your thoughts!