How to Run User Interviews That Surface Real Needs

Most teams know they should talk to users. Fewer run interviews that change a single decision. The difference is rarely the script. It is whether you went in to learn or to be reassured. An interview that confirms what you already believed taught you nothing.

Recruit for the job, not the title

The wrong people give you clean, useless answers. Recruit around the job to be done you are studying, not job titles or company logos. If you want to understand onboarding friction, talk to people who signed up in the last month, including the ones who stopped using the product. Happy power users will tell you the product is great. The customer who churned three weeks in will tell you why.

Five to eight interviews per segment is usually enough to hear patterns repeat. You are looking for themes, not statistical significance.

Ask about the past, not the future

The single biggest interview mistake is asking people to predict their own behavior. Would you use this. Would you pay for that. People are generous and wrong about hypotheticals. They say yes to be nice and then never act on it.

Ask about specific recent events instead. Walk me through the last time you tried to export a report. What were you doing right before. What did you do when it did not work. Concrete past stories carry real detail. Hypothetical futures carry flattery. This is the heart of good continuous discovery: grounding every claim in something that already happened.

Stay quiet and dig

You should be talking for a small fraction of the session. Silence feels awkward and pulls more out of people than any clever follow-up. When someone gives a short answer, wait. When they mention a feeling or a workaround, ask why, then ask why again.

Avoid leading questions. Do you find this frustrating plants the answer. How did that feel does not. Never pitch your solution mid-interview. The moment you start selling, the person switches from honest narrator to polite audience, and the data goes flat.

Separate listening from voting

Interviews are for understanding problems. They are weak at deciding which solution to build, because a sample of eight cannot rank a roadmap. Use the interview to find the problem and its shape, then validate demand through a broader channel like a feedback board where many customers can weigh in.

This split matters. A vivid interview quote can stampede a team into building for one articulate person. Pair qualitative depth with quantitative reach before you commit engineering time.

Turn transcripts into tracked signal

The work after the interview is where most learning leaks away. Notes sit in a doc, someone half-remembers a quote in a planning meeting, and the customer never learns anything came of it. Tag interview findings into the same system as your other feedback so themes accumulate across sources.

Kithspark keeps that thread intact. When an interview insight becomes a tracked request and later ships, feedback lineage credits the person who raised it, and an automatic notification tells them their conversation led somewhere. That closing of the loop turns a one-off interview into an ongoing relationship, and it makes the next person far more willing to talk to you.

A short checklist

Recruit for the behavior you want to understand. Ask about specific past events. Talk less than you think you should. Never pitch. Validate demand outside the room. Then feed what you learned into a system that tracks it and tells people when their problem gets solved.