Henry Ford never said the line about faster horses. The Henry Ford Museum keeps a database of roughly 200 authenticated Ford quotations, and it is not in there. The earliest attribution anyone has traced showed up in 1999, decades after his death in 1947, in a cruise industry newsletter. Harvard Business Review and Snopes have both worked through the evidence and come up empty.
I bring it up because the quote gets wheeled out to justify ignoring customers, and the real lesson runs the other way. Customers are usually right about the problem. They are usually wrong about the solution. A product manager’s job is to tell the two apart, and most of the discovery work I see collapses that distinction on the first request.
The request is already an answer
When a customer says “I need a wishlist,” they have done something subtle and expensive. They have skipped past the problem and handed you a solution. Buried inside that request is a real situation: they found something they wanted, they were not ready to buy, and they had no way to hold onto it. That situation is worth solving. The wishlist is just the first idea a non-designer reached for.
One team I read about got repeated requests for a wishlist on an e-commerce product. They interviewed instead of building, and the underlying problem turned out to be narrower than a wishlist: people wanted to set aside items without committing them to a cart. They shipped a “Save for Later” affordance, which was smaller, cheaper, and closer to the actual behavior. Same request, different build, because someone treated the request as a clue rather than a spec.
This is the pattern under almost every feature request. The customer is a domain expert on their own pain and an amateur at your product. They will describe the pain in the vocabulary of a solution because that is the only vocabulary they have. If you build what they literally asked for, you are outsourcing product design to someone who has seen your product for a combined total of forty minutes.
Why building the literal request is so costly
There is a number I keep coming back to. Pendo’s 2019 Feature Adoption Report analyzed usage across cloud software and found that roughly 80% of features were rarely or never used, and that about 12% of features drove 80% of the usage. They estimated that publicly traded software companies had collectively spent somewhere around $29.5 billion building features that mostly sat idle (Pendo).
That graveyard is not made of stupid ideas. It is made of features someone asked for. Every dead feature had a champion, a request behind it, probably a customer name attached, possibly a deal it was supposed to unblock. The requests were real. The translation from request to build was where it went wrong. Teams heard “add X” and added X, without ever confirming that X was the shortest path to the thing the customer actually needed.
The cost is not only the engineering time. Every feature you ship is something you now maintain, document, support, and route around when you redesign. A wishlist you did not need is a permanent tax on every future decision about that screen. The cheapest feature is the one you correctly decided not to build because you found the smaller thing underneath it.
What “get to the problem” actually means
The advice to “understand the problem behind the request” is easy to nod at and hard to do, because it feels like you are second-guessing a paying customer. You are not. You are taking them more seriously than the request does.
The mechanics are unglamorous. When a request lands, from a customer, from sales, from your own executive, the move is not to argue and it is not to comply. It is to get curious about the story that produced it. Teresa Torres frames incoming requests as inspiration for what to explore rather than items to schedule; the request tells you where to point your next interview, and the interview is where the real opportunity surfaces (Product Talk). Her one-line test for any proposed feature is worth taping to your monitor: what underlying pain does this solve for the customer?
The questions that get you there are about the past, not the hypothetical. Not “would you use a wishlist,” which invites a polite yes. Instead: walk me through the last time this happened. What were you trying to do? What did you do instead? How often does that come up? What made it annoying enough to email us? You are collecting a specific story, because specific stories contain the constraints that a generic request strips out. This is the same reason interviews beat surveys for discovery: a survey captures the solution the customer typed in a box, an interview recovers the situation that made them type it. I have written before about how users cannot reliably explain their own behavior, and feature requests are that gap in its most confident, most specific form.
A case from outside software
Years ago, running operations at a telecom in Saskatchewan, I had a regional manager insist we needed a new daily report. Very specific request: a spreadsheet, emailed at 7 a.m., breaking out overnight technician callbacks by exchange. My first instinct was that this was a two-hour job, so let’s just build it and move on.
I asked him to walk me through what he did with the report. It turned out he did not want the report. He wanted to stop getting ambushed in the 9 a.m. leadership call by numbers his own boss already had. The report was his guess at a fix. The actual problem was that dispatch data reached his boss before it reached him. We did not build the 7 a.m. spreadsheet. We changed who was on the existing distribution list, which took ten minutes and solved the thing he actually cared about, which was not looking uninformed in front of his boss.
If I had built the literal request, I would have shipped a report, felt productive, and left the real problem untouched, and it would have shown up again in a different disguise a month later. That is the tax you pay for treating requests as specs. The disguises keep coming because you keep solving the costume instead of the person inside it.
When to just build the thing
Discovery has a cost too, and I am not arguing you should interview your way through every button. A few conditions make the request trustworthy enough to build more or less as stated.
You already understand the problem deeply, and the request is consistent with a pattern you have validated. The request is cheap and reversible, so the cost of being wrong is a few days you can claw back. Many independent customers are converging on the same underlying situation, not just the same solution word. Or the requester is describing something in their own domain where they genuinely are the expert and you are not, which happens often in vertical and developer tools.
The judgment call is not “always dig” versus “always build.” It is proportioning your discovery to the cost and reversibility of getting it wrong. A cheap, reversible feature that matches known demand: build it and watch. An expensive, load-bearing feature justified by three loud accounts: that is exactly where the $29.5 billion went, and exactly where an hour of interviewing pays for itself many times over.
The habit worth building
Put one filter between every feature request and your roadmap: separate what they asked for from what they are trying to accomplish, in writing, before anyone estimates anything. Two columns. Left column is the literal request. Right column is the underlying job, stated as a problem, sourced from an actual conversation and not your assumption about it.
Most of the time the right column, once you have it, suggests something cheaper and better than the left. Occasionally the two columns match, and now you build with real conviction instead of just compliance. Either way you have stopped letting the customer’s first guess set your engineering agenda. The customer brought you a genuine problem wearing a solution’s clothes. Getting the clothes off is the job.