validation-interview

Category: Browser automation Risk: Unknown Mihir-Bhargav/OmniSkill NOASSERTION

name: validation-interview
description: "Design a customer interview that validates or kills a core product assumption — extracts real purchase intent instead of polite enthusiasm."

/validation-interview

"Do you like this idea?" gets "yes" from 90% of people who have no intention of paying for it. Founder interviews fail not because founders don't talk to customers — they do — but because the questions are pitched forward. They describe the solution, ask for feedback, and hear what sounds like validation. This skill forces you to anchor the interview on the past behavior and current pain that would make someone actually buy, not on hypothetical willingness.

State the Assumption You're Testing

  • Write down the one core belief your business model depends on. Not a feature — the underlying behavioral or market assumption.
  • Example: "Mid-market RevOps teams spend 10+ hours/week manually syncing data between their CRM and data warehouse and would pay to automate it."
  • If you're testing more than one assumption, you're running two interviews. Pick one.
  • What would it look like if this assumption is false? What would you do differently? If the answer is "build something else," this is the right assumption to test.

Question Design — Past Behavior, Not Future Intent

  • Never ask: "Would you use this?" or "Would you pay for this?" — these predict nothing
  • Always ask: "Tell me about the last time you dealt with [problem]. Walk me through exactly what happened."
  • Probe the workaround: "What do you do today when this happens? How long does it take? Who else is involved?"
  • Probe the cost: "What happened the last time this didn't get done well? What was the consequence?"
  • Probe the priority: "Where does this fall on your list of problems right now? What's above it?"
  • One question you must ask: "Have you looked for a solution to this before? What did you find? Why didn't it work?"

Reading the Signals

  • Paying signal: they've already tried to solve this (bought a tool, hired someone, built a spreadsheet, written a script)
  • Curious signal: they think it's interesting but can't point to a specific pain or consequence
  • Polite signal: they're agreeable, offer suggestions, and would never pay — they're helping because you asked nicely
  • Kill signal: the problem exists but is 6th on a list of 8 priorities — real buyers have this as top 3

After 5 Interviews — Pattern Matching

  • How many described the same problem unprompted, in the same words?
  • How many had already attempted a workaround? What was it?
  • What was the consistent language they used? (Their words become your marketing copy)
  • What surprised you — something they care about that you didn't expect?
  • What's the sharpest version of the problem statement that fits all 5?

Go / No-Go Criteria

  • Go: at least 3 of 5 have a workaround today, can name a specific recent consequence, and would introduce you to their boss or a colleague with the same problem
  • Conditional: 2 of 5 meet the above — go back and run 5 more before building
  • No-go: no one has a workaround, consequences are vague, everyone is "curious but not urgent"

Rules

  1. The assumption must be written before the first interview — you cannot define it retroactively after you've heard what people said
  2. No solution pitching in the first 20 minutes — your job is to understand their world, not sell yours
  3. You must ask about past behavior, not hypothetical future behavior, in every question
  4. Silence is a probe — if they stop, don't fill the gap. Let them keep going.
  5. Record or take verbatim notes — your memory will bias toward what confirmed the hypothesis

This interview guide produces a clear go/no-go signal and the exact language your first buyers use to describe their problem — which is also your headline copy.