Interview Guide — The Product Playbook

An interview guide is the one-page plan you bring to a customer interview. It lists what you're trying to learn, the questions you'll ask, and the order you'll ask them in. That's the difference between a conversation that gets you the truth and one that gets you a compliment.

This page is the recipe. The why underneath it, why you interview at all, why past behavior beats hypotheticals, why you listen more than you talk, lives in Talking to Customers. Read that for the mindset. Come here when you've got an interview on the calendar and you need to build the guide.

One thing up front. A guide is not a script. You don't read it word for word with your head down, checking boxes. It's a map you glance at to stay on track while you follow the human in front of you. You wrote it so you could forget it.

What it is, and what it's for

The guide does three jobs. It keeps you focused, so every question ties back to the one thing you set out to learn instead of wandering. It keeps your data clean, so when you ask ten people roughly the same questions, the answer that shows up in eight of ten is a pattern you can trust, not ten anecdotes you can't compare. And it frees you up to listen, because the questions are written down and you're not burning half your brain remembering what to ask next. The guide does the remembering so you can watch their face.

The template

Fill each field in before you talk to anyone.

Theme. One line: what problem space are you exploring? Go narrow. "Agriculture" is too big to ask a useful question about. "How small farmers decide whether to adopt a new irrigation system" is something you can build questions around.
Objective. One sentence: what specifically are you trying to learn? Not "understand the customer," but "understand the barriers small farmers hit when adopting new irrigation tech." Every main question gets measured against this. If it doesn't serve the objective, cut it.
Segment. Who are you talking to, and why them? Define the slice that actually has this problem. Wrong person, clean answers, useless data. Write down the one or two traits that qualify someone.
Intro (3 to 5 minutes). Not questions yet. Build trust. Who you are, what you're exploring, why their answers matter, how long it'll take, and that there are no wrong answers. Ask if you can record, get a real yes, then start recording and confirm the yes again on tape. People don't open up to a stranger who leads with "tell me about a time when." Earn it first.
Warm-up. Two or three easy ones. How long have you been doing this? What got you into it? Low stakes, gets them talking, hands you the context you'll want later for a persona, a sketch of a typical customer in their segment.
Screener. One or two questions that confirm this person can answer what you need. If the answer to "when did you last use a tool like this?" is "never," you found out now instead of forty minutes in.
Main questions. The core set, every one tied to your objective. Build these off your best guess at the customer's journey, the step-by-step path they take to get the job done, and write a question that probes each step. Open-ended, rooted in specific past behavior. Plan four to seven; you won't get to all of them, and that's fine.
Closer. Always the same question: "Is there anything we didn't talk about that you think is important here?" Sometimes nothing. Sometimes the best insight of the day. Then thank them, tell them what's next, ask if they'd look at a prototype later, an early, rough version of what you might build.

What does not go in the guide is your idea. Keep it in your pocket. The moment you describe what you're building, you've biased every answer that follows. The guide is about their life, not your solution.

Good questions are open-ended and rooted in what already happened: "tell me about the last time you did X," "walk me through that," "how did you feel when it failed?" Four kinds quietly poison the well, so keep them out of the guide: leading questions ("how happy were you with that product?"), hypothetical futures ("would you use this if I built it?"), yes/no questions ("do you like this feature?"), and jargon that makes a normal person feel stupid. Talking to Customers breaks down why each one fails.

This approach comes from The Mom Test by Rob Fitzpatrick, the best short book there is on asking questions the right way. Three principles run through it: talk about their life, not your idea; ask about specific past behavior, not hypothetical futures; chase facts and stories, not opinions.

A worked example

A filled-in guide for a made-up project: a team exploring whether to build a tool for people stuck deep in a long job search, the world Dana from the persona and journey map lives in. Illustrative, not a real study.

Theme: How a mid-career job seeker decides where to spend her effort when the search drags on.
Objective: Understand the barriers she hits, and why the search stalls, before building anything to fix it.
Segment: People three or more months into an active job search who've sent 50-plus applications, especially mid-career folks switching industries.
Intro: "I'm researching how people get through a long job search, not recruiting and not selling anything. There are no wrong answers. About 30 minutes. Mind if I record so I don't miss anything?" (Get yes. Record. Confirm yes again.)
Screener: How long have you been searching, and when did you last send an application?
Main questions: each one probes a step in how she actually job-hunts, from finding a posting to living with the silence after.
- Walk me through the last role you applied for. What made you click apply? What did you do right after?
- Tell me about a time you never heard back. What did you do next?
- Think about the last time you considered asking someone in your network for help. Walk me through what happened, or what stopped you.
Closer: "Anything we didn't cover that matters here?" Then thanks, next steps, prototype ask.

The Dana guide above is a made-up project. Here's a real one. On a project I worked on, my team found that farmers felt they had to haggle over the price of seed, almost a ritual, while those same farmers would buy a truck online at sticker without blinking. Nobody planned to ask about trucks. It fell out of one open, past-behavior question, and it changed how we thought about pricing.

When to reach for it, and when not

Reach for an interview guide any time you're about to sit down with a real person to learn about their problem: a new problem space, a feature nobody's tested, a market you don't understand yet. If the goal is a human's actual experience, you build a guide first, and you build it before you build anything else. It's how you find out what's true before you spend money acting on it.

Don't reach for it when the question isn't "what's their experience":

You need numbers, not stories. "How many people abandon checkout on step three?" That's a survey or your analytics. Interviews tell you why; they're terrible at how many.
You want to watch behavior, not hear about it. To see the workaround nobody mentions, go observe the work in person, watching them do it rather than asking them about it. The guide and field observation are partners, not substitutes.
You're past discovery, the early learning phase before you've built anything. Once you've got something to put in front of people, you're testing a prototype, not interviewing for empathy. See the Five-Customer Test.
It's an internal decision with no customer in it. That's a Decision Jam, not a round of interviews.

The guide is for one job: an honest, specific account of how someone actually lives with a problem. When that's the job, build the guide, then go get the truth.

The interview-guide structure here, the theme-to-objective funnel, the intro/warm-up/screener/main/closer sequence, and the questions-to-avoid list, is how Brandon teaches interviewing in his University of Illinois design-thinking course. The core question-asking principles are Rob Fitzpatrick's, from The Mom Test*.*