The Customer Interview Playbook: How to Get Real Answers (Not Polite Ones)
You ask a customer, "So, how do you like the product?"
They say, "It's great, really helpful."
Three weeks later, they cancel.
If you've run a SaaS company for more than a few months, this scene is probably familiar. It's one of the most common — and most expensive — traps in customer interviews: mistaking politeness for insight. Customers aren't lying to hurt you. They're being human. Most people would rather give you a comfortable answer than an awkward truth, especially when you built the thing they're being asked about.
This is the core problem with most customer interviews in B2B SaaS: they're optimised for a pleasant conversation, not for surfacing real pain. And real pain — the kind that makes someone pay, switch tools, or champion you internally — is rarely handed over voluntarily. It has to be drawn out, layer by layer.
This playbook covers why customers default to polite answers, and gives you a repeatable framework — the Pain Funnel — to get past them.
Why Customers Give Polite Answers (Even When They Don't Mean To)
Before fixing the questions, it helps to understand why vague, friendly answers are the default outcome of most interviews:
Social politeness. Criticising your product feels like criticising your effort. Most people soften that blow instinctively, even with strangers.
Forgetting the friction. Humans are bad at recalling minor frustrations unless prompted with a specific moment. "Is it hard to use?" invites a shrug. "Walk me through the last time you got stuck" invites a memory.
Founder bias in the question itself. Asking "Do you like the new dashboard?" already signals the answer you want. People often give it to you, especially in a video call where you can see their face.
Hypothetical optimism. Ask "Would you use this?" and you'll usually get a hopeful yes. Humans are notoriously bad at predicting their own future behaviour — what they say they'd do and what they actually do when the moment arrives are often two different things.
No real stakes in the room. If there's no consequence to answering vaguely, most people will. Specificity takes more effort than a friendly generality, so the brain defaults to the easier option.
None of this means your customers are unhelpful. It means the standard question set — built around opinions and hypotheticals — is the wrong tool for the job. You need questions that anchor people to specific memories, not general impressions.
The Pain Funnel: A 5-Layer Question Framework
Think of a real pain point like something buried at the bottom of a funnel.
Surface-level questions only skim the top. To get to the bottom, you need to move through five layers, each one narrower and more specific than the last.
Layer 1 — Open the Door
Start broad enough that the person doesn't feel interrogated, but anchored in their actual work, not your product.
"Walk me through how your team currently handles [the process your product touches]."
"What does a normal week look like for you in this part of the job?"
This layer isn't about your product at all. It's about understanding their world well enough to know where the friction probably lives.
Layer 2 — Anchor to a Real Moment
This is the single most important shift in the entire framework: stop asking about opinions, and start asking about incidents.
"When's the last time this caused a problem?"
"Tell me about the most recent time you had to deal with this."
If they can't name a specific moment, that's data too — it might mean the pain isn't urgent enough to act on.
Layer 3 — Walk the Story
Once you have a real incident, get the full sequence. Resist the urge to jump to solutions here — you're still gathering evidence.
"What happened right before that?"
"What did you do next?"
"Who else got pulled into it?"
Stories reveal workflow details, hidden stakeholders, and workarounds you'd never uncover by asking direct questions.
Layer 4 — Quantify the Cost
This is where "annoying" gets separated from "expensive." Pain that doesn't cost time, money, or political capital usually isn't worth solving — for them or for you.
"How much time did that eat up?"
"Did that affect anyone outside your team — a customer, a manager, finance?"
"If you added up how often this happens in a month, what would that look like?"
Layer 5 — Probe the Workaround
This is the layer most founders skip, and it's the most revealing one. What someone is already doing about a problem tells you more than what they say they want.
"What have you tried so far to deal with this?"
"What are you using instead right now — even if it's a spreadsheet or a manual process?"
"What would have to be true for you to actually switch tools to fix this?"
If someone has built a duct-tape workaround, cobbled together a spreadsheet, or is paying for a clunky point solution just to patch the gap — that's a far stronger signal than any verbal enthusiasm. People build workarounds for problems that hurt. They don't bother for problems they don't really mind.
Putting It Together: A Sample Exchange
Here's roughly how that looks in a real conversation, compressed:
You: Walk me through how your team handles customer onboarding right now. Them: It's mostly manual — we send a welcome email, then our CS person follows up. You: When's the last time that caused a problem? Them: Actually, last month — a customer went two weeks without hearing from us because our CS person was out. You: What happened after that? Them: The customer almost churned. We had to comp a month and our VP got looped in. You: How much time did that whole situation end up costing your team? Them: Honestly, probably a full week between the apology calls, the internal review, and the fix. You: What have you done since then to make sure it doesn't happen again? Them: We built a backup spreadsheet tracker, but it's clunky and people forget to update it.
Notice what happened: zero opinions about your product were asked for, and yet you now know the trigger, the cost, the stakeholders involved, and the (weak) existing workaround. That's a sales conversation and a product roadmap input rolled into one.
Red Flags You're Getting Polite Answers, Not Real Ones
Watch for these signs mid-interview — they usually mean you've slipped back into surface-level territory:
The answer uses words like "sometimes," "occasionally," or "I guess" without a specific example attached.
You're getting feature requests instead of problem descriptions ("it would be cool if it had X") before you've even established there's a real problem worth solving.
They compliment the idea but can't describe a moment where the absence of it actually hurt them.
You're asking "would you," "could you," or "do you think" — all hypothetical framings that invite hopeful guessing rather than memory.
The 25-Minute Master Interview Guide
The Pain Funnel above assumes you have room to breathe. In reality, when you're interviewing busy C-suite executives or founders in markets like Singapore, London, or San Francisco, you rarely get an hour — you get 25 minutes, if that. The fix isn't a different framework; it's a denser, time-boxed version of the same one, built to extract maximum signal under real time pressure.
Timeline | Focus Area | Essential Questions to Ask |
00:00 - 05:00 | Context & Current Baseline | "What is your main priority for this quarter, and what's standing in your way?""What tools does your team open first thing every morning?" |
05:00 - 15:00 | Behavioural Deep-Dive | "Tell me about the last time you had to deal with [Problem X]. What day was it?""What was the exact workaround you used to get past it that day?""Why hasn't that workaround been automated yet?" |
15:00 - 22:00 | Quantifying the ROI | "If you don't solve this problem by next quarter, what happens to your team's core metrics?""Where does this issue rank on your CEO's priority list—top 3 or bottom 10?" |
22:00 - 25:00 | Commitment Test | "Who else on your leadership team is feeling this specific pain right now?""Can you introduce me to them so I can see if their workflow matches yours?" |
The Takeaway
Customer interviews don't fail because customers are dishonest. They fail because the questions invite politeness instead of memory. Swap your opinion-based questions for incident-based ones, follow the pain down through the funnel, and you'll walk away with something far more useful than validation — you'll have evidence.
For B2B SaaS founders, that distinction is the entire game. Validation feels good in the room. Evidence is what actually tells you what to build next.
If you found this useful, the next post in this series breaks down how to turn these interview insights into a prioritised product roadmap — without just building whatever the loudest customer asked for last.
Ready to Find Your One Thing?
If your demos aren't converting and you’re tired of being compared to competitors on a feature-by-feature basis, let’s talk. I help startup founders bridge the gap between "great product" and "dominant category leader."
Comments