Listening to Customers

Customers are experts in their own problems. They are not experts in solutions. When a user says 'I want a faster search,' they're describing a symptom — frustration with something in their workflow. The root cause might be poor relevance, too many steps, missing filters, or actual latency. Each of those root causes leads to a completely different solution.

This is the core challenge of product discovery: customers describe what they experience, not what they need. They speak in features ('add a dashboard'), outcomes ('I want to see everything in one place'), or frustrations ('this takes forever'). None of those are requirements. They're signals pointing toward an unmet need.

Your job as a PM is to be a translator. You take the symptom — the feature request, the complaint, the workaround — and you dig until you find the underlying job the customer is trying to accomplish. That job is what you build for. Not the symptom.

There is no single right way to listen to customers. Great PMs build a portfolio of five listening methods — each one surfaces a different kind of signal, and each answers a different question.

Interviews are your highest-signal tool. A well-run 30–60 minute conversation reveals mental models, emotional context, and the stories behind behavior that no other method can capture. They're slow and hard to scale, but nothing else comes close for understanding root causes.

Support data is an underrated goldmine. When customers file tickets, they're describing real pain in their own words — unsolicited, unfiltered, and urgent. The exact language they use is often the most authentic description of their problem.

Product analytics reveal what customers actually do, not what they say they do. Activation rate, retention cohort curves, and funnel drop-off points tell you where problems exist — but not why. That's what interviews are for.

UX insights from session recordings, heatmaps, and usability tests show you where users get stuck without requiring them to tell you. Rage clicks, dead zones, and exit points are the silent signals that quantitative metrics miss.

Surveys scale where interviews can't. NPS, CSAT, and open-ended follow-ups measure satisfaction across your entire user base. The trap: surveys measure stated preferences. Never use them as a substitute for qualitative listening — use them to validate what you've already heard.

Interviews are the highest-signal method — but only if you ask the right questions. Most interviewers talk too much, lead the witness, or ask hypothetical questions that produce useless answers. The TEDW framework fixes all three problems.

TEDW gives you four question starters that keep customers talking in their own words: Tell me about... opens a narrative without leading. Explain how... uncovers the mechanics of their actual process. Describe what... captures the emotional texture of the experience. Walk me through... reconstructs the exact sequence of events step by step.

Pair TEDW with the Mom Test (Rob Fitzpatrick): never ask questions your mom would answer to make you feel good. 'Would you use this feature?' fails — it invites validation. 'Tell me about the last time this cost you time or money' passes — it asks about real, observable behavior. The rule: ask about the past, not the future. Past behavior is something that happened. Future behavior is a guess.

Clayton Christensen's Jobs to Be Done framework is the most powerful lens for interpreting what you hear. The core insight: people don't buy products — they hire them to make progress in their lives. When someone buys a milkshake at 7am, they're not buying a milkshake. They're hiring something to make a boring commute more interesting and keep them full until lunch. The job is 'get me through this commute.' The milkshake is just the best available candidate.

This reframe changes everything about how you listen. Instead of cataloguing feature requests, you're listening for four things:

Situation — the specific context that triggers the need. 'When I'm preparing for a quarterly business review...' or 'When a new team member joins...' The situation defines when the job becomes urgent.

Motivation — what the customer is trying to accomplish in that situation. Not the feature they want, but the progress they're trying to make. 'I want to quickly show stakeholders what's changed...' or 'I want to get them productive without hand-holding every step.'

Desired outcome — how they'll know the job is done. 'So I can walk out of the meeting with budget approved' or 'So I can focus on my own work by day three.' The outcome is the success criterion.

Pain points — the friction, anxiety, and obstacles that make the current situation unsatisfactory. These are the forces that make customers open to switching. 'Right now I have to pull data from three different tools and build the deck manually every time.' Pain points reveal the gap between where customers are and where they want to be.

A well-formed JTBD statement: 'When [situation], I want to [motivation], so I can [desired outcome].' This single sentence contains more product direction than a hundred feature requests.

A customer submits this support ticket:

'I want an AI assistant.'

This is a symptom. Your job is to find the root cause — the real job they're trying to get done.

Before you read on, work through these three questions yourself:

What questions would you ask this customer? Think about what context is missing. What situation are they in? What are they trying to accomplish? What does their current workflow look like?

What job might they be trying to accomplish? Generate at least three different hypotheses. A sales rep might be hiring an AI assistant to draft follow-up emails faster. A developer might want help writing documentation. A manager might want to summarize meeting notes without sitting through recordings. The same four words — 'I want an AI assistant' — could mean completely different jobs.

What evidence would you need to validate your hypothesis? An interview question? A behavioral metric? A prototype test? Knowing what evidence you need is as important as knowing what question to ask.

The point of this exercise: 'I want an AI assistant' is not a requirement. It's an invitation to discover. The PM who ships an AI assistant without asking these questions is guessing. The PM who asks them first is doing discovery.