Customer Interviews Without Leading Questions

Most founders unintentionally coach their interview subjects into agreeing with the product idea they already believe in. The fix is not a longer script, it is a discipline of asking about past behavior instead of future intentions, and resisting the urge to explain your solution before the customer has finished describing their problem.

Why Leading Questions Sabotage Startup Validation

A leading question signals the answer you want before the person has a chance to think. Questions like "Would you use an app that saves you time on invoicing?" almost always get a polite yes, because people want to be agreeable and because hypothetical enthusiasm costs nothing. Nielsen Norman Group's research on interviewing bias explains why phrasing that hints at a preferred answer produces unreliable data, even when the interviewer has good intentions (source).

The deeper problem is that leading questions confirm what you already believe rather than revealing what is actually true. That defeats the entire purpose of talking to customers before you build. If you are still deciding whether an idea deserves engineering time, see our guide on validating app ideas before you invest in development.

Designing Questions That Reveal Real Behavior

The goal of a founder interview is to reconstruct what someone actually did, not what they imagine they might do. Michael Seibel's widely cited essay for Y Combinator on talking to users makes the case that founders should treat every customer conversation like an investigative interview, focused on specifics, not opinions (source).

Use these question types instead of hypotheticals:

1. Ask about the last time it happened. "Walk me through the last time you had to reconcile invoices." This forces a real memory instead of a guess.
2. Ask what they currently use. "What tool or spreadsheet do you use for this today?" Reveals the actual workaround, which is your real competitor.
3. Ask what they tried and abandoned. "Have you tried any other tool for this? Why did you stop?" Surfaces switching costs and prior failed solutions.
4. Ask about cost, not willingness. "What does this problem cost you in time or money right now?" Grounds the conversation in something measurable.
5. Ask them to rank, not rate. "Of these three problems, which is the most annoying this month?" Forces prioritization instead of vague agreement.

A Practical Interview Script Structure

Follow a repeatable structure so every interview produces comparable data.

1. Open with context, not pitch. Ask about their role, team size, and workflow before mentioning your product idea at all.
2. Dig into the problem for at least ten minutes. Resist introducing your solution early. The temptation to explain your app is the single biggest cause of contaminated data.
3. Ask for a specific recent story. Push past "usually" and "sometimes" toward one concrete instance with dates and details.
4. Only then describe the concept, briefly. Present it as one sentence, not a slide deck.
5. Ask what they would need to see before paying. This shifts the conversation from opinion to commitment, which is where testing B2B app pricing before building the product becomes useful as a next step.
6. Close by asking who else has this problem. Referrals from a real interview are a stronger validation signal than the interview itself.

Hypothetical Example

Hypothetical: a founder believes small landscaping companies need a mobile app for crew scheduling. In a leading version of the interview, she asks, "Would you use an app that lets you schedule crews from your phone?" Every owner she talks to says yes, because who would say no to convenience.

In the corrected version, she instead asks, "Walk me through how you scheduled your crews last Monday." Three owners describe a paper whiteboard photographed and texted to a foreman. Two describe a shared spreadsheet edited by only one person because "nobody else remembers to update it." None describe using or wanting a mobile app specifically. The real problem is not lack of an app, it is that only one person can update the schedule and everyone else is working from a stale photo. That reframes the product from "a scheduling app" to "a shared, always current schedule view," which is a narrower and more buildable first version.

This hypothetical illustrates why unscripted, behavior focused questions change what gets built, not just how it gets marketed.

Running the Interviews as a Lightweight Experiment

Treat the interview round itself as a small experiment with a defined stopping point, similar in spirit to a concierge MVP validation experiment. Set a target number of interviews, a consistent script, and a simple rubric for what counts as a strong signal versus a weak one before you start, so you are not tempted to reinterpret ambiguous answers as validation after the fact.

Tradeoffs to Weigh

• Structured scripts vs. open conversation. A tight script produces comparable data across interviews but can feel robotic and miss unexpected insights. A loose conversation surfaces surprises but makes patterns harder to compare.
• Interviewing warm contacts vs. cold prospects. Friends and existing contacts are easier to reach but tend to be more agreeable and less representative of a real buyer.
• Speed vs. depth. Ten short fifteen minute calls will surface breadth of problems faster, but five sixty minute calls usually surface the specific workflow detail that changes your build decision.
• Recording vs. note taking. Recordings preserve exact language, which matters for product copy later, but some interviewees speak less freely when recorded.

Common Mistakes

• Pitching before listening. Once you describe your solution, every later answer is contaminated by what the person now thinks you want to hear.
• Asking about the future instead of the past. "Would you use this?" is a guess. "What did you do last time?" is a fact.
• Treating polite interest as demand. Interest costs nothing to express and predicts very little about actual adoption or payment.
• Interviewing only people who already agree with you. Seek out skeptics and non-users, not just enthusiasts in your network.
• Skipping the follow-up question. The first answer is often a summary. The second and third "why" or "can you give an example" question is where the useful detail appears.

Checklist Before You Start Interviewing

• Have you written down what answer would actually change your build decision, before the interview?
• Have you removed any mention of your product idea from the first half of your script?
• Do your questions ask about specific past events rather than general habits or hypothetical futures?
• Have you planned to interview people outside your existing network, not just friendly contacts?
• Do you have a simple, pre-agreed way to score each interview as a strong, weak, or no signal?
• Have you asked every interviewee who else has this problem, to build a referral chain?

If you want an outside team to help translate validated customer interviews into a scoped, buildable first version of your product, talk to us about your project.