Users asked for a faster horse. Don't take their word for it

Say you’re building a product. You sit down with users, ask what they need, write it down, and build exactly that. Simple enough — give people what they ask for. Then you ship it, and the thing they swore they needed barely gets touched. Turns out users don’t always know what they want.

The Faster Horse Problem

“If I had asked people what they wanted, they would have said faster horses.”

The quote’s often attributed to Henry Ford — unverified, but the problem is real.

It’s difficult to imagine a solution beyond what you already know — users can struggle to picture unfamiliar solutions, predict their future behaviour, or voice needs they have never had the chance to articulate. As a product manager, you’re in an awkward position: you’re told to listen to users, yet blindly following their requests can lead to the wrong product decisions. If users don’t always know what they want, what exactly should you be listening to?

A team spends two sprints building an “export to PDF” button because three interviews asked for it — nobody asks why they wanted PDFs in the first place. Turns out they just needed a reliable way to share a report, and PDF was the only word they had for it.

Your Brain Is Not a Reliable Witness

I buy a gym membership every January, convinced this year’s different. I plan three sessions a week. By February, I’ve been twice — and I still can’t say what changed between the planning and the doing, though here’s hoping writing an entire article about it finally breaks the loop. (Ask me again in March.)

Users aren’t always good at predicting their future behaviour or evaluating hypothetical solutions. Our brains are full of cognitive biases that influence how we think, remember, and make decisions. Researchers have documented more than 180 cognitive biases, although the exact number varies depending on how they’re classified (Engler et al., 2019).

Even our memories aren’t as reliable as we think. We don’t replay the past like a video recording. We reconstruct it, sometimes mixing up details or remembering things differently from how they actually happened (Lentoor, 2023). And if we can’t reliably recall the past, predicting our future behaviour is hardly a piece of cake.

Turns out there’s a name for what just happened to my gym plan: the planning fallacy.

Users Aren’t Your Product Managers

If users can be wrong about their own behaviour, should we simply build whatever they ask for and hope for the best? Probably not. Taking user requests at face value can lead to products that solve the wrong problems or prioritise solutions that sound appealing but don’t actually work.

Think about it this way: when you’re sick, you don’t ask a random person on the street to diagnose you. You look for a doctor who can use their expertise to understand the problem and recommend a treatment. You want the doctor to listen to you, but you don’t expect to prescribe your own treatment.

I’ve sat in meetings where a stakeholder diagnosed the problem and prescribed the fix before anyone opened a notebook — skipping the research part entirely.

Product decisions are the product team’s responsibility, not the users’. Users bring essential knowledge of their experiences, needs, and frustrations. The team’s job is to combine that knowledge with research, expertise, and evidence to decide what to build.

Asking Questions Isn’t Research

Touching a ball doesn’t mean you’re playing football. Looking at the sky doesn’t mean you’re conducting an observation. And asking users what they want doesn’t automatically mean you’re doing research. Asking users questions and doing research aren’t the same thing.

Good research comes down to asking the right question, in the right way, and reading the answer correctly — get any one of those wrong and the data misleads you.

Talking to users is just one part of research. Knowing what to ask, how to ask it, and how to interpret the answers is what makes the difference.

Stop Listening. Start Understanding.

Asking someone what they want and watching what they actually do are two different experiments, and they don’t always agree. UX researchers run the second one to check the first. The goal isn’t to stop listening. It’s to stop treating every answer as a direct instruction for what to build.

UX researchers use methods designed to work around the limitations of self-reported data, from observing what people actually do to testing how they interact with a product. Instead of asking users to predict what they might do, we can observe their behaviour, explore the context behind their choices, and identify needs they may struggle to articulate. Users can rate a feature highly on a post-launch survey, and usage data after launch can show almost nobody opening it — that gap between what they said and what they actually did is exactly what pairing self-report with behavioural data is built to catch.

Don’t just listen to what users say. Investigate what they do, why they do it, and what they actually need.

As Nielsen Norman Group explains, users’ opinions and preferences aren’t always reliable predictors of usability. That doesn’t make their input useless. It means we need to understand what their answers can and cannot tell us.

Bias Is a Bug. Or Is It?

Leave a checkbox pre-ticked on a signup form and most people never touch it — not because they want what’s behind it, just because unticking takes effort.

One email opt-in experiment found that a pre-checked box raised sign-up acquisition by over 125% compared to an unchecked one (NextAfter, CaringBridge experiment) — the same mechanism that nearly doubled real-world consent rates in a controlled comparison of organ donation policies (Johnson & Goldstein, 2003). Notice that one of those defaults serves the company collecting the email, and the other serves the person signing up — the bias itself doesn’t care which.

Cognitive biases aren’t just something we need to protect ourselves from — understanding how they work can also help us design better products, as long as we’re honest about which side of that line we’re standing on.

Take nudge theory — coined by Thaler and Sunstein. By changing how choices are presented, setting helpful defaults, or making certain options more visible, we can influence people’s decisions without taking away their freedom to choose. Instead of fighting against how our brains work, we can use that knowledge to design environments that make the better choice the easier one.

Research suggests that nudging can influence behaviour across different domains, although its effectiveness depends on the context and the intervention (Mertens et al., 2022).

The point isn’t to manipulate users into doing what we want. It’s to understand what’s actually shaping their decisions, then design around it.

We can’t eliminate cognitive biases. But we can design with them in mind.

Conclusion

Users may not know which solution is best, but that doesn’t mean we should stop listening to them. Their experiences, needs, frustrations, and constraints are essential evidence for making good product decisions.

The goal of UX research isn’t to ask users what to build and follow their instructions. It’s to understand their problems well enough to help the team make better decisions.

That gym membership I mentioned? Still two sessions out of three most weeks. The planning fallacy didn’t go away — I just know its name now.

Users bring the problems. Research helps us understand them. And the product team is responsible for finding the right solutions.