How to Run a Customer Discovery Interview That Actually Surfaces Truth

The Discovery Trap: Why Your Notes Are Full of Lies

Most customer discovery interviews are accidentally designed to produce false positives. You show a deck, the prospect says "that looks interesting," and you mark it as a win in the CRM. Then the deal dies four months later because "interesting" is the polite B2B word for "useless."

If you want the truth, you have to stop selling. You also have to stop asking people what they would do in the future. Humans are terrible at predicting their own behavior, but they are very accurate at describing their past pain.

A successful customer discovery interview is a forensic investigation into a specific business process. Your goal is to find the scar tissue. If there is no scar tissue—no hacks, no manual spreadsheets, no budget reallocation, no previous failed attempts to fix it—there is no problem worth solving.

Forget "Would You Use This?"

The biggest mistake a VP of Product or a Founder makes is asking for validation. When you ask "Would you use this feature?", the interviewee wants to be helpful. They say yes.

Instead, look for evidence of past behavior. If you are building a new automated compliance tool for FinTech, don't ask if they want automation. Ask the Head of Compliance to show you the last three SOC2 audits. Ask how many hours the Junior Analyst spent manually pulling AWS logs into an Excel sheet.

Specific beats generic every time. If they can’t point to a specific calendar event or a specific line item in last year's budget related to the problem, you are chasing a ghost.

8 Questions That Force a Reality Check

These questions are designed to move the conversation away from hypothetical praise and toward concrete friction.

1. "What is the manual workaround you’re using for this today?" If they aren't hacking a solution together with Zapier, Airtable, or sheer human willpower, the pain isn't high enough.
2. "Who is the person most frustrated by this process right now?" This identifies the actual end-user. If the Director of RevOps says "everyone," they usually mean "no one." You want a specific name and a specific reason why that person is annoyed.
3. "Where does this sit on your priority list compared to [Project X]?" Always benchmark your problem against their known priorities. If your "must-have" security tool is ranked 6th behind a CRM migration and a hiring freeze, you aren't getting budget.
4. "What was the last tool you bought to try and solve this?" This reveals their "buying DNA." If they spent $50k on a competitor last year and it failed, you need to know why before you pitch.
5. "If I gave you this for free tomorrow, what would be the first hurdle to actually getting it installed?" This surfaces the silent killers: IT security reviews, legal bottlenecks, or lack of API access.
6. "How much did this problem cost the department last quarter in actual dollars or hours?" Don't accept "a lot." Push for a number. A Director of Engineering at a Series B should be able to estimate dev hours lost to tech debt.
7. "What happens if you do absolutely nothing about this for the next six months?" If the answer is "not much," you don't have a product; you have a vitamin.
8. "Who would be the biggest internal skeptic of a solution like this?" This identifies the person who will kill your deal in the final hour. You want to hear their objections now, not in a procurement meeting.

Isolate the "Job to be Done"

I once watched a Founder interview a VP of Sales at a high-growth SaaS firm. The Founder spent 20 minutes explaining how their AI could "optimize the top of the funnel." The VP nodded and smiled.

The interview failed because the Founder didn't realize the VP’s actual "job" wasn't optimization—it was headcount retention. The VP didn't care about a 5% increase in lead flow. They cared about the fact that their SDRs were quitting because their lead routing tool was broken and unfair.

By using BuyerSignal, you can find and compensate these specific roles—like that VP of Sales or a stressed DevOps lead—to get this level of unfiltered, structured feedback before you write a single line of production code.

The "Checkbook" Test

The ultimate goal of discovery is to find out if someone will pay. But in early discovery, you aren't asking for a contract. You are asking for a different currency: time.

At the end of the interview, don't say "I'll follow up." Instead, ask for a measurable commitment. "If we build a prototype of that specific dashboard we discussed, would you be willing to give me 30 minutes next Tuesday to tear it apart?"

A "yes" to a specific time slot is a signal. A "sure, send me an email" is a polite rejection.

Why Technical Founders Fail at Discovery

Technical leaders often fall into the trap of "feature-branching" the conversation. The interviewee mentions a minor inconvenience, and the Founder spends ten minutes explaining how their architecture handles that edge case.

This kills the flow. When an interviewee mentions a problem, your only job is to dig deeper. Use the "Five Whys" or simply sit in the silence. People hate silence; if you wait three seconds after they finish a sentence, they will often volunteer the most honest, unvarnished detail of their day.

To get the truth, you need to talk to people who have no skin in your game. BuyerSignal connects you with verified professionals for structured product-research conversations, ensuring you're getting data from the right people under the right conditions. It is the fastest way to turn your assumptions into a validated roadmap.