The interview where the user agrees with your framing is almost always the least useful.
The User Interview That Actually Teaches You Something
A user interview is a conversation with an agenda you do not reveal - the goal is to understand how someone thinks, not to confirm what you already believe. This article covers how to recruit the right person, structure a topic guide, ask questions that teach rather than confirm, and debrief before memory fades.
The Question You Are Not Asking Before You Start
Everyone says they do user research. Most teams run user interviews two weeks before a launch to check whether people understand the copy.
flowchart LR
A[Set Falsifiable Belief] -->|belief named?| G1{Go / No-Go}
G1 -->|Yes| B[Recruit Filter]
G1 -->|No| A
B -->|behavior-based screen?| G2{Go / No-Go}
G2 -->|Yes| C[Topic Guide Check]
G2 -->|No| B
C -->|topics not questions?| G3{Go / No-Go}
G3 -->|Yes| D[First 5 Min Setup]
G3 -->|No| C
D -->|frame set no product pitch?| G4{Go / No-Go}
G4 -->|Yes| E[Debrief Window]
G4 -->|No| D
E[Debrief Within 1 Hour]Before you recruit a single person, write down three things you currently believe about your user or product that could be proven wrong inside a 45-minute conversation. Not three things you want to learn. Three beliefs you hold that the interview could invalidate.
If you cannot name them, you are not doing research. You are doing outreach with extra steps.
This is the actual preparation step. The screener, the topic guide, the logistics - those come after. What you believe right now, written down before any data arrives, is the only thing that separates a learning session from a confirmation session.
Recruiting the Person Who Will Actually Teach You Something
The fastest way to run a useless interview is to recruit the person who is easiest to reach.
A good screener has one job: find someone whose behavior you do not yet understand. That means recruiting against what people have done, not what they say they are or what they prefer. "Do you use home services apps?" is a preference question. "In the last 90 days, how many times have you booked a home service and cancelled or rescheduled it after confirmation?" is a behavior question.
The user who cancelled twice is more interesting than the user who completed ten bookings without friction. You already understand the happy path. You do not understand the exits.
One practical constraint: do not recruit from your own user base exclusively when you are trying to understand why people do not adopt your product. The people who stayed are already selected for tolerating whatever is broken.
Topic Guide Versus Script - The Difference Matters
A script tells you what to say next. A topic guide tells you what territory to cover, in any order, however the conversation wants to go.
Scripts feel safe. They also produce interviews where the PM is half-listening to the user's answer because they are reading ahead to the next question. That half-attention is where the real learning dies.
A topic guide looks like a list of areas, not questions. "Understand how they currently find and vet service providers" is a topic. "How do you find service providers?" is a question that has already decided what matters. The topic leaves room for the user to show you something you did not think to ask about.
Keep the topic guide to five to seven areas. If you cannot cover five areas in 45 minutes with a real person talking freely, you are not asking open questions.
The First Five Minutes Are Setup, Not Data
The first five minutes of an interview are not data collection. They are relationship setup.
Most PMs waste this window by explaining the product or what the session is about. That primes the user to respond as a product evaluator rather than as a person with a life and a problem. The framing you set in the first five minutes determines what kind of answers you get for the next 40.
Instead: explain that you are trying to understand how they think about a domain, not test a product. Tell them there are no right answers. Then ask them to tell you about the last time they dealt with the problem you care about - not in the abstract, but specifically, the most recent time. Start with memory, not opinion.
Memory is anchored. Opinion drifts toward what people think they should say.
Three Question Types That Actually Teach You Something
Show me. When a user describes a process, ask them to show you. Screen share, pull out their phone, walk you through the steps. What people describe and what they actually do are almost always different. The gap between the two is where the product insight lives.
Walk me through. When you want chronology, ask for it explicitly. "Walk me through the last time you booked a home service, from the moment you decided you needed one." This forces the user to reconstruct a specific episode rather than summarize a general pattern. Summaries flatten the friction. Episodes preserve it.
What did you do when. This is the recovery question. "What did you do when that did not work?" forces the user to reveal workarounds, compensating behaviors, and hacks they have built around the broken parts of your product or the incumbent solution. Workarounds are underrated as insight surfaces. Every workaround is a feature request that never made it into a ticket.
The Comparison: Questions That Teach vs. Questions That Confirm
This is the practical difference between the two modes. The left column is what most interviews contain. The right column is what produces usable signal.
| Questions That Confirm | Questions That Teach |
|---|---|
| "Would you use a feature that lets you reschedule your booking?" | "Walk me through the last time something came up and you needed to change a confirmed booking." |
| "How important is trust when choosing a service provider?" | "Tell me about a time you chose one provider over another. What actually made the difference?" |
| "Do you find the current booking flow easy to use?" | "Show me how you would book a service right now, starting from scratch." |
| "Would you recommend this to a friend?" | "Have you recommended this to anyone? What did you say?" |
| "What would make you use this more often?" | "What did you do the last time you needed this and did not use us?" |
| "Do you prefer fixed pricing or variable pricing?" | "Tell me about a booking where the price surprised you. What did you do?" |
The left column produces answers. The right column produces data.
The confirming question tells the user what category of answer you want. The teaching question forces the user to retrieve a specific memory and reconstruct what actually happened.
The Urban Company Example: Interview the Supply Side First
Urban Company - the Indian home services platform operating across Bengaluru, Delhi, Mumbai, and several international markets - is known for a counterintuitive PM onboarding sequence. Before a new PM interviews a customer, they first interview a service professional.
This is not a generosity exercise. It is an epistemics exercise.
A PM who has never spoken to a plumber or a beauty professional about how they experience a booking has a model of the customer interaction that is structurally incomplete. They understand demand. They do not understand supply. When they go into a customer interview, they ask about scheduling convenience, pricing, and quality - the obvious demand-side surface.
A PM who first understands how a professional decides whether to accept a booking, what happens when a customer cancels 30 minutes before, and how the professional manages their own calendar - that PM asks the customer completely different questions. They ask about the signals customers use to indicate they will actually be home. They ask about what happens when the professional arrives and something is wrong. They ask about communication patterns after confirmation.
The insight did not come from a better interview technique. It came from a richer model of the system before the interview started. What you already understand about the problem determines the ceiling on what you can learn from a user.
The Judgment Turn
Here is the uncomfortable position this article will not walk back from.
The interview that feels most comfortable - where the user is agreeing with your framing, nodding at your product ideas, and validating your hypotheses - is almost always the least useful interview you will run.
Comfort in a research session is a symptom. It means your questions already contained the answers. It means the user is being socially cooperative, not intellectually honest. It means you recruited someone who already agrees with your worldview, or you framed the session in a way that made disagreement feel impolite.
The useful interview is the one where the user says something that makes you sit with discomfort for a moment before you can ask the next question. Where they describe a behavior you did not predict. Where the problem they care about is adjacent to the problem you thought you were solving, but not the same problem.
If you finish an interview and your beliefs are intact, ask whether you ran an interview or gave a presentation and waited for applause.
The Debrief Within the Hour
Memory degrades fast. The specific words a user used - not your paraphrase of them - are gone within a few hours. The behavioral surprise that felt important during the session gets smoothed into a confirming narrative by the time you write your synthesis doc.
Debrief within the hour. This means 15 minutes, alone or with a co-interviewer, answering three questions in writing:
- What surprised me - specifically, the thing I did not predict.
- What did they do that they did not describe - the gap between stated and observed behavior.
- Which of my three pre-interview beliefs is now weaker or stronger, and what exactly caused that shift.
These three questions force you to make the learning explicit before your brain retroactively rewrites the session to fit what you already believed. The synthesis doc comes later. This comes immediately.
Key Takeaways
- Write down three falsifiable beliefs before every interview. If you cannot name them, reschedule until you can.
- Recruit for behavior, not for persona - the user who cancelled or churned or worked around your product teaches more than the satisfied user.
- Use a topic guide, not a script. Cover territory; do not execute a checklist.
- The first five minutes set the frame - do not waste them on product explanations or warm-up platitudes.
- Debrief within the hour. The exact words and the unexpected moments are gone by tomorrow.
Related Articles
Before running a user interview, the most important preparation step is:
Make the call in Reps and see how your reasoning holds up.
Make the call