How to Run a User Interview That Actually Teaches You Something

Most product teams think the hard part of user research is finding people to talk to. The hard part is asking good questions. A bad question can ruin an entire interview. A good question can change your roadmap. The difference is usually small and easy to miss.

A bad question leads the user. It tells them what answer you want. It asks them to predict the future or design your product for you. A good question is neutral. It asks about the past. It pulls out real behavior instead of opinions.

Bad questions and why they fail

Here is a common one. "Would you use a feature that lets you tag insights automatically?" Almost everyone says yes. Saying yes is free and polite. You learn nothing. The question is hypothetical and leading at the same time.

Here is another. "Don't you find your current tool frustrating?" This plants the answer. The user now feels nudged toward agreeing. Even if the tool is fine they may complain to please you.

Here is a third. "How important is speed to you on a scale of one to ten?" People are terrible at rating abstract things. The number feels precise but means almost nothing.

Good questions and why they work

Good questions ground the user in a real moment. "Walk me through the last time you analyzed a batch of interviews." Now the user has to remember something real. You hear what tools they opened. You hear where they got stuck. You hear what they did next.

Try "What were you trying to get done that day?" This surfaces the goal behind the behavior. Goals are stable. Feature opinions are not.

Try "What did you do right before that?" and "What happened after?" These map the workflow around the moment you care about. You learn the context that your product has to fit into.

Rewording a business question into a research question

Teams often walk into interviews carrying business questions. A business question serves your goals. A research question serves your understanding. You have to translate one into the other.

Say the business wants to know "Will people pay for our new reporting feature?" You cannot ask that directly. The user has no idea. Reword it. Ask "The last time you needed to share findings with a stakeholder, what did you do?" Then ask "How long did that take?" and "What was annoying about it?" Now you learn whether reporting is even a real pain. Willingness to pay follows real pain.

Say the business wants to know "Should we build a Slack integration?" Do not ask "Would you want a Slack integration?" Ask "Where does your team talk about research today?" If the answer is Slack you have your signal. If the answer is somewhere else you just saved months of work.

The pattern is simple. Turn the feature into a behavior. Ask about the behavior in the past tense. Let the user lead.

A few rules to keep

Ask one question at a time. Stacked questions confuse people and you lose the thread.

Stay silent after you ask. The best answers come three seconds into the awkward pause.

Follow curiosity over your script. The script keeps you safe. The detours teach you the most.

Record everything so you can listen for what you missed. You will always miss something in the room. Good interviews reward a second listen.

Good interviewing is a skill. It is learnable. Start by cutting your leading questions and grounding every question in a real past moment. The quality of your insights will jump immediately.