Table of Contents
The most expensive discovery mistake is not building the wrong feature. It is asking users to help design a feature before you understand the situation that made them look for help. I have watched smart product teams turn a 30-minute conversation into a feature-voting exercise, then wonder why their roadmap “validated” beautifully and still missed the real problem.
Generic user interviews often fail because the team arrives with a concept, a prototype, or a backlog item already in mind. Questions such as “Would you use this?” and “Which version do you prefer?” force participants to react to the team’s framing rather than reveal their own reality.
People are poor predictors of their future behavior but excellent reporters of past behavior. A customer may say they want a dashboard, for example, when their actual problem is that three stakeholders send conflicting spreadsheet updates every Friday. Build the dashboard and you may create a cleaner view of a workflow that should not exist at all.
I saw this with a nine-person B2B SaaS team building inventory-planning software. Their product manager asked operations leads whether they wanted “automated reorder alerts,” and eight of 10 said yes; when I reframed the study around recent stockout stories, we learned alerts were not the bottleneck. Buyers were manually overriding reorder suggestions because they did not trust supplier lead-time data, so the team shifted from notification design to data-confidence signals and exception handling.
Usability testing has a different job. It evaluates whether people can understand and use an existing design: can they find the export button, complete checkout, or interpret an error state? An empathy interview happens earlier, when there may be no interface, no concept, and no justified solution direction.
A broader user interview can include solution-focused questions, concept feedback, pricing discussions, or usability tasks. An empathy interview stays grounded in the person’s context, goals, constraints, and lived experience. It is designed to expose the forces behind behavior before the team tries to change that behavior.
An empathy interview is an open-ended, story-based conversation used in design thinking and continuous discovery to understand how someone navigates a real problem today. The goal is not to make participants feel emotionally understood as an end in itself; the goal is to gather credible evidence about what they are trying to accomplish, what gets in their way, and what tradeoffs they already make.
This distinction matters because users rarely arrive with neat problem statements. They describe symptoms: “Reporting takes too long,” “I lose track of requests,” or “The onboarding is confusing.” Your job is to find the sequence beneath the summary: what triggered the issue, what happened next, who was involved, what they tried, and where the cost landed.
Teresa Torres-style continuous discovery works because these conversations are not treated as a one-off research phase that ends when delivery starts. Weekly customer conversations give teams a steady view of changing needs, emerging workarounds, and the difference between a loud request and a repeated opportunity.
In practice, I define an empathy interview as a conversation about a recent or recurring experience, not an opinion about a hypothetical future. If a participant cannot point to a specific moment, move them toward one. “Tell me about the last time” is usually more valuable than “How do you generally feel about.”
A strong empathy interview has enough structure to keep the conversation useful and enough flexibility to let an unexpected story change your understanding. I start with the participant’s role and goals, then narrow into a recent relevant event, then follow the decisions, tools, people, and friction inside that event.
Do not treat the guide as a script. When someone says, “I had to chase the finance team again,” that is not a transition point to your next planned question. It is an invitation to ask what “again” means, what they had already tried, why finance became involved, and what happened when the request stalled.
The chronology is not bureaucratic detail. It prevents participants from giving polished retrospectives that smooth over contradictions. A person may say a workflow is easy, then describe six browser tabs, two Slack channels, a copied spreadsheet, and a weekly reminder from their manager; the story is the evidence, not the summary.
On a consumer subscription product, I once ran interviews after a four-person growth team saw a 22% drop between trial activation and first saved project. We had only five days before a planning meeting, and the team wanted to test new onboarding screens immediately. Eight empathy interviews showed that users were not confused by setup; they were waiting for a colleague to send source materials, so the team built a lightweight sample-project path instead of redesigning the entire flow.
The best questions invite detail without suggesting an answer. They ask participants to replay reality, not collaborate on your roadmap. When researchers ask, “Would it help if we added…?” they may get enthusiastic feedback, but they lose the chance to learn whether the proposed feature addresses a meaningful problem.
Follow each answer with prompts that make the account concrete: “Can you show me what you mean?” “What happened next?” “How often does that occur?” “What made that difficult?” Silence also helps. Participants often fill a three-second pause with the detail they initially skipped.
Avoid asking what features they want, what they would pay for, or whether they like your idea until you have a clear behavioral picture. You can discuss aspirations near the end, but label them correctly: aspirations are inputs for opportunity mapping, not proof of demand.
I also avoid “why?” as a default probe. It can sound accusatory and pushes people to rationalize. “What led you to do that?” or “What were you weighing at that point?” produces richer answers and preserves rapport.
One research sprint produces a snapshot; recurring empathy interviews reveal whether the snapshot still holds. The useful cadence is usually weekly customer contact, not quarterly batches of interviews. Even one to three conversations per week can expose whether a problem is persistent, which segments experience it differently, and whether a recently shipped change altered behavior.
That cadence does not mean every conversation needs a researcher in the room. For teams with limited research capacity, I recommend using AI-moderated interviews for repeatable early-discovery conversations, while reserving live research time for sensitive topics, complex stakeholder dynamics, or surprising themes that need expert follow-up.
Usercall is particularly useful here because it combines AI-moderated interviews with deep researcher controls, so I can define the context, probes, and areas that require follow-up rather than accept a generic chatbot conversation. Its research-grade qualitative analysis helps teams synthesize patterns across many interviews, and product teams can place user intercepts at key analytic moments—such as a stalled activation flow or unexpected churn event—to uncover the “why” behind the metric.
The practical takeaway is simple: use empathy interviews before concepts exist, ask for stories rather than predictions, and return to the field often enough to catch changing reality. Discovery becomes reliable when evidence from real experiences—not enthusiasm for proposed features—sets the direction.
Related: Continuous Discovery Interviews: Building an Always-On Research System · Product Discovery Interview Questions · The User Interview Playbook
Usercall runs AI-moderated user interviews that collect qualitative insights at scale, with the depth of a real conversation and without the overhead of a research agency. Usercall is self-serve, so you can start a free trial with no sales call required and establish a weekly discovery cadence without filling a researcher’s calendar.
Related methodology: Cognitive Interviewing · JTBD Interviews
