How to Run PM User Interviews That Actually Tell the Truth
Most user interviews generate comfortable noise, not signal. The Mom Test, the wall of separation between problem and solution, the forensic timeline technique, behavioral recruiting, and how to synthesize what you find.
By The Cala Voice Team ·Most user interviews feel productive and produce almost no useful information. Users are helpful by default. They want you to succeed. They don't want to waste your time. And so, when you ask them if your idea is good, they tell you it's interesting. When you ask if they'd pay for it, they say probably. When you ask what they think of your prototype, they tell you what they like about it.
None of that is signal. All of it is noise that feels like signal.
The gap between a well-run user interview and a poorly-run one is not enthusiasm or empathy. It is technique. The frameworks in this article are the techniques that separate interviews that tell the truth from interviews that confirm what you already believe.
The Mom Test: The Foundation
Rob Fitzpatrick's The Mom Test (2013) takes its name from a simple diagnostic. Your mom loves you and does not want to hurt your feelings. If you ask her whether your startup idea is good, she will say yes. The test is: would your mom give you an honest answer to this question? If yes, it is a good question. If she would lie to protect you, it is a bad one.
The principle generalizes. Users are not your mom, but they share the same bias toward social comfort. They want the interaction to go well. They don't want to be the person who kills your project. When you ask opinion-seeking questions, you get socially-optimized answers, not true ones.
The Mom Test: Talk to people about their life instead of your idea. Ask about specifics in the past instead of generalities or opinions about the future. Talk less and listen more.
Rob Fitzpatrick, The Mom Test
Three principles follow from this:
Talk about their life, not your idea. The moment you put your idea on the table, the user's attention shifts from their own experience to evaluating yours. Keep the focus on them for as long as possible. You learn more from a user describing their workflow unprompted than from a user reacting to your description of a feature.
Ask about specifics in the past, not generalities or hypotheticals. "Do you think you'd use something like this?" is a hypothetical. What people say they will do and what they actually do are systematically disconnected. "Tell me about the last time you had to do that" produces actual behavior, not a prediction of imagined behavior. Past specifics are evidence. Future opinions are noise.
Listen more than you talk.
The more you're talking, the worse you're doing.
Rob Fitzpatrick, The Mom Test
Bad questions that feel like research:
- "Do you think this would help you?"
- "Would you pay for something like this?"
- "What features would you want?"
- "Do you like this idea?"
Good questions that produce real signal:
- "Tell me about the last time you had to deal with that."
- "How did you handle it? What did you actually do?"
- "What did that cost you, in time, money, or frustration?"
- "What have you already tried?"
The last question is particularly diagnostic. If users have already tried to solve the problem, it is real. If they haven't, it may not be painful enough to warrant a product.
The Wall of Separation
Understanding the Mom Test is straightforward. Applying it consistently requires a structural discipline most teams skip: keeping the problem interview and the solution evaluation completely separate.
The moment you introduce your solution, a user stops being a witness to their own life and starts being a critic of your work. As a witness, they describe their actual experience — uncontaminated, specific, reliable. As a critic, they evaluate something you have created, shaped by your visible enthusiasm, their desire not to discourage you, and the professional context that makes honest criticism feel risky.
These two roles produce fundamentally different information. Witness information tells you what is actually true about the problem. Critic information tells you how a user navigates the social situation of evaluating your idea. The second is nearly useless for product decisions.
The practical rule: complete the problem interview before showing anything. Treat them as two distinct activities that happen in sequence, not simultaneously.
If you must run both in the same session, the structure matters:
- Run the full problem interview until you have what you need.
- Announce an explicit mode switch: "I'd like to shift now and show you something we're working on. What I heard from you just now was really useful. This is a completely separate part of the conversation."
- Reserve the last ten to fifteen minutes for the solution evaluation.
The announcement is not a formality. It resets the user's framing and signals that you are asking a different kind of question. Without it, users carry their witness mode into the critique, softening their feedback; or they carry their critic mode into the witness portion, shaping what they report about their own experience.
For high-stakes decisions, a different day entirely is worth the logistics cost. The cost of cross-contaminated data is higher.
The Forensic Approach: Reconstructing the Struggling Moment
Most interview techniques treat the user as a journalist: someone who can accurately summarize their own experience on request. They cannot. Memory for habitual tasks is reconstructive, not archival. People report what they believe they usually do, not what they actually did last Tuesday.
The forensic approach treats the user as a witness to a specific event and the interviewer as a detective reconstructing that event from available evidence. You are not asking for a summary. You are walking backward through a sequence of actual events.
The starting point is always a specific recent instance: "Tell me about the last time you had to do that. When was it?" Once anchored to a real event, memory becomes far more reliable. Users can often recall surprising detail about a specific occasion that they could not generalize accurately.
From there, the most useful question in the toolkit:
"What happened right before you decided to do that?"
This question surfaces the trigger: the specific circumstance that created the problem. It is the bridge between the JTBD struggling moment and the Mom Test's insistence on past specifics. The trigger is where the job lives. A user who says "I just export to Excel and rebuild the thing manually" is describing a workaround. Asking what happened right before surfaces why: a deadline, a colleague request, a specific data need the tool didn't serve. That context is what the product needs to address.
Push for specifics at every step:
- "When exactly was this?"
- "Who else was involved?"
- "What were you using at that point?"
- "How long did it take?"
- "What did you do when it didn't work?"
The struggling moment is not a single data point. It is a sequence: trigger → search for a solution → consideration of alternatives → decision → outcome. Each step carries information. The alternatives users considered reveal the real competitive landscape. The outcome reveals whether the job was actually done or just approximated.
What to listen for during reconstruction: unexpected detours (the user did something you didn't anticipate), improvised workarounds (they solved it in a way no product designer planned), and moments of visible frustration or embarrassment. Strong emotion attached to a specific moment usually marks a real problem.
Screening for Behavior, Not Characteristics
The most neglected part of the interview process is recruiting. Teams spend significant effort on interview technique and almost none on selecting who to interview. The result is technically well-run conversations with the wrong people.
Demographic screeners recruit by who someone is: marketing manager, mid-sized company, tech-forward industry. They produce users who resemble your assumed persona. They do not reliably produce users who have actually experienced the problem you're trying to solve.
Behavioral screeners recruit by what someone recently did. "Have you tried to automate a repetitive spreadsheet task in the past 30 days?" finds people who just experienced the problem. "Do you work with spreadsheets regularly?" finds people who might have it in theory.
The principle: screen for recency and specificity. Recent behavior is recent experience. Specific behavior indicates specific pain.
| Demographic screener | Behavioral screener |
|---|---|
| Marketing manager at a B2B SaaS company | Someone who built a lead tracking system outside their CRM in the past month |
| Busy professional who travels frequently | Someone who had a flight disruption and rebooked in the past 90 days |
| Early-stage founder | Someone who tried to get customer feedback before building a feature in the past 60 days |
Two additional recruiting principles worth building into your process:
Interview churned users. The most valuable interviews for a mature product are often with people who tried it and stopped. They have already made the decision you are trying to understand. They know exactly what was missing. Retained users can tell you what works. Churned users can tell you what fails.
Five to eight is usually enough. For a well-defined problem space with a reasonably homogeneous user population, five to eight interviews typically surfaces the major patterns. Past that point, each additional interview produces diminishing returns unless you are deliberately sampling across different segments with meaningfully different contexts.
The Filter of Truth: Three Bad Data Traps
Even with good questions and the right participants, three specific failure modes contaminate interview data repeatedly.
The Compliment Trap
Compliments feel like signal. They are not. "This is really interesting" and "I love the concept" are social responses, not product evaluations.
Compliments are the fool's gold of customer development.
Rob Fitzpatrick, The Mom Test
The diagnostic: when you receive a compliment, ask "Can you tell me more about why that would be useful for you specifically?" A user who describes a concrete situation where the feature would have changed their behavior is giving you signal. A user who returns a vague positive without attaching it to a specific experience is giving you noise. The follow-up question separates the two instantly.
The Hypothetical Future
"I would definitely use something like this" is one of the most common and most misleading statements in customer development. What people say they will do and what they actually do is a well-documented divergence. Intentions, especially for novel products, are unreliable predictors of behavior.
The redirect is consistent: bring every hypothetical back to the past. "Have you ever tried to solve this before?" "What did you actually do the last time you hit this problem?" "What tools have you paid for in the past to handle this?" Past behavior is imperfect but far more reliable than imagined future behavior.
Memory Distortion and the "Show Me" Technique
For habitual tasks, people describe what they believe they usually do rather than what they actually did. The reconstruction is often inaccurate in ways the user is not aware of. They are not lying. They are misremembering.
The antidote, when possible, is direct observation. "Can you open your screen and walk me through how you did that yesterday?" eliminates the reconstruction step entirely. Watching a user navigate their actual environment surfaces workarounds, tool choices, and friction points that no amount of questioning would uncover. When screen sharing isn't possible, ask for artifacts: "Do you still have the email? Can you show me the spreadsheet?" Reality beats recall. Observation beats description. Show me beats tell me, every time.
After the Interview: From Raw Data to Usable Insight
The interview is not the hard part. Synthesis is where most discovery processes break down. Teams complete ten interviews, accumulate pages of notes, and then discuss general impressions rather than structured observations. The output is a vague consensus that doesn't survive the first meeting with a skeptical stakeholder, and cannot connect reliably to a product decision.
Two practices that prevent this:
Atomic notes. Document observations at the smallest meaningful unit: one insight per note, attributed to the specific user who produced it. Not "users struggle with onboarding" but "User 3 (operations manager, 8 years experience) rebuilt the import field mapping manually every session because the template didn't preserve her custom column names." Specificity is what makes an insight defensible. It also makes it possible to group and regroup observations across interviews without losing the source.
Insight tagging. Tag each observation by problem area, user type, frequency (how many users mentioned it), and intensity (minor inconvenience vs. expressed frustration vs. visible workaround built around it). Frequency and intensity together tell you what matters most. A problem three users mentioned casually is different from a problem one user had built an entire workaround to solve.
After a batch of interviews, the most productive question to ask the team is not "what did we learn?" It is: what surprised us? Observations that fit your existing hypothesis are confirming. Anomalies are where the real signal usually lives. A finding that requires you to revise a core assumption is worth more than ten findings that confirm it.
Connect what you find back to the discovery process: each validated insight is a candidate opportunity in Torres's opportunity solution tree, ready to be mapped against your desired outcome, explored for solutions, and tested before committing to build.
What to Read and Do Next
The Mom Test by Rob Fitzpatrick is short (around 130 pages) and the single most practical book on customer interviews. For the habit structure that makes user interviews a continuous practice rather than a periodic event, Product Discovery Frameworks covers Torres's continuous discovery model in full. For the struggling moment and timeline interview in the context of JTBD theory, Jobs to Be Done covers the Four Forces and the switching interview methodology.
Cala Voice covers The Mom Test in its audio brief library alongside PM interview guides and framework deep dives. For interview practice, the voice coach lets you work through product sense and user research questions with immediate feedback on the structure and depth of your reasoning.