5 min read
On this page

User Interviews

User interviews are the most underused tool in product management. PMs will spend weeks building dashboards, days in planning meetings, and hours arguing about prioritization frameworks — but ask them to spend 30 minutes talking to a user and they will say they do not have time. This is backwards. No amount of analytics will tell you why a user is frustrated. No dashboard will reveal the workaround a user invented because your product failed them. You have to talk to people.

Why Interviews Matter

Quantitative data tells you what is happening. Interviews tell you why. Analytics can show that 40% of users drop off at step 3 of onboarding. They cannot tell you that users drop off because the terminology is confusing, the required integration feels risky, or they simply cannot figure out what the product does.

Five interviews will reveal approximately 80% of usability issues. This is a well-documented finding from research by Jakob Nielsen and Thomas Landauer. The first interview surfaces the obvious problems. The second confirms them and adds new ones. By the fifth, you are hearing the same themes repeated. The return on time investment is extraordinary.

ROI comparison:
  Building the wrong feature: 4-8 weeks of engineering time wasted
  Running 5 user interviews: ~10 hours of PM time invested
  
  5 interviews would have told you the feature was wrong
  before a single line of code was written.

Finding Participants

Who to Interview

Interview people who represent your target user, not your ideal user. You want the messy reality, not the polished case study.

Good interview candidates:
  - Recent signups who did NOT activate (why did they leave?)
  - Active users in their first 30 days (what's confusing?)
  - Power users (what workarounds have they built?)
  - Users who churned (what broke?)
  - Users of competitor products (what do they value?)
  - People who fit your target persona but have never heard of you

Avoid interviewing only happy, engaged users. They will tell you everything is great, which is nice but not useful. The most valuable insights come from users who struggled, failed, or left.

How to Recruit

Internal channels (cheapest, fastest):
  - In-app prompt: "Got 20 minutes? We'd love your feedback." + incentive
  - Support ticket follow-up: "Thanks for reaching out. Would you be
    willing to chat about your experience?"
  - Email to recent signups or churned users
  - Customer success team introductions

External channels (broader reach):
  - UserTesting.com, Respondent.io, or similar recruitment platforms
  - Social media posts in relevant communities
  - Craigslist or local community boards (for consumer products)
  - Conference or meetup attendees

Incentives:
  - $50-100 Amazon gift card for 30-minute interview (consumer)
  - $100-200 for B2B professionals
  - Free month of service or account credit
  - Early access to new features (highly engaged users love this)

Aim for 5-8 interviews per research question. Fewer than 5 risks missing patterns. More than 12 has diminishing returns unless you are segmenting across very different personas.

Writing a Discussion Guide

A discussion guide is your interview playbook. It is not a script — you should not read questions verbatim — but it keeps you on track and ensures you cover the same ground with every participant.

Structure

1. Introduction (3 minutes)
   - Thank them for their time
   - Explain the purpose: "We're learning about how people [do X]"
   - Set expectations: "There are no right or wrong answers.
     We're here to learn from you, not test you."
   - Ask permission to record

2. Context & Background (5 minutes)
   - "Tell me about your role and what a typical day looks like."
   - "How did you first hear about [product/category]?"
   - "What were you trying to accomplish when you started looking?"
   Establish who they are and what their world looks like.

3. Core Questions (15-20 minutes)
   - Open-ended questions about the problem space
   - Walk me through the last time you [did the thing]
   - What was the hardest part?
   - What happened next?
   - Show me how you currently handle [task]

4. Wrap-Up (5 minutes)
   - "Is there anything I should have asked but didn't?"
   - "If you could change one thing about [product/process], what would it be?"
   - Thank them, confirm incentive delivery

Writing Good Questions

The quality of your questions determines the quality of your insights. The cardinal rule: do not lead the witness.

Leading (bad):
  "Don't you think the dashboard is too cluttered?"
  "Would you like it if we added a search feature?"
  "How much do you love our product?"

Open-ended (good):
  "Walk me through how you use the dashboard."
  "When you need to find something, what do you do?"
  "How would you describe your experience so far?"

Specific follow-ups (good):
  "You mentioned that was frustrating. Tell me more about that."
  "What did you try first?"
  "What did you expect to happen?"

Questions to Always Include

"Tell me about the last time you [relevant task]."
  This grounds the conversation in real experience, not hypotheticals.

"What was the hardest part?"
  This surfaces pain points without leading.

"What do you do today to solve this problem?"
  This reveals workarounds, competitors, and the intensity of the problem.

"If you could wave a magic wand, what would be different?"
  This surfaces unmet needs without constraining to your product.

"Who else is involved in this decision/process?"
  This reveals stakeholders and buying dynamics you might not see.

Conducting the Interview

Shut Up and Listen

The hardest skill in interviewing is silence. When you ask a question, wait. Let the participant think. Do not fill awkward pauses. Do not suggest answers. The most valuable insights often come after the participant sits with a question for a few seconds.

Bad interviewer behavior:
  PM: "How do you find the onboarding process?"
  User: "It's... well..."
  PM: "Is it the number of steps? Or maybe the terminology?"
  User: "Yeah, the terminology I guess."
  
  You just put words in their mouth. You learned nothing.

Good interviewer behavior:
  PM: "How do you find the onboarding process?"
  User: "It's... well..."
  [silence, 5 seconds]
  User: "I actually skipped most of it. I just wanted to see if I could
         import my data, and I couldn't figure out how to do that from
         the onboarding flow, so I went to the help docs."
  
  Now you learned something real.

The Interview Is Not a Survey

Do not ask yes/no questions. Do not ask rating-scale questions. Do not ask "would you use X if we built it?" (They will say yes to be polite. It means nothing.)

Survey questions (wrong for interviews):
  "On a scale of 1-10, how satisfied are you?"
  "Would you recommend this to a friend?"
  "Would you pay for this feature?"

Interview questions (right for interviews):
  "Tell me about your experience with [product]."
  "When was the last time you told someone about a product you use?"
  "How do you currently solve this problem, and what does it cost you?"

Follow the Story, Not the Guide

If the participant says something interesting, follow it — even if it is not on your discussion guide. The guide is a safety net, not a railroad track.

Planned question: "How often do you use the reporting feature?"
Participant says: "I don't use reporting. My manager pulls the reports
                   and sends them to me in Slack."

Do not move to the next question. This is gold.
Follow up: "Tell me more about that. Why does your manager pull the reports?"
           "What does the report look like when it arrives in Slack?"
           "Is there anything you wish you could do with that data?"

Take Notes, But Stay Present

Ideally, have a note-taker so the interviewer can focus entirely on the conversation. If you are solo, record the session (with permission) and take minimal notes — just key quotes and moments you want to revisit.

Note-taking format:
  [Timestamp] Key quote or observation
  [03:45] "I actually stopped using it after the first week because
           I couldn't get my team to switch from our spreadsheet."
  [07:20] Showed workaround: screenshots pasted into Confluence
  [12:10] Strong emotional reaction when discussing data export

Synthesizing Findings

Raw interview notes are not insights. You need to synthesize across interviews to find patterns.

Affinity Mapping

After completing all interviews, write individual observations on sticky notes (physical or digital) and group them by theme:

Theme: Onboarding Confusion
  - User 1: "I didn't understand what a 'workspace' was"
  - User 3: "The setup wizard asked for things I didn't have yet"
  - User 4: "I skipped onboarding and went straight to help docs"
  - User 5: "It felt like the onboarding was designed for a bigger company"

Theme: Workarounds for Missing Features
  - User 1: "I export to CSV and do the analysis in Excel"
  - User 2: "We built a Zapier integration to get data out"
  - User 4: "My assistant manually copies numbers into our slide deck"

Theme: Team Adoption Barriers
  - User 2: "I love it but I can't get my team to switch"
  - User 3: "It only works if everyone uses it, and they won't"
  - User 5: "My manager won't approve another tool subscription"

From Themes to Insights to Actions

Theme:   Onboarding is confusing for small teams
Insight: The onboarding flow assumes enterprise-scale use (workspaces,
         roles, permissions) which overwhelms small teams who just want
         to get started quickly.
Action:  Create a simplified onboarding path for teams under 5 people
         that skips workspace configuration.

Theme:   Users export data to do analysis elsewhere
Insight: Our reporting capabilities are not meeting users' analytical needs.
         They value the data but need more flexible analysis tools.
Action:  Investigate: is the gap in visualization, filtering, or export
         formats? Run 3 follow-up interviews focused on reporting workflows.

Presenting Findings

Do not hand stakeholders a 20-page research report. They will not read it. Present the one-sentence research question, top three findings with supporting quotes, and recommended actions. Use direct quotes liberally. A user saying "I literally wanted to throw my laptop" is more persuasive than a PM saying "users expressed frustration."

For most product teams, remote interviews (Zoom, Google Meet) are the practical default. They are good enough for the vast majority of research questions. In-person interviews are richer — body language, physical context, actual workspace observation — but the scheduling overhead limits them to high-stakes research like enterprise contextual inquiry.

Common Pitfalls

  • Asking leading questions — "Don't you think X is a problem?" is not a question, it is a suggestion. Keep questions open-ended and neutral.
  • Talking more than the participant — the 80/20 rule: the participant should talk 80% of the time. If you are talking more than 20%, you are presenting, not interviewing.
  • Asking about future behavior — "Would you use this?" is meaningless. People cannot predict their future behavior. Ask about past behavior: "Tell me about the last time you..."
  • Interviewing only fans — happy users confirm your biases. Churned users, struggling users, and non-users provide the most actionable insights.
  • Not recording — memory is unreliable. Record every interview (with permission). You will miss nuances if you rely on notes alone.
  • Skipping synthesis — individual interviews are anecdotes. Synthesis across interviews reveals patterns. Without synthesis, you act on the loudest voice, not the most common problem.
  • Treating insights as requirements — "A user said they want X" is not a requirement. It is an input. Combine interview findings with quantitative data, business context, and product strategy before making decisions.
  • Doing interviews once and stopping — user research is not a phase. It is a continuous practice. Talk to users every week, not once a quarter.

Key Takeaways

  • Five user interviews reveal roughly 80% of usability issues. The time investment is minimal compared to building the wrong thing.
  • Write a discussion guide with open-ended questions. Never lead the participant toward an answer.
  • Shut up and listen. The participant should talk 80% of the time. Silence is your most powerful tool.
  • The interview is not a survey. Do not ask yes/no questions, rating scales, or hypothetical "would you use this" questions.
  • Synthesize across interviews to find patterns. Individual interviews are anecdotes; patterns are insights.
  • Talk to churned users, struggling users, and non-users — not just your biggest fans. The uncomfortable truths drive the most improvement.