๐คCustomer Interviews โ The Basics
The single highest-ROI activity in product management. Almost every PM is bad at it.
Customer interviews are how you build product intuition. PMs who do 100+ interviews a year ship better products and have stronger opinions than PMs who don't. It's also the cheapest research method โ 30 minutes per interview, no budget required.
A great customer interview gets the user talking about real past behavior, not hypothetical preferences. The PM listens 80% of the time, asks open-ended questions, follows up with 'tell me more,' and never pitches the product. The goal is to learn what's true, not to validate what you already believe.
The cardinal rules
- Ask about past behavior, not hypothetical future behavior. "What did you do the last time X happened?" beats "would you use a feature that does X?" Humans are terrible at predicting their own behavior.
- Open-ended questions only. "Tell me about..." or "walk me through..." instead of yes/no.
- Listen 80% of the time. If you're talking more than 20%, you're not learning.
- Don't pitch. The moment you start describing your product idea, the user becomes a focus group, and the data degrades.
- Follow up. "Tell me more about that." "Why?" "What happened next?" Most insights come from the second or third follow-up.
- Take notes after, write up within 24 hrs. Memory degrades fast.
The Mom Test framework
Rob Fitzpatrick's The Mom Test is the bible. Three rules:
- Talk about their life, not your idea. "Walk me through how you handle invoicing today" beats "would you pay for an invoicing tool?"
- Ask about specifics in the past, not generics about the future. "Tell me about the last time you missed a payment" beats "do you ever forget payments?"
- Talk less, listen more. The user has the information; you don't.
The basic interview structure (30 min)
- 5 min: Warm-up. Tell them what you're doing ("I'm trying to understand how teams handle X โ not selling anything"), get them comfortable.
- 15 min: Context questions. Walk me through your typical week. How does X get done today? What's frustrating about it? When was the last time this happened?
- 5 min: Specifically about the problem you're investigating. What did you try? What worked, what didn't? How big a deal is this on a scale of 1-10?
- 5 min: Wrap-up. Who else should I talk to? Anything I didn't ask that I should have?
Don't show prototypes in the first interview. Save that for round 2 once you've understood the problem.
How to find interviewees
- Existing customers. Filter your CRM, ask CS for warm intros, post in your community.
- Cold outreach on LinkedIn. "I'm researching [problem]. 20 minutes of your time, no sales pitch โ happy to share what I learn." Conversion is ~5-10%.
- User testing platforms. UserInterviews, Respondent, Ethnio. $50-150 per session, fast.
- Twitter / Reddit / niche communities. Free, slower.
You want 5-10 interviews per discovery cycle. After 5, patterns emerge; after 10, you're hearing the same things and can move on.
How to take notes
Two columns: observations (what they said, in their words, verbatim if possible) and interpretation (your hypothesis about what it means). Keep them separate. Verbatim quotes are gold โ they make your PRDs vastly more persuasive.
Key frameworks
Ask questions about real past behavior โ questions even your mom couldn't lie to you about.
Keep asking 'why?' to get from surface complaint to root cause. Usually need 3-5 iterations.
Frame the interview around the 'job' the user is hiring your product to do, not the features they say they want.
Real-world examples
Superhuman's CEO Rahul Vohra ran a famously rigorous interview practice โ quarterly cohort interviews to track the 'very disappointed' score from Sean Ellis. The discipline produced product-market fit clarity that informed every subsequent product decision.
Common pitfalls
- โ Pitching the feature instead of listening to the problem.
- โ Leading the witness โ 'don't you think X is frustrating?'
- โ Skipping the writeup โ insights evaporate within 48 hours.
- โ Recruiting only happy customers โ you miss the failure patterns.
- โ Treating one strong opinion as a pattern. Wait for 3+ users to say something before believing it.
Go deeper โ recommended reading
Interview questions (2)
Q1How would you run a customer interview?executionmidโผ
Five things I'd do:
- Set context up front. "I'm trying to learn how you currently handle X. Not selling anything. About 30 minutes." Lowers the user's guard.
- Ask about past behavior, not hypothetical future behavior. 'Walk me through the last time you needed to X' beats 'would you use a feature that does X.'
- Listen 80% of the time. Follow up with 'tell me more' rather than jumping to the next question.
- Resist the urge to pitch. Don't show your prototype in the first interview. Save that for round 2 after you've understood the problem.
- Write up within 24 hours. Verbatim quotes are gold for later PRD writing.
After 5-10 interviews, patterns emerge. After 10+, you're in diminishing returns and should move to either a quant validation (survey) or a prototype test.
Q2A user says 'I'd love a feature that does X.' How do you respond?executionmidโผ
Don't write down 'user wants X.' That's a near-useless data point โ humans say lots of things they wouldn't actually pay for or use.
Instead, dig into the job behind the request. "Tell me about the last time you wished you had something like that. What did you do instead? How did you work around it?" If they can describe a concrete recent instance, the underlying problem is real. If they can't, X is just a vague preference and you should discount it.
Then: "If we built X, what would it replace? How often would you use it?" These follow-ups separate real demand from politeness.