Week 35, 2026
One of the most common pieces of product advice is also one of the most dangerous when taken literally: listen to customers.
Before anyone misunderstands me, let me be clear. I believe deeply in customer feedback. I spend a huge portion of my time talking to customers, and I think those conversations are among the most valuable sources of insight a Product Manager can have. But I also think many teams quietly struggle because they confuse listening to customers with obeying customers. Those are not the same thing. In fact, some of the most expensive product mistakes I’ve seen started with good intentions and customer feedback.
A customer asked for something. Then another customer asked for it. Soon the request appeared in planning meetings, roadmap discussions, and executive reviews. Momentum built quickly because it felt customer-driven. Yet I’ve lost count of how many times a feature that customers passionately requested became a feature they barely used.
Two often-quoted ideas, one from Theodore Levitt and other from Henry Ford whether historically accurate or not, capture this tension well: “If I had asked people what they wanted, they would have said faster horses.” and “People don’t want to buy a quarter-inch drill. They want a quarter-inch hole.” Both point to the same uncomfortable reality. Customers usually describe the solution they can imagine, while the value they need sits underneath it.
So do customers ask for what they’ll actually buy? The longer I’ve worked in Product Management, the more I’ve realized that customers often describe solutions when they should describe problems.
A few years ago, I found myself in a familiar situation while working with healthcare customers using a speech recognition solution. Several customers kept asking for more customization. They wanted additional voice commands, more options for configuring workflows, greater control over templates, and more ways to adapt the experience to specific clinical environments. The demand sounded consistent. Sales teams supported it. Customers were vocal. Internally, it felt irresponsible not to prioritize it. Then I sat through a series of conversations that changed my perspective. One customer spent thirty minutes talking about a feature and five minutes talking about the problem. Almost every discussion revolved around commands, configuration, and flexibility. Very few began with the clinical outcome.
Instead of moving directly into solution mode, I tried to apply Michael Bungay Stanier’s Coaching Habits where I stay curious a little longer and rush to action and advice giving a little slower. I began with a simple kickstart question: “What’s on your mind?” When I received the first answer, I followed with: “And what else?” Then came the question that changed the conversation: “What is the real challenge for you here?” The concern wasn’t really the number of voice commands. Clinicians were worried about whether speech recognition would behave predictably across their workflows. They worried about text appearing in the wrong place. They worried about interruptions during documentation. They worried about correcting mistakes under time pressure. They worried about losing confidence in the solution when they needed it most.
The conversation changed once we stopped discussing features and started discussing risk. They asked for more commands, but what they needed was confidence. They asked for customization, but what they wanted was predictability. The request wasn’t wrong. It was incomplete. The most important part of the request was often the part that wasn’t said.
What’s fascinating is how often this pattern repeats. I’ve seen customers insist a feature was mandatory and then barely use it after launch. I’ve seen prospects reject genuinely innovative capabilities while enthusiastically purchasing something more ordinary. I’ve watched teams spend months implementing competitor-parity features only to find adoption barely registering. At the same time, I’ve seen improvements to reliability, supportability, and operational simplicity become deciding factors in major customer conversations.
That’s why I increasingly believe one of the biggest myths in Product Management is the belief that customers buy features. They usually don’t. People rarely purchase features. They purchase outcomes. The quarter-inch drill matters only because someone needs the quarter-inch hole, and even the hole may only be a step toward a larger outcome they are trying to achieve.
In enterprise environments, customers often purchase something even more fundamental than an outcome. They purchase certainty. Enterprise buyers often purchase confidence more than capability. Buying conversations may begin with innovation and product differentiation, but they often move toward implementation plans, support models, compliance requirements, reliability expectations, migration concerns, operational readiness, and service levels.
The feature discussion may get everyone into the room, but the risk discussion often determines whether the deal closes. Customers don’t buy roadmaps. They buy confidence that their business won’t break. That is especially visible in healthcare, where a capability can be impressive in a demo but still create hesitation if customers are uncertain about how consistently it will fit into a clinician’s day. The most innovative capability does not automatically become the most valuable one. Sometimes the quieter promise of dependable performance matters more. Reliability frequently beats innovation.
This creates an uncomfortable tension inside Product Management. If we build everything customers request, we risk building a collection of symptoms instead of solving underlying problems. If we ignore customer requests, we lose touch with reality. Customer feedback can be essential and misleading at the same time, which is exactly what makes the role so fascinating. We spend our days trying to understand whether a request represents a genuine market need, a temporary workaround, a procurement checkbox, an organizational constraint, a fear, a risk, or simply a customer’s best guess at a solution.
That is why I’ve come to think of “Why?” as the most important tool in the Product Management arsenal. Not because repeating the word mechanically reveals some hidden truth, but because it keeps the conversation open. The first answer is often about the requested feature. The next answer may be about the workflow. Another answer may expose the risk, constraint, or fear underneath it. Of course, asking “Why?” can sound confrontational if it becomes an interrogation. Questions such as “What’s on your mind?”, “And what else?”, and “What is the real challenge for you here?” create more room for customers to think out loud. They also challenge me to stay curious just a little bit longer and rush to action and advice giving a bit slower.
That is harder than it sounds. Product Managers are conditioned to solve problems. The moment I hear a request, part of my brain starts drafting a requirement or imagining a roadmap item. But acting quickly can create the illusion of customer focus while cutting discovery short. The loudest request is rarely the most important request, and the loudest customer is rarely the most representative customer. What customers said they wanted and what they eventually bought were not always the same thing. That’s why I increasingly view Product Managers less as request collectors and more as translators. My job isn’t merely to hear the customer. My job is to understand what problem would cause someone to make that request in the first place.
The more customer conversations I sit through, the more I notice the gap between what gets discussed and what gets purchased. Customers ask about features. Buyers often evaluate trust. Users ask for functionality. Leaders worry about risk. Clinical teams request flexibility. Healthcare organizations seek predictability. Many buying decisions are emotional decisions disguised as rational ones. Not because customers are irrational, but because uncertainty carries real consequences.
A feature may generate interest. Confidence generates commitment. That’s why I continue to find customer conversations so fascinating. The visible request is usually only part of the story. Underneath it is often a concern, a fear, a constraint, an incentive, or a risk that matters far more than the feature itself. Customers are usually right about their problems and less reliable about the solution.
“Why?” helps me explore that distance, but the value comes from the curiosity behind the question. Can I stay curious just a little bit longer? Can I rush to action and advice giving a bit slower? Can I leave enough room for the problem to emerge before turning it into a feature?
The more customer conversations I have, the more I realize that the feature being discussed is not always the thing being evaluated. Sometimes the real conversation is about confidence, trust, predictability, and risk. Customers rarely ask for what they’ll actually buy. And that tension remains one of the most fascinating and misunderstood realities of Product Management.
This newsletter reflects my personal views and experiences as a product manager. It does not represent the views, strategies, or opinions of my employer or any organization I am affiliated with.
