User Interview

What is User Interview?

A user interview is a one-on-one conversation where you ask a real user structured questions about their past behavior, not their opinion of your idea, so you learn how they actually work today.

Nielsen Norman Group defines it plainly: a user interview is a research method where "the interviewer asks participants questions about a topic, listens to their responses, and follows up with further questions to learn more" (NN/g, User Interviews 101). NN/g also draws a distinction worth sitting with: interviews are attitudinal research, capturing self-reported experience, while usability tests are behavioral research, capturing observed action. That gap is exactly why interviews are easy to run badly. People forget details and round up how often they actually do something.

Steve Portigal's "Interviewing Users" is the field's standard text on doing this well. The book's own framing is that interviewing is a skill people assume they have and usually don't, and it walks readers from just gathering data to actually uncovering insight about people (Portigal, Interviewing Users). One reviewer on that same page calls it "a complete guide to interviewing," and the throughline across the book's endorsements is that interviewing is treated as a learnable, disciplined craft rather than a talent you either have or don't.

Rob Fitzpatrick's The Mom Test sharpens the same idea into a rule founders can apply this week: ask what someone actually did the last time this came up, instead of asking them to react to your idea. Fitzpatrick's core argument is that a leading question about a hypothetical feature will get a polite yes from almost anyone, so you should ask about what people actually did rather than what they say they would do (Fitzpatrick, The Mom Test). What Produck cares about is narrower: running interviews so they surface real behavior instead of flattering opinion.

Why it matters for product-market fit

User interviews are the primary tool inside the Product Discovery stage of Produck's loop, Listen, Diagnose, Decide, Ship. Listen is where you capture raw signal, tickets, calls, reviews, DMs. Interviews are where you go get signal on purpose, on a topic you chose, from a person you chose.

The reason interviews sit closer to Diagnose than to passive Listen is that a good interview does more than add a data point. It tests a hypothesis against a real workflow. If a churn ticket says the reporting is confusing, an interview is how you find out whether the person opens that report weekly and gets stuck on one control, or opens it once a quarter and never really needed it. That distinction changes what you build next, and a support ticket alone won't give it to you.

This is also where most teams's PMF process quietly breaks. As we argue in why the standard PMF stack keeps founders guessing instead of deciding, tools built around support tickets or NPS scores are built to log opinions, not to diagnose behavior, so teams end up with a pile of feedback and no clearer read on what to ship. Produck treats the interview as a Customer Development practice: a recurring habit tied to specific accounts and specific hypotheses, not a one-off research sprint. What you learn in an interview should sit alongside your Voice of the Customer data and your usage events, so Decide gets made from a full picture instead of whichever channel was loudest that week.

When it works, and when it doesn't

It works when

• You have a specific hypothesis to test, like a workflow or a drop-off point, rather than an open-ended "tell us what you think."
• You can talk to someone who actually did the behavior recently, not someone describing a hypothetical future use case.
• You ask about the last concrete instance of the problem and let them walk you through what happened.
• You record the conversation and review it later instead of relying on memory, so quotes and details survive into your Diagnose stage intact.

It falls short when

• The interviewer asks leading questions and the participant just agrees to be polite.
• You interview a handful of vocal customers and treat their opinions as representative of your whole base.

How to apply it

1. Pick one specific behavior or drop-off you want to understand, not a general "how's the product going" check-in.
2. Recruit two to four users who recently did that exact behavior, using account or usage data, not a generic newsletter blast.
3. Write four to six open questions anchored to the past ("walk me through the last time you did X") and cut any that ask for an opinion on a feature.
4. Run the interview, take notes on what they did and said verbatim, and resist pitching your roadmap mid-conversation.
5. Log the raw notes in the same place your tickets and usage data live so Diagnose can weigh the interview against other signal instead of trusting it in isolation.
6. Turn the finding into one testable decision for the next Decide cycle, and close the loop by telling the person what shipped because of what they told you.