How to Run User Interviews That Actually Influence Your Roadmap

Most user interviews don't change anything.

The PM goes in with a feature in mind, asks questions that lead toward it, and comes out with quotes that confirm the roadmap they already had. Stakeholders nod. The feature ships. And six months later, adoption is 4%.

The problem isn't that user interviews are a bad method. It's that they're usually run in a way that generates comfort, not evidence.

Here's how to run customer interviews that actually inform what you build.

Before You Schedule a Single Call

The most important question is: what do you not know that would change your decision?

If there's nothing that could come out of an interview that would make you change your roadmap, don't do the interviews. They're not going to help.

Write down one or two genuine unknowns before you design any questions:

• "I don't know whether users actually want weekly digest emails or whether they just said they did because it sounded useful."
• "I don't know whether the problem is finding insights or acting on them."
• "I don't know whether this is a team lead problem or an IC problem."

These are the questions your interview should answer. Everything else is secondary.

Who to Interview

Recruit for the specific segment that has the problem you're investigating — not your easiest-to-reach users.

Avoid: Your most engaged power users (they're atypical), people who already gave you positive feedback (selection bias), or whoever responds to your general email blast first (self-selection).

Target: Users who match the profile of the person you're building for, including people who churned or never converted. Churned users tell you why the product failed them. Non-users tell you what they do instead.

Aim for 5–8 interviews per segment. You'll start hearing the same things by interview 5 or 6 — that's when you know you've reached saturation for that segment.

The Interview Questions That Work

The best user interview questions share three properties: they're open-ended, they focus on past behavior (not hypothetical preference), and they don't mention your product or solution.

Start with context

"Walk me through how you [handled the relevant task] most recently — what happened?"

Not: "How often do you write PRDs?" (closed, self-reported)

But: "Take me back to the last time you had to write a PRD. Walk me through what happened."

Past behavior beats self-reported frequency every time. People are consistently wrong about how often they do things; they're much more accurate about what happened last Tuesday.

Follow every answer with a "why" or "tell me more"

Most interviewers accept the first answer. The first answer is almost always the surface-level explanation, not the real one.

User: "We just don't have a good place to track decisions."

PM: "Tell me more about that. What happens when you need to find a decision that was made?"

User: "Honestly, we don't really look for them. We just make the decision again and hope it's the same."

That second answer is the insight. The first one is the symptom.

Never ask hypothetical preference questions

"Would you use a feature that…?" and "How much would you pay for…?" are almost entirely useless. People are very bad at predicting their own future behavior.

Replace:

• "Would you use a weekly email digest?" → "Tell me about the last time you found out about a change in a project tool — how did you find out?"
• "How valuable would this be?" → "What do you do today when this problem comes up?"

End with the question that often reveals everything

"What have you already tried to solve this?"

The existing workarounds tell you how acute the pain is. If people have built elaborate spreadsheets, created Slack channels, hired a researcher — the problem is real. If they haven't tried anything, it may not actually bother them enough to change their behavior.

How to Run the Call

Keep it 30–45 minutes. Longer interviews don't produce proportionally better insights — people give you their best material in the first half.

Start with 5 minutes of context-setting and relationship building. People talk more honestly once they feel like they're having a conversation, not being evaluated.

Take notes on quotes verbatim, not paraphrased. Paraphrases lose the specific language users use, which is often the most valuable part. "I open it once a week during planning" is more useful than "low engagement" — one tells you exactly when and why, the other tells you nothing actionable.

Record with permission. You'll miss things live.

User Research Analysis: What to Do With 8 Interviews

The raw material from 8 interviews is a lot. The temptation is to write a report. Don't.

Instead, do this:

1. 1Extract every distinct observation — not conclusions, but specific things customers said or did. One observation per sticky note or row.

1. 1Tag by type: pain point, workaround, behavior, outcome they care about.

1. 1Count frequency. How many of your 8 interviews mentioned this? An observation that came up in 6 of 8 interviews is much stronger evidence than one that came up once.

1. 1Look for the pattern that surprises you. The useful insight from user research analysis is almost never the thing you expected to confirm. It's the thing that shows up repeatedly and that you didn't have a hypothesis for.

1. 1Write one sentence per finding: "6 of 8 customers said they only open the tool during sprint planning, not between sessions — this is about pull vs. push, not about content quality."

That sentence is what belongs in your PRD under "customer evidence." Not "customers want email notifications" — but the specific pattern and what it implies.

Common Mistakes in Product Discovery

Leading questions. "Would it help if we sent you a weekly email?" primes the user to say yes. They're being polite, and the feature sounds reasonable. This is not research — it's confirmation.

Asking about features instead of problems. Your job is to understand the problem space deeply enough that you can design the right solution. If users are designing the solution during the interview, you've gone too far.

Too small a sample. One interview is an anecdote. Two is a coincidence. Five or more with consistent patterns is evidence.

Not involving engineering. Have an engineer observe at least two or three interviews. The questions they ask after are better than any user story you'll write. Watching a user fumble with a workaround changes what an engineer builds far more than reading a PRD.

Connecting User Research to Your Roadmap

Customer interview analysis only influences the roadmap if you've built a system for capturing and tracking findings over time. A single set of 8 interviews is a snapshot. What you really want is the ability to ask, "Across all the customers we've talked to in the last six months, how many mentioned X?" — and get a real answer.

Without that, you end up redoing the same research every quarter and reaching the same conclusions.

Use our User Interview Template to capture structured findings from each call, or try PMRead to extract and frequency-rank insights directly from your interview recordings and transcripts.