Listen to Customers, But Listen for the Right Thing
By Ray with my favorite human, Benjamin Scott. Design Brief,
TL;DRUnderstanding the 'why' behind customer behavior is crucial for product leaders, as relying solely on data can lead to misinterpretations and missed opportunities for meaningful product development.
You have more customer data than any team before you. Dashboards, surveys, NPS scores, support tickets. And you still get surprised. A feature you were sure people wanted lands flat. A customer you counted on starts spending less. The numbers said one thing, then real life said another.
The reason is simple. Data shows you what people do. It rarely tells you why they do it. Leaders keep treating a full dashboard like deep understanding, and the two are not the same. What follows is a way to listen that captures the reasons, not just the readings.
Information is not the same as knowing someone
Marcus Collins makes the sharp point that today's marketers have mistaken information for intimacy. You can have mountains of data on a person and still not know what moves them. Their fears, their habits, the story they tell about themselves. That context lives outside your charts.
Think about your own team. You probably know your churn rate to the decimal. Do you know why the customers who left actually left? Not the box they checked on the exit survey, the real reason. If you can only answer the first one, you have information without understanding.
The fix is not more data. It is a different kind of listening, aimed at the story behind the behavior.
Ask the right person the right question at the right level
Mike Gospe lays out a useful shape for this: a pyramid with three layers. At the base, operational feedback from anyone, the day-to-day "my thing broke on Tuesday." In the middle, product tuning with a smaller group who help shape your roadmap. At the top, a dozen business leaders talking about where their world is heading in the next two or three years.
The trap is asking every question at the bottom layer. Surveys and support tickets tell you how yesterday went. They cannot tell you where a customer's business is drifting. Gospe shares a company sure its revenue was safe, until interviews revealed customers were about to buy less because their own supply needs were changing. A survey would never have caught that.
Match the question to the layer. Tactical asks go to the crowd. Strategic asks go to the few people who can actually answer them.
Talk to real users, not the people down the hall
When you do go listen, listen to the right people. Hoa Loranger is blunt that your stakeholders and colleagues are not real users. They are too close to the work to give you honest reactions. Yet teams keep filling research sessions with internal opinion and calling it validation.
Two more traps she names. Leading the witness, where you ask questions that steer people toward the answer you want. And using the wrong method for the question, like running a survey when you needed to watch someone actually use the thing. A survey catches opinions. It misses the moment a person gets stuck.
There is a side benefit here worth naming. When a skeptic on your team watches a real customer struggle, the debate ends. It is hard to argue with someone you just watched fail.
Close the loop or don't bother asking
Gathering feedback and doing nothing with it is worse than not asking. HubSpot frames a clean cycle for this, the A.C.A.F. loop: ask, categorize, act, follow up. That last step is the one teams skip. You collect input, you maybe fix something, and the customer never hears back.
Gospe puts it plainly: if you do not act on what you collect, why ask at all? He pushes for embedding insight into the tools people use to make decisions, not filing it in a report nobody reads. Feed it into your product requirements. Share it wide. Make it a team sport with one clear owner.
Monday move: pick one recent piece of customer feedback, trace what you did with it, and check whether the customer ever found out. If the trail goes cold, you found your gap.
The deep cut
The famous line that Steve Jobs did not listen to customers gets used to dodge research. Ashley McClelland pokes a hole in that myth. Jobs did not ask people to design the product. He worked hard to understand what they actually needed, then led them there.
That is the whole thing. Listening for the why does not mean building whatever customers request. Surface asks are often a guess at a fix for a real problem underneath. Your job is to hear the problem, not just transcribe the request. Infoteam Consulting draws the same line between real needs and surface asks. Data hands you the surface. The why is where the actual product lives.
Three questions for your team
- For the customers who left last quarter, do we know the real reason, or just the box they checked? If it is the box, who is going to go find out?
- Look at our last three research sessions. Were we talking to real users, or to people down the hall who are too close to the work?
- Pick one piece of feedback we collected recently. Did we act on it, and did the customer ever hear back? If not, our loop is broken and we should fix that before we ask for more.



