Customer Interviews That Actually Produce Insights
You finish a customer call, scribble some notes, share them in Slack, and a week later nobody can recall what was actually decided or whether anything new was learned. This is the common shape of customer research at small teams. The calls happen, but they don't change anything.
The difference between an interview that changes the roadmap and one that doesn't isn't the customer - it's almost always the questions. Most teams ask the wrong ones, and the wrong questions produce polite, agreeable, useless answers. Below is what we've learned from running these calls ourselves and watching them go right and wrong.
The single biggest mistake
Asking customers what they want.
"Would you use a feature that does X?" - they say yes, to be polite. "Would you pay for Y?" - they say maybe, to be diplomatic. "What would make this product better?" - they generate suggestions that sound plausible but don't reflect any real behavior or need.
The famous Henry Ford line about "faster horses" is overused, but the underlying point is right: customers are great experts on their problems and terrible experts on solutions. Asking them about solutions wastes the conversation; asking them about their problems is where the gold is.
The reframe: ask about past behavior, not future intention
This is the single rule that changes more interviews than any other. Future-tense questions ("would you," "could you see yourself," "if we built") get aspirational answers that don't predict behavior. Past-tense questions ("the last time you," "what did you do when," "walk me through") get factual answers grounded in actual events.
Replace these:
- "Would you use a feature for X?" → "Tell me about the last time you needed X."
- "Would you pay for that?" → "When you tried to solve this last time, what did you end up paying for?"
- "Is reporting important to you?" → "Walk me through the last report you put together."
The structure is from Rob Fitzpatrick's The Mom Test, which is probably the single book that has changed the most teams' interview practice. The principle: if a question is one your mom would say yes to regardless of the truth, the question is wrong. "Would you use a thing that helps you save time?" Yes, mom would say yes. The question is useless.
The Jobs-To-Be-Done frame
The other shift that changes what you hear: stop asking about your product (or your hypothetical product). Ask about the underlying job the person is trying to get done.
Clayton Christensen's JTBD framework has the great quote: "People don't buy a quarter-inch drill. They buy a quarter-inch hole." For your interviews, that means asking about the hole - what they were trying to accomplish - not about the drill - what tool they used.
The structure of a JTBD interview is built around a specific event: a moment when the customer hired some product or workaround to do a job. You reconstruct the timeline of that event in detail:
- When did you first notice you had this problem?
- What were you doing before you started looking for a solution?
- What did you try first? Why that?
- Where did you look? What did you search for?
- What almost-bought options did you consider and reject? Why?
- What finally made you commit to this solution? Who else was involved in the decision?
This reconstruction frequently surfaces things you'd never have guessed - that the real triggering event wasn't a feature need but a deadline, that the search started with a Google query you weren't ranking for, that three other people had to approve the purchase. None of which shows up in a "what features would you like" conversation.
The five questions that almost always work
- "Walk me through the last time you ___." The opener that gets a concrete story instead of a generalization.
- "Why did you do it that way?" Follow-up that probes for the actual decision logic instead of the rationalization.
- "What were you afraid would happen if you didn't fix this?" Surfaces the underlying urgency, which tells you what's actually a "vitamin" vs a "painkiller."
- "Who else cares about this?" Reveals the real decision unit - especially important in B2B, where the person you're talking to is rarely the only one whose approval matters.
- "What did you do in the meantime?" The workarounds people use before they have your tool tell you exactly what your tool is competing against.
Things to skip
Product reveal questions. "What do you think of this mockup?" doesn't tell you anything useful. People are polite about mockups even when they wouldn't use the product. If you need to validate a specific design, run a usability test, not an interview.
Pricing questions, mostly. "What would you pay?" produces noise. The only price signal that means anything is when someone has actually paid for something similar (which is why the JTBD reconstruction matters - it gets you to that fact). For real pricing research, run pricing experiments, not interviews.
Feature lists. "Which of these features matter most to you?" prompts people to pick from your list rather than tell you what they actually need. Their actual needs are almost never the items you listed.
Hypothetical scenarios. "If you had unlimited time, what would you do?" - meaningless. "If money were no object, would you buy this?" - also meaningless. Anchor in actual events.
Note-taking that produces re-readable notes
The other reason interviews don't produce insights: the notes are unusable a week later. A pattern that works:
Two columns. Left column is what they said, as close to verbatim as you can manage - especially direct quotes, in their words. Right column is your interpretation, hypotheses, follow-up questions. The discipline of separating "what they said" from "what I think it means" prevents your interpretation from contaminating the raw data, which lets you re-read the notes later and re-interpret them in light of new evidence.
Tag every note with a topic. After 5 interviews, you can search across the notes by tag and start seeing the patterns. Notion, Coda, or even Google Docs with consistent headers work fine; specialized tools like Dovetail are overkill for fewer than a few hundred interviews per quarter.
The "five interviews" rule
Nielsen Norman Group's classic finding is that ~5 users uncover ~85% of usability issues in a given flow. The same heuristic works for problem-discovery interviews. After 5 conversations with people in the same segment, you start to hear the same things repeated. After 10, you're mostly confirming. After 20, you've badly overspent unless your goal was quantitative.
The practical implication: run 5 interviews, then stop, synthesize, and decide what to do. Don't run 30 interviews and try to summarize at the end - the synthesis gets harder, not easier, and the cost of the last 25 interviews exceeds their incremental value.
The output: a one-page synthesis
After every batch of 5, write a single page. Structure it as:
- Who we talked to (1-2 sentences each, with a tag like "early-stage founder, 5 customers")
- Three things we heard repeatedly (direct quotes where possible)
- Two things that surprised us
- What we're going to do differently (the actual decision the interviews produced)
- What we still don't know (which becomes the agenda for the next round)
If the synthesis doesn't end with at least one concrete decision, the interviews didn't work. Either the questions were wrong, or you weren't actually willing to change anything based on what you heard, in which case stop interviewing.
The compound effect
Five well-run interviews per quarter, with a one-page synthesis, will make a small team feel like it has telepathy about its customers within a year. The compound effect comes from re-reading old syntheses against new ones, watching which hypotheses got confirmed, which patterns persisted, which were one-off noise. Most teams stop noticing they're doing it - they just start being right more often.
The bar to clear, in the end, is small. Talk to five customers. Ask about the past, not the future. Write down what they said in their words. Decide one thing. Repeat next quarter.