How to Conduct User Interviews That Reveal Real Insights

Most user interviews are a complete waste of time.

You get on a call with a user, you explain the new feature you’re working on, and you ask them: "Would you use this?" They smile, nod, and say, "Yes, that looks great! I would definitely use that." You write 'Validated' in your Notion doc, you build the feature, you launch it, and absolutely zero people use it.

You just spent thousands of dollars in engineering time building something because a user wanted to be polite to you on a Zoom call.

Your brain loves confirmation bias. If you want to validate your idea, a user interview is the worst way to do it. You don't use interviews to validate; you use interviews to discover.

Here is how you actually learn something.

The Problem with Hypotheticals

The easiest way to ruin a user interview is to ask a hypothetical question.

Human beings are terrible at predicting their own future behavior. If you ask someone if they will go to the gym next week, they will say yes. If you look at their location data for the last six months, they haven't been once.

When you ask a user "How much would you pay for this?" or "Would you use this dashboard to track your metrics?", they answer based on their idealized self—the version of themselves that is perfectly disciplined and always uses new software correctly.

You must root your questions in the past.

Instead of "Would you use a dashboard to track this?", ask "Can you show me exactly how you tracked this metric last week?" If they didn't track it last week, they aren't going to suddenly start tracking it just because you built a dashboard. The pain isn't acute enough yet.

The Anatomy of an Insightful Interview

If you want to extract actual signal from a conversation, follow a few basic rules of physics for interviewing.

1. Shut Up

The ratio of talking should be 90% them, 10% you. Most PMs are incredibly uncomfortable with silence. When a user pauses, the PM jumps in to fill the void, usually leading the witness. "So you mean that it was frustrating, right?" Stop. Let the silence hang. People hate awkward silence, and they will eventually fill it by giving you the deepest, most unfiltered truth they have just to keep the conversation moving.

2. Dive into the Anomalies

When a user tells you they do something weird, do not brush past it. If they print out a digital report, scan it, and email it to their boss—stop the interview. Dig into that. “Wait, you printed it out? Walk me through why.” Anomalies and weird workarounds are the neon signs pointing to massive product opportunities.

3. Ask for Examples, Not Generalities

Never accept a generalized statement. If a user says, "Our current software is really clunky," that is not an insight. It's a sentiment.

Follow up with: "Tell me about the specific moment yesterday when you felt it was clunky." Get the details. Were they holding a baby in one arm? Were they in a low-reception area? Were they trying to export ten thousand rows while their manager was screaming at them on Slack? Context is the only thing that matters.

The 5 Whys (Applied Realistically)

You've probably heard of the "5 Whys" framework. It's good in theory, but if you actually just ask "Why?" five times in a row, you sound like a sociopath and the user will get defensive.

You have to disguise the "Why."

Level 1: "I notice you export this to Excel every morning."
Level 2 (Why 1): "Can you walk me through what you do with the sheet once it's exported?"
Level 3 (Why 2): "Ah, you highlight those specific columns. Who usually looks at those highlights?"
Level 4 (Why 3): "And what decision does the VP make based on those highlighted numbers?"
Level 5 (Why 4): "So if those numbers are late, the VP can't allocate budget for the afternoon shift?"

Now you understand the stakes. You aren't just building an export button; you are building a budget allocation engine.

You Are Not the User

This is the hardest pill to swallow. Just because you use the product every day does not mean you understand the user. You are tainted by the curse of knowledge. You know where all the buttons are, you know what the feature roadmap looks like, and you know how the database is structured.

The user knows none of that. They just know they have a problem, and right now, your software is either in the way or out of the way.

Stop trying to confirm your brilliant ideas. Start trying to understand their incredibly mundane reality.

FAQ

How many users do I need to interview?

Nielsen Norman Group says 5 users is enough to find 85% of usability issues. For generative research (discovering new problems), aim for 8 to 12. After about 10 interviews in a specific cohort, you will start hearing the exact same things repeated. That is called the "saturation point." Once you hit it, stop interviewing and start building.

Should I pay users for their time?

Yes. Give them a $50 gift card or a discount on their subscription. Paying them shifts the psychological dynamic—they feel obligated to give you their time and honest attention, rather than doing you a rushed favor.

What do I do if a user gives me a terrible feature idea?

Do not argue with them. Do not explain why it's technically impossible. Say, "That is a really interesting idea. What problem would that solve for you?" Users are terrible at designing solutions, but they are world-class experts at experiencing problems. Ignore their solution; fixate on their problem.