Talking to Customers — The Product Playbook

A good interview gets you the truth. A bad one gets you a compliment... or really shitty data.

Of every skill in discovery, this is the one I'd protect first, because it's the one that decides whether everything downstream is built on what people actually do or on what they politely told you they might do. Get this wrong and you don't find out for a year. You find out when the thing you built sits there, unused, and the room goes quiet.

Most people think they're good at this because they've had conversations their whole life. Talking to a customer to learn the truth is not a conversation. It's a craft. And the default way humans talk, the friendly, agreeable, "oh that sounds great" way, is exactly the way that gets you lied to.

Start with their pain, not your idea

I've gotten a lot of my best lessons on customer interviews from a place you wouldn't expect: hostage negotiation.

Chris Voss spent his career as an FBI negotiator, and he wrote a book about it called Never Split the Difference. Read it and you'll notice the whole thing rests on a single idea. The essence of a negotiation is understanding the other person's pain. Not winning. Not convincing. Understanding what hurts, deeply enough that they feel understood. (Jim Camp's Start With No lands in the same place.)

That's the same job as a customer interview. You're not there to pitch. You're not there to win them over to your idea. You're there to understand their pain so well that you could describe their day back to them better than they could.

And there's only one way to actually do that. Ask questions, and listen. That's it. Listening is the skill, not talking. If you walk out of an interview having done most of the talking, you ran a sales call and called it research.

You can't build great products unless you truly understand the pain. So the first move isn't a clever question. It's a decision. This conversation is about their life, not your idea.

There are bad questions

When you were a kid, a teacher probably told you there are no bad questions. Ask anything, explore, learn. Good advice for a classroom.

It's wrong for an interview.

In interviewing, there are absolutely bad questions, and they wreck your data before you even notice. Here are the ones that get people every time:

Leading questions. "How happy were you using that product?" You just handed them the answer. The honest version is "how did you feel when you used it?"
Hypothetical futures. "Would you use this if I built it?" People cannot predict the future. They'll say yes to be nice, and now you've got a green light to build the wrong thing. Worse, you'll believe it.
Yes/no questions. "Do you like this feature?" "Yes." The conversation ends there. You learned nothing.
Jargon. "What methodology did you follow to determine that?" Unless you're talking to a specialist, this either gets you a blank stare or makes them feel stupid, and a person who feels stupid stops being honest.

Notice what every bad question has in common. It's about your idea, your feature, your imagined future. The truth doesn't live there. The truth lives in what they've already done.

The Mom Test

The single best resource I've found for this is a short book called The Mom Test, by Rob Fitzpatrick. The name comes from the premise. Ask your questions the right way and you could get useful, honest feedback even from your own mom, who loves you and wants to tell you your idea is brilliant.

Fitzpatrick's point is that bad conversations don't just fail to help. They actively hurt you, because they hand you a false positive. They convince you you're on the right path right before you over-invest your time, your money, and your team into something nobody wanted. The customers aren't even trying to lie. The questions made it impossible for them to tell the truth.

The fix is a handful of principles I lean on in every interview:

Talk about their life, not your idea. The second you describe what you're building, you've biased them. Keep your idea in your pocket. Ask about how they actually live and work today.

Ask about specific past behavior, not hypothetical futures. This is the one that matters most. What someone has already done is the truest signal you'll ever get about what they'll do next. I get into why over on Past Behavior Predicts Future Behavior. So you don't ask "would you ever buy something like this." You ask "walk me through the last time you bought something like this."

Chase facts and stories, not opinions. "How would you solve this?" gets you a pile of ideas and fluff. People are bad at designing solutions and great at telling you what actually happened to them. Mine the stories.

Here's the difference in practice. The weak version sounds like this. "Would you use an app that tracks your expenses?" Almost everyone says sure. The strong version sounds like this. "Tell me about the last time you checked where your money went this month. Walk me through it." Now you find out they don't track it at all, or they have a spreadsheet they hate, or they checked once in March and gave up. That's data. The first question gave you a wish.

Build your questions off a journey map, then sequence the conversation

A question set isn't a random list. It's built on a map.

Before you ever talk to anyone, you sketch your best guess at the customer's journey, step by step, start to finish. A journey map is just that. It's a step-by-step list of everything the customer does to get from start to finish, written out before you talk to a single person. Say you're building a budgeting tool. Your map might run like this. They realize they're overspending, they go looking for a tool, they try one, they give up after a week. Four steps. Every one of them is an assumption. You don't know any of it is true yet. You made it up from research and your own experience.

So your questions exist to validate, or kill, those assumptions. You walk the person through the journey one step at a time and let them confirm it, correct it, and fill in what they actually felt at each step. The map breaks when they correct a step you guessed wrong, or describe a step you never put on there at all. That break is the prize. It's an assumption you got wrong and didn't know you had.

That's what to ask. Now to what order to ask it in. Structure the conversation so they'll actually open up:

Set up and build rapport. First three to five minutes, no real questions. This part isn't small talk you do before the interview. It is the interview's first job, and it's how you earn the right to ask the hard stuff. Tell them why you're here, what you're hoping to learn and why it matters, how long this'll take, and ask if you can record. Get a real "yes." Then start recording and confirm the yes again on tape. People don't get vulnerable with a stranger who opens with "tell me about a time when." Earn it first.
Warm-up questions. Easy context. How long have you been doing this, what got you into it. Low stakes, gets them talking, gives you the demographics you'll need later when you build personas, your stand-in profiles of a typical customer.
Screener. Make sure this person can even answer what you need. If you're learning about a specific tool, make sure they've actually used it. Talking to the wrong person produces clean, confident, useless data.
Main questions. The core set, built off the journey map, tied to what you're trying to learn. This is the part that does the work.
Closer. Always end the same way. "Is there anything we didn't talk about that you think is important here?" Sometimes you get nothing. Sometimes you get the best insight of the day, or a phone call two days later with the thing they couldn't stop thinking about.

One rule that's easy to break. Don't rewrite the question set after every interview. Adjust after the first one or two, where you're shaking out the obvious flaws. Then hold it steady so you get clean, comparable answers across everyone else.

Make them talk, not you

The mechanics of a great interview are mostly about getting out of the way. A few moves do most of the work.

Silence. Ask your question and shut up. After they finish, count three to five seconds before you say anything. It feels unbearable. Do it anyway. The first answer is never the full answer. The first answer is the surface. That silence is what makes them keep going, and the second thing they say is usually the real thing.

Mirroring. This one's straight out of Voss. They say "the last time I did that, it was so frustrating." You lean in and say "frustrating?" with the inflection going up, like a small question. That's it. They'll tell you exactly what was frustrating, in their own words, and you never had to lead them or even think up a follow-up. Repeating their last few words back is the laziest, most powerful tool you have.

The 5 Whys. This one comes from Toyota, where Sakichi Toyoda used it to dig past a symptom to the real cause on the factory floor. It works the same in an interview. When you hit something that matters, ask why. Then why again. About five times, you hit the root cause. "I gave up on it." Why? "Took too long." Why? "I kept losing track of where I was." Why? And so on, until you're standing at the actual problem instead of the symptom everyone complains about.

Aim for an 80/20 split. They talk 80 percent of the time, you talk 20. If that ratio is flipped, you're pitching, and pitching in an interview never ends well. Save your idea for later, the prototype phase, when you have something real to put in front of them and watch what they do.

And watch for contradictions. Someone tells you they love budgeting apps. Great. What's the last one you used? When? How often? If "I love them" turns into "I opened one once in March," you've found a gap between what they say and what they do. The gap is the truth.

Watch, don't just ask

Here's the part most people skip, and I've watched it save teams from building the wrong thing more than any interview ever has.

Asking gets you what someone can put into words. Watching gets you what they can't.

Let me tell you about a company that thought it knew its customers' biggest pain. The team had done its homework, internally. They'd talked among themselves, mapped the customer's day, written down the problem, and lined up exactly what to build to fix it. They were confident. They had a clear number-one pain point and a plan to automate it away, plus an app to bundle in a few other tasks while they were at it.

Then they did something simple. Instead of staying at their desks, they sent the team out to watch their customers actually do the work. In person, in the field, on a normal working day.

What they saw didn't match what they'd assumed. The thing they were sure was the biggest pain? Customers had already quietly solved it themselves with a workaround so simple it never came up in conversation. It wasn't a pain point at all. The real bottleneck was somewhere else entirely, something the team hadn't been planning to touch. And the slick app they were going to build turned out to be useless in the actual conditions the work happened in. The customers would never have a free hand to use it.

So they stopped. They killed the feature they'd been so sure about. They killed the app. And they took all that energy and money and put it into what actually worked. Training. A simple printed guide to the problems that came up most. Less time guessing in a conference room. More time in the field.

Watching beat asking. If they'd only run interviews, the customers would have nodded along and the team would have built the wrong thing well. All that energy and money, spent on an app nobody could have used with their hands full, shipped clean and useless. Built wrong and built well is the most expensive way to be wrong.

In-person observation is the gold standard for a reason. You see the workaround nobody mentions. You see the step that's secretly the hard one. You see the gloves, the noise, the rush, all the real conditions that make a "great idea" fall apart. When you can't be in the room, a video call gets you the nonverbal cues. A phone call gets you the words and not much else. But if you can possibly go watch, go watch.

After the interview: do the debrief

The interview isn't the work. The interview is the raw material. What you do next is the work, and it's where most teams quit.

Right after each one, while it's fresh, run a quick debrief. The three questions I always ask:

Biggest surprise: the thing that didn't match what you expected going in.
Biggest pain: the moment they got frustrated, gave up, or built a workaround.
Biggest delight: the thing that genuinely worked for them, that you'd be foolish to break.

Then hold it up against your journey map. Which assumptions did the conversation confirm? Which ones did it just destroy? You were about to build on a lie and now you're not.

Here's where AI actually earns its keep in this process. Not in the interview, that's still a human in a room, watching a face. Afterward. It'll summarize a transcript in seconds and spot the same complaint showing up in eight of twelve conversations, a pattern you'd never hold in your head all at once. It does the sorting so you can do the deciding.

Turning a stack of these debriefs into a single clear insight is its own skill, and it's the step after this one. (That's Synthesis, where the wall of notes becomes something you can actually decide on.)

The point

You can't help someone you don't understand. And you can't understand someone by asking them to predict the future or rate your idea on a scale of one to five.

You understand them by asking about what they've already lived, listening more than you talk, and going to watch when watching will tell you something the words won't. Be curious about their actual day, not eager to validate your plan.

Do that, and the interview gives you the truth. The real pain, the real workaround, the real reason something failed before you ever showed up. Everything else in discovery gets built on those. For the why underneath all of this, the discovery mindset this serves, read Design Thinking & Experimentation when you want it. You don't need it first. This page stands on its own.

A compliment feels good in the room. The truth is what keeps you from building the wrong thing. Go get the truth.