Asking customers "what would you want?" fails because people are bad forecasters of their own future behavior — a well-documented gap between stated preference and revealed preference. The fix isn't a better version of the question; it's a different question entirely, anchored in what someone already did, not what they imagine they'd do.

Quick Answer: Don't ask customers to design your product. Ask what they did last time they hit the problem, what they're duct-taping together right now, and what they gave up on. Behavior is data; wishes are fiction.

The Henry Ford Myth Is Doing More Harm Than the Quote Ever Did

The "faster horses" line gets quoted in every product-strategy deck as proof that customers can't be trusted with the roadmap. The irony: there's no solid historical record Ford ever said it. Patricia Anne Musso's research into the quote's origins finds no primary source earlier than decades after Ford's death — it's an attributed maxim, not documented history.

That doesn't make the underlying point wrong; it makes it worth grounding in something sturdier than folklore. Customers genuinely do struggle to specify the right solution when asked directly. The real reason isn't that they're unintelligent or uncooperative — it's that solution design requires imagining a future state they've never experienced, and humans are measurably bad at that specific task. The myth survives because it flatters the person retelling it ("see, I already knew better than my users"), which is exactly the attitude that produces bad discovery interviews.

The useful reframe: customers aren't withholding good ideas out of ignorance. They're being asked a question that sits outside what direct interviewing can reliably extract. Blaming the customer for a research-design mistake is the wrong lesson to take from the anecdote either way.

Why the Prediction Gap Is Real, Not Just a Cute Anecdote

The gap between what people say they'll do and what they actually do is a replicated finding across behavioral economics and market research, not a one-off curiosity. Three streams of evidence point the same direction, and each explains a different failure mode of the wish-list question.

Affective forecasting research, most associated with psychologist Daniel Gilbert, shows people are consistently poor at predicting how they'll feel about future states — they overweight the intensity and duration of anticipated satisfaction or frustration. Applied to product: a customer imagining a hypothetical feature can't accurately simulate how it would actually feel to use it three months in, so their forecast is unreliable by construction, not by carelessness.

The intention-behavior gap, documented across decades of health and consumer-behavior studies, shows stated intentions correlate only weakly with follow-through — meta-analyses in this literature (associated with work following Icek Ajzen's theory of planned behavior) have repeatedly found intentions explain only a modest share of variance in actual behavior. People say they want the feature. They mean it. They still won't use it.

New-product forecasting research from the marketing field, going back to work popularized around concept testing (frequently traced to Procter & Gamble-era practice and later academic replication), consistently finds stated purchase-intent scores overstate real adoption — often described directionally as a large gap between "would definitely buy" survey responses and actual purchase rates. The table below maps each mechanism to what it means for an interview.

MechanismWhat it distortsWhat it means for your interview
Affective forecasting errorHow good/bad a future feature will feelCustomers overstate excitement for novelty, understate friction of change
Intention-behavior gapWhether stated intent predicts action"I'd definitely use that" is weak evidence of real adoption
Purchase-intent inflationStated demand vs. realized demandConcept-test enthusiasm systematically overshoots actual uptake

None of this means customers are lying. It means the question format itself introduces the error, regardless of how honest or thoughtful the person answering is.

The Social-Desirability Layer Makes It Worse

On top of the forecasting problem sits a second, purely social one: people answer hypotheticals in ways that make them look forward-thinking, cooperative, or sophisticated to the interviewer. A customer wants to seem like a good partner in your research, so they hand you an idea that sounds smart in the room — regardless of whether they'd ever act on it.

This is why a wish-list question in a customer conversation often produces answers that mirror whatever the PM seems excited about. It's not manipulation; it's ordinary social mirroring. If your interview structure already conflates open and leading phrasing, this effect compounds — worth cross-checking against the mechanics laid out in the guide on the difference between open, leading, and closed interview questions.

What to Ask Instead: Mine Behavior, Not Imagination

Replace forward-looking hypotheticals with backward-looking, concrete recall — questions anchored in something that already happened, which is far harder to fabricate or idealize on the spot. The shift is from "what would you want" to "what did you actually do."

Three question families reliably outperform the wish-list format:

  1. Past-behavior questions. "Walk me through the last time you hit this problem." Specific, recent, real — not a composite or an average.
  2. Current-workaround questions. "What are you doing about it right now, even if it's clunky?" Workarounds reveal the true shape of the problem better than any stated preference, because someone built the workaround under real constraints, not hypothetical ones.
  3. Consequence questions. "What happened the last time this went wrong?" Consequences expose priority and severity, which a hypothetical wish list can't — nobody imagines the downside of a feature they're being asked to wish for.

Behavioral-economics framing aside, the practical test is simple: can the customer show you evidence, or only tell you a feeling? Evidence beats feeling every time in discovery.

A Side-by-Side of Weak vs. Strong Interview Prompts

Weak (wish-list) promptStrong (behavioral) promptWhy the strong version works
"What features would you want in this tool?""What's the last workaround you built to deal with this?"Workarounds are observed, not imagined
"Would you use a dashboard like this?""Walk me through what you looked at this morning to make that decision."Recent, specific recall beats a hypothetical yes
"What would make this product perfect for you?""What's the most annoying part of your current process, step by step?"Annoyance is remembered accurately; perfection is invented
"Do you think you'd pay for this?""What are you paying for or cobbling together today instead?"Existing spend is evidence; hypothetical willingness-to-pay is not

Notice the pattern: every strong prompt asks about something that already exists — a workaround, a decision, a step, a cost. The weak column always asks the customer to author something that doesn't exist yet, which is exactly the task affective forecasting research says people do badly.

Customers Reveal Problems; You Design the Solutions

The job of a discovery interview is to extract problems, frictions, and workarounds with high fidelity — not to extract a spec. The moment an interview starts asking "what should we build," it has quietly outsourced the PM's actual job to someone who lacks the full picture of technical constraints, business model, and competitive landscape.

This isn't a reason to dismiss customer input; it's a reason to route it correctly. A customer is the best possible source for "here is what hurts and here is what I've tried." They are a poor source for "here is the mechanism that should fix it." Those are different questions requiring different expertise, and conflating them is the core mistake the wish-list question makes.

Jobs-to-be-done thinking formalizes this split cleanly: customers hire products to make progress against a job, and the job itself is stable even when the tools they use to do it change completely. If your interview practice isn't already separating "what job are they trying to get done" from "what tool would satisfy it," the complete guide to Jobs-to-Be-Done is the deeper reference for that distinction.

Once you've collected problems and workarounds instead of feature requests, the next step is synthesis — turning raw friction into prioritized opportunities rather than a backlog of customer-authored feature ideas. That's the exact function of an opportunity solution tree for shipping teams: it structures problem evidence into ranked opportunities before any solution gets named, which keeps the solution-design work where it belongs — with the team, not the interviewee.

Where in the Journey the Wish-List Question Does the Most Damage

The wish-list question is especially corrosive at specific moments in a customer's relationship with a problem — points where emotion is high and memory of the actual friction is fresh, but where a premature "what would fix this" question short-circuits deeper problem exploration. Mapping frustration spikes against a customer journey emotion curve makes those moments visible before you walk into the interview, so you know where to slow down and ask about behavior instead of reaching for a solution question too early.

Building the Habit: One Behavioral Question at a Time

Fixing this isn't a one-time interview redesign — it's a recurring discipline, because the wish-list question is genuinely easy to slip back into under time pressure. It sounds collaborative. It sounds like you're listening. Those are exactly the reasons it survives in so many interview scripts.

A few concrete anchors keep it from creeping back in:

  • Pre-commit to a question bank of past-behavior and workaround prompts before the call, so you're not improvising phrasing live under social pressure.
  • Flag every hypothetical the moment it leaves your mouth — "would you use X" is a tell, and catching it mid-interview is a trainable skill, not a one-time fix.
  • Debrief for wish-list leakage, not just for insights — after each call, check whether you asked customers to design rather than describe.
  • Treat a strong answer as a symptom, not a spec — even a vivid workaround description still needs your team's judgment to become a solution.

Discovery consistency matters more than any single great interview. Building this into a weekly discovery habit of two interviews is the practical way to make behavioral questioning routine rather than something you remember only when a big interview is coming up. For the fuller frame this all sits inside — how discovery connects to prioritization and delivery — the complete guide to product discovery is the anchor piece worth bookmarking.

Where Prodinja Fits: Rehearsing the Catch, Not Automating the Judgment

Catching yourself mid-slip into the wish-list question is harder alone than it sounds, especially on a live call with a customer who's being generous with their time. Prodinja's Customer Interview practice is designed as a place to notice that pattern before it reaches a real customer — a space to walk through interview phrasing, catch a hypothetical "would you want" prompt, and rehearse the behavioral alternative instead. It's a practice space for the PM's own habits, not a system that talks to customers on your behalf or produces interview findings by itself.

That framing matters: the value is in building the muscle memory of asking about a workaround instead of a wish, not in offloading the judgment of what the customer's words actually mean. The interview itself, and the interpretation after it, stays entirely with the PM.

Key Takeaways

  • The "faster horses" quote is folklore, not history — researchers have found no solid documentation Ford said it, so lean on the behavioral-science mechanism instead of the anecdote.
  • People are poor forecasters of their own future satisfaction — affective forecasting research shows imagined future states are systematically miscalibrated, which is why hypothetical feature questions produce unreliable answers.
  • The intention-behavior gap is well documented — stated intent explains only a modest share of actual behavior across decades of research, so "I'd use that" is weak evidence on its own.
  • Concept-test enthusiasm reliably overstates real adoption — a pattern long observed in new-product forecasting, directionally consistent across categories.
  • Ask about the past and the present, not the future — past-behavior, current-workaround, and consequence questions all resist the fabrication and idealization that wish-list questions invite.
  • Customers reveal problems; your team designs solutions — that division of labor, not customer distrust, is the real lesson buried under the Ford myth.
  • This is a recurring discipline, not a one-time fix — the wish-list question creeps back in under time pressure unless you build habits and review calls specifically for it.

Frequently Asked Questions

Why don't customers know what they want in product discovery?

Customers struggle to specify what they want because forecasting a future feature's value requires imagining an experience they've never had, and behavioral-science research on affective forecasting shows people are systematically unreliable at that specific task. It's a predictable cognitive limit, not a lack of intelligence or effort on the customer's part.

What should I ask instead of "what would you want"?

Ask about past behavior, current workarounds, and past consequences — for example, "walk me through the last time you hit this problem" or "what are you doing about it right now, even if it's clunky." These questions ask for recall of something real instead of invention of something hypothetical, which produces far more reliable signal.

Did Henry Ford actually say the "faster horses" quote?

There's no solid documented evidence Ford said it during his lifetime; historical research into the quote's origins finds it attributed long after the fact with no verified primary source. The underlying point about stated preference still holds up on its own evidence, so it's worth citing the mechanism rather than the disputed quote.

Is it ever okay to ask customers directly about features?

It's reasonable late in a process, after problems are well understood, to validate direction with a concept or prototype reaction — but that's different from asking an open-ended "what would you want" early in discovery, when the risk of manufactured or socially-mirrored answers is highest. Even then, treat the reaction as one input, not a spec.

How do I stop myself from asking the wish-list question out of habit?

Pre-commit to a bank of behavioral prompts before each call, flag any hypothetical the moment you notice yourself asking it, and debrief afterward specifically for wish-list leakage, not just for insights. Building this into a recurring weekly interview habit makes the correction automatic rather than something you only remember under pressure.