There’s a quote, often attributed to Henry Ford, that gets thrown around a lot: “If I had asked people what they wanted, they would have said faster horses.” Whether he actually said it or not, the idea has stuck around because it’s true. People are great at describing their current frustrations. They’re much worse at imagining a solution that doesn’t exist yet.
This is one of the hardest lessons for any founder, product builder, or service provider to learn — because it sounds like arrogance. “I know better than my customer what they need”? That feels backwards. Aren’t we supposed to listen to the customer?
Yes. But listening and obeying are not the same thing.What customers are actually good at telling youCustomers are an incredible source of truth about their problems. They know:What’s annoying them right nowWhat’s costing them time or moneyWhat almost worked, but didn’t
What they’re comparing you to
This is gold. You should be mining it constantly.What customers are bad at telling you
Where it falls apart is when you ask them to design the solution. Most people describe fixes in terms of what already exists. They’ll ask for a faster version of the thing they already have, a cheaper version of the thing they already have, or a slightly modified version of the thing they already have — because that’s the only vocabulary available to them.
Steve Jobs leaned hard into this idea. He famously avoided traditional market research, arguing that it’s not the customer’s job to know what they want. The often-cited version of his reasoning: people don’t know what they want until you show it to them.
That’s not a license to ignore feedback. It’s a reminder that feedback tells you the destination, not the route.
The translation job
Your real job, if you’re building a product or running a business, is translation. The customer hands you a request. Underneath that request is a problem. Underneath that problem is a goal. Your job is to dig past the request, understand the goal, and then build the best possible answer to that goal — even if it looks nothing like what they asked for.
A few classic examples of this gap:
People didn’t ask for a smartphone. They asked for a better phone and a better music player.
People didn’t ask for ride-hailing apps. They asked for cabs that showed up faster.
People didn’t ask for streaming. They asked for fewer late fees at the video store.In every case, the company that won wasn’t the one that built exactly what was requested. It was the one that understood the underlying desire — convenience, speed, certainty — and delivered that, in a form nobody had thought to ask for.Why “just build what they ask for” backfires
If you only ever build literal requests, a few things go wrong:
You ship a patchwork. Every feature is a one-off fix for one complaint, with no coherent vision tying them together.You stay reactive forever. You’re always one step behind whatever the loudest customer said last week.
You miss the bigger opportunity. The literal request is almost always smaller and safer than the real opportunity hiding behind it.
Customers optimize locally. They want their specific pain point gone. You have to optimize globally — for the whole problem, the whole experience, the whole reason they came to you in the first place.
How to actually do this well
This isn’t permission to ignore people and “trust your gut.” It’s a discipline:Collect requests, but interrogate them. When someone asks for a feature, ask why. Then ask why again. Get to the root need.Watch behavior, not just words. What people do is often more honest than what they say they want.
Prototype the real solution, not the literal request. Show them something better and let their reaction tell you if you’re right.Earn the right to disagree. This only works if you deeply understand the problem space. Ignoring feedback because you “just know better” without doing the work is ego, not insight.
Listen to every complaint. Take every request seriously. But don’t treat the customer’s specific phrasing as a blueprint. Treat it as a clue. Your job is to solve the problem they’re pointing at — not necessarily the problem they described. Give them what you know they want, and most of the time, they’ll thank you for not asking first.