How to analyze customer interviews for signal (with examples)
Quick answer: To analyze customer interviews, ignore the compliments and hunt for evidence: past behaviour, real money spent, and specific pain. A comment counts as signal when the person has already done something about the problem, paid for a workaround, or reorganised their day around it. Everything else ("I love this", "I'd definitely use that", "great idea") is noise. Read every transcript twice, once for what they said and once for what they actually did, and label each line as a real signal, a polite comment, or an open question.
I used to walk out of customer calls feeling great.
People nodded. They said nice things. I heard "yes" everywhere.
Then I would go build, and the yes never turned into money.
The interview was not the problem. My reading of it was. I was scoring warmth as demand, and those are not the same thing.
The reading is the problem, not the interview
Steve Blank has a line I keep coming back to. There are no facts inside your building, so get outside. Founders take the first half seriously. They do get outside. They book the calls, they talk to real people, they fill a doc with quotes.
Then they carry those quotes back inside and quietly bend them into the answer they were already hoping for. The interview was real. The reading of it was wishful.
I have done the exit thing once, sold a company and walked away in one piece. But plenty of that run was me treating warm conversations as proof, and getting away with it more often than I had any right to. I would rather not lean on that same luck a second time.
Compliments are not data
Rob Fitzpatrick wrote a whole book about this, The Mom Test, and the one line I keep coming back to is simple. Opinions about your idea are worthless. Facts about their life are gold.
A compliment feels like progress. It is not. "That sounds really useful" costs the person nothing and tells you nothing. What tells you something is what they have already done about the problem, with their own time and their own money, before they ever met you.
Read the transcript twice
The method I use now is boring and it works.
First pass: read for what they said.
Second pass: read for what they have actually done.
The gold is almost always in the second pass. Go line by line and label each one:
- Signal: a past action, a payment, a workaround, a real cost.
- Comment: a compliment or a hypothetical ("I would", "I'd probably", "that's cool").
- Open: something you still need to test before you can call it.
At the end you are not left with a vibe. You are left with a list of facts.
A quick example
Watch how two lines from the same call read completely differently.
Me: "Would you use a tool that organises your invoices automatically?" Them: "Oh yeah, definitely. That sounds super useful."
That is a comment. Pure noise. It is a hypothetical about the future, and I led them straight to the answer I wanted.
Now the same person, ten minutes later:
Them: "Honestly I spend every Sunday night doing invoices in a spreadsheet I built myself, and last month I paid someone forty euros to clean it up."
That is signal. Past behaviour. Real money. A workaround they built with their own hands. I did not even have to mention my idea to get it.
Same person. Same call. Your job is to keep the second line and quietly delete the first.
The signals worth circling
When I read a transcript now, these are the things I circle:
- Money already spent on the problem, even on a bad workaround.
- A hack or spreadsheet or process they built themselves.
- Time they keep losing, described with a real frequency ("every Sunday").
- A tool they tried and abandoned, and why.
- Emotional charge. People do not get annoyed about problems they do not have.
Notice none of those are about your product. They are all about their life before you showed up.
You are the worst reader of your own interviews
This is the honest part. You cannot read your own transcripts cleanly, because you want the idea to be true. You will round every "maybe" up to a "yes". I do it too, every time, unless I force myself not to.
Two things keep me honest.
First, I separate the recording from the judgement. Export the transcript on the day of the call, then label it a day later, when I am less in love with it.
Second, I get an outside read. Someone who does not care about protecting my feelings. That is literally why we built Foxy to read interview transcripts inside Ventropolis, it pulls the signal from the noise and tells you what an outsider would see, not what you wish the call had said. If you want that objective second read on your own transcripts, that is what Ventropolis is for, and you can see how the validation loop fits around it.
How many interviews before you trust it
You do not need a spreadsheet full of p-values. Patterns show up faster than you think.
If five of your ten conversations describe the same painful workaround, in their own words, without you prompting it, that is a signal you can act on. If ten out of ten have never once done anything about the problem, that is a signal too. Just not the fun one. If you want the actual number I aim for before I call it saturated, I wrote that up in how many customer interviews to validate an idea.
So here is the question for your last batch of interviews. If you strip out every compliment and keep only what people have actually done, what evidence is left?
If the honest answer is "not much", that is still a win. It is a lot cheaper to learn it now than after you have built the thing.
Want an objective second read on your transcripts before you commit months to the build? That is exactly what we made Ventropolis for. What did your customers actually do?
