How to Run Customer Interviews That Don't Lie to You

Most founder customer interviews produce flattering nonsense. Here's how to ask questions that surface real signal - and what to do with what you hear.

Published 2026-05-16 · 9 min read

Ask a founder how customer discovery is going and most will say "great - everyone loves the idea." Ask them what they actually heard in their last five interviews and you'll get a paraphrase that sounds suspiciously like a marketing landing page they haven't built yet.

This isn't dishonesty. It's the predictable output of a broken interview process. Most founder customer interviews aren't research - they're validation theater, ritually conducted to confirm a decision the founder already made.

The good news: the fix isn't more interviews. It's better ones. Here's how to ask questions that surface real signal, and how to recognize the signal when you hear it.

Why Your Interviews Lie to You

Your users aren't lying. The interview format is.

The default founder interview looks like this:

"So I'm thinking about building a tool that helps [target user] do [task] more easily. Would you use something like that?"

This question is dead on arrival. It does four things wrong in fifteen seconds:

It pitches the product first, which converts the interview from research to sales without you noticing.
It asks about future behavior ("would you use") which is the least reliable kind of self-report a human can give.
It frames the existing experience as a problem ("more easily") which primes the user to agree there's a problem to solve.
It signals what answer you want - and most people, in conversation with a stranger they like, will give it to them.

The user says "yeah, that sounds useful, I'd probably use that." You leave the call energized. Nothing has happened. You just spent 45 minutes generating noise that confirms an assumption you already had.

The Past-Behavior Rule

The single most important rule in customer discovery: ask about what they did, not what they will do.

Past behavior is real. It happened. It left evidence: calendar entries, Slack messages, browser tabs, charges on a credit card. The user can tell you exactly when they last did the thing because they remember it.

Future behavior is a hypothesis the user has never had to defend with action. They'll say yes to almost anything that sounds reasonable, especially when the questioner clearly hopes they will.

Compare these two questions:

Future-intent question (weak)	Past-behavior question (strong)
"Would you use a tool that helps you keep track of customer feedback?"	"Walk me through the last time you needed to remember what a customer told you three months ago. What did you actually do?"

The first question gets you a polite "yeah, that'd be useful." The second gets you a story: "Oh god, I scrolled through six months of Slack DMs and a Notion page I'd half-finished, and then I just gave up and asked them again on the next call." One of those is data. The other is a compliment.

The Three Questions That Do Most of the Work

You don't need a 20-question script. You need three questions, plus the discipline to follow them with "can you tell me more about that?" until you've heard the actual story.

Question 1: "Walk me through the last time [problem happened]."

This is your opener. You're asking the user to narrate a specific past event. Listen for:

When it happened (recency tells you frequency)
What they tried (their current workarounds - this is gold)
Where it broke down (the exact moment of pain)
What it cost them (time, money, missed opportunity)

If the user says "I haven't really had that problem," that's also data. Believe them. You just learned this person is not your target customer, which is more useful than convincing them they should be.

Question 2: "What did you do about it?"

The workarounds people use to solve a problem today are the most honest measurement of how acute that problem is. If the answer is "I just lived with it," the problem isn't acute enough to build a product around. If the answer is "I bought three different tools and stitched them together with Zapier and it still doesn't work right," you have found a real, paying, motivated buyer.

Listen specifically for:

Existing spend. What are they paying for already to address this? Even partial solutions count.
Workaround complexity. Spreadsheets, manual processes, custom scripts. Every workaround is a vote that the problem is worth solving.
Frequency of failure. How often does their current solution fail them? Once a quarter is not a problem. Once a day is a business.

Question 3: "What would have to be true for you to switch?"

This is the only forward-looking question you should ask, and it's framed as a condition, not a promise. You're not asking "would you buy this?" - you're asking "what's the bar?"

The answer reveals their actual buying criteria, which are almost never what your landing page assumes. "It would have to integrate with our existing CRM." "It would have to be cheaper than what we have." "I'd have to be able to try it without involving my IT team." These are the real constraints. Build around them.

What You Should Never Do in a Discovery Interview

A short list of moves that turn a research conversation into validation theater:

Don't describe your product. The moment the user knows what you're building, they start being polite. If they ask, redirect: "I want to learn more about how you do this today before I tell you what we're thinking - it makes the conversation more useful for me."
Don't lead with the problem. Asking "isn't it frustrating when X?" tells the user that X is the answer you want. Ask open questions and let them name the frustration themselves.
Don't argue with answers you don't like. If the user says "honestly, this just isn't a big deal for us," don't try to convince them it should be. That's the most important sentence in the interview. Write it down. Thank them. Move on.
Don't take vague enthusiasm as signal. "I love this idea" is not signal. "I'd put down a $500 deposit right now to be in the beta" is signal. Until someone trades something real, treat enthusiasm as a friendly nod.

The 20-Interview Minimum

Five interviews don't tell you anything. They tell you what five friendly humans on a Tuesday afternoon thought of a fast-moving conversation. Patterns don't emerge that quickly, and most founders who stop at five are stopping precisely because they've heard what they wanted to hear.

20 interviews is the minimum to start trusting a pattern. By interview 12 to 15, the same problems show up in the same words. By interview 18 to 20, you can predict roughly what each segment will say before they say it. That is when you have a thesis worth building on.

If you find the same answers earlier than that - if interviews 6 through 10 all say something specific and identical, unprompted - you can move sooner. But the bar is "identical, unprompted, across segments," not "three nice people agreed."

What to Do With What You Hear

The artifact of an interview isn't a transcript. It's a structured note that captures:

What problem they're trying to solve (in their words, not yours)
What they're doing about it today (the workaround stack)
What it's costing them (time / money / missed opportunity)
What would have to be true to switch (their buying criteria)
Whether they belong in your target segment (one sentence)

After 10 interviews, sort the notes. Cluster the answers. Look for the segment where all five fields cluster tightest - same problem, same workarounds, same cost, same switching criteria. That cluster is your beachhead. Everyone else is interesting, but they're not who you're building for first.

The founders who do customer discovery well end up with a product that looks weirdly specific - obviously built for exactly one type of buyer. That's the goal. Specificity in early-stage products is not a limitation; it's a moat. Vague products built for everyone are the ones that fail.

What This Looks Like in 1tab.ai

1tab.ai includes a Customer Discovery module that gives you structured interview templates, a place to log past-behavior notes alongside your CRM and product roadmap, and AI-assisted clustering to surface the segments where your evidence is strongest - so the patterns from 20 interviews don't disappear into a Notion page nobody opens twice.

Run discovery that actually decides things →

← Back to Blog