How to fix user interviews that are not teaching you anything

Bad interviews rarely feel bad. The conversation is warm, the participant recognizes the problem, and the notes contain phrases that sound quotable. The failure appears later, when the team cannot name anything it would build, stop, narrow, or investigate differently because of what it heard.

The usual response is to improve the interview script. That only fixes one of three possible failures. An interview can be uninformative because the questions invite opinions instead of evidence, because the participant is too far from the behavior, or because the team never decided what the conversation should change. The repair depends on which link is broken.

The Mom Test supplies the evidence standard: reconstruct specific behavior before asking people to judge an idea, and treat commitment as stronger than praise. The additional operating rule is to connect that evidence to a pending decision. A conversation teaches you something only when it changes your model or the next move.

Find the broken link before changing the script

A useful interview completes a chain from conversation to evidence to decision. Weak research usually breaks at one transition. If the participant offers reactions but cannot describe a recent event, the evidence link is broken. If they know the policy but not the daily workaround, access is broken. If the notes are detailed but nothing could change the plan, the decision link is broken.

This diagnosis prevents a common waste: collecting more of the same weak data. Ten additional reaction interviews do not repair a behavioral-evidence problem. A better transcript from the wrong participant does not repair an access problem. More research cannot repair a decision no one has defined.

When people give opinions, reconstruct an event

Future-facing questions make the participant predict a situation that does not yet exist. Would you use this? Would it save time? How much would you pay? A sincere answer still depends on imagination, politeness, and an idealized picture of future behavior.

Move backward in time instead. Ask about the most recent occurrence, then reconstruct it in order. What triggered the problem? What was the person trying to accomplish? What did they do next? Which tool, document, or colleague entered the workflow? Where did time, money, risk, or credibility disappear?

The distinction is not that opinions are worthless. They can reveal language, taste, trust, and comprehension. They are simply weak evidence for demand. If the decision is whether a message feels credible, a reaction may be exactly the evidence required. If the decision is whether someone will replace an existing workflow, behavior and commitment matter more.

Workarounds are especially informative because they show that a problem has already defeated inaction. A spreadsheet, manual handoff, support escalation, paid but disliked tool, or repeated search is a trace of importance. If no trace exists, the problem may be infrequent, owned by someone else, or adequately solved. Do not argue the participant into caring; find out which explanation fits.

When access is filtered, move closer to behavior

Sometimes the questions are sound but the participant cannot supply the evidence. A manager may know the outcome but not the workaround. A buyer may understand procurement but never touch the tool. A customer-facing team may summarize complaints while removing the sequence and stakes that made them meaningful.

The solution is not always another interview. Move to the closest available record of behavior: an anonymized artifact, support ticket, usage event, renewal objection, implementation document, or conversation with the person who performs the workaround. These sources are not automatically more truthful, but they reduce the distance between the claim and the event.

Keep access failure separate from weak demand. “The manager could not describe the workflow” does not mean the workflow is painless. It means this participant cannot answer that question. Conversely, a detailed operator story does not prove a buyer will fund the solution. Operator, buyer, approver, and blocker may each hold a different piece of the decision.

When nothing changes, define the update condition first

An interview can contain excellent evidence and still teach the team nothing if no decision is waiting for it. Before the call, write the uncertainty in a form that could be updated. For example: we do not know whether the pain occurs weekly, whether the workflow owner controls budget, or whether the existing workaround is costly enough to replace.

Then write what evidence would move the plan. A recent recurring incident might justify more discovery. A workaround consuming several roles might change the target segment. Repeated satisfaction with the current process might lower the priority. The exact threshold depends on the decision; the important part is agreeing that some observations can change direction.

This also improves note-taking. Preserve the observation before compressing it into an interpretation. “They reconcile three exports every Friday” is evidence. “They need automation” is an inference. Keeping them separate lets someone else challenge the proposed solution without discarding the underlying fact.

Commitment shows whether the conversation can advance

Praise costs nothing. A useful next step costs time, access, money, or reputation. That is why Fitzpatrick treats commitments as stronger signals: they move the research into contact with another constraint.

The commitment should fit the remaining uncertainty. If the workflow is unclear, ask to inspect a sanitized artifact or speak with the operator. If authority is unclear, ask for an introduction to the buyer. If adoption is unclear and the product is concrete enough, define a pilot with an owner and success condition. A premature request for payment can be as uninformative as a compliment because it tests the wrong stage.

A refusal is not automatically rejection. It may reveal privacy limits, timing, authority, or low priority. The point is not to force a yes. It is to make the next source of uncertainty visible.

Reset the next five interviews

Use a small batch to repair the system rather than rewriting the entire research program:

1. Name one decision and the evidence that could change it.
2. Recruit people close enough to the relevant behavior.
3. Reconstruct recent events before describing the idea.
4. End with the smallest commitment that opens the next uncertainty.

After five conversations, review facts and inferences separately. Count recent events, workarounds, costs, stakeholders, and commitments—not compliments. If the evidence changes the target user, the problem, or the next test, the interviews are teaching again. If it changes nothing, diagnose the broken link before scheduling five more.