Turn a Product Hypothesis Into 20 Customer Discovery Questions That Actually Validate It
Why this prompt matters
CB Insights lists "no market need" as the single most common reason startups fail, and the root cause is almost always interview questions that quietly lead the witness. A founder who asks "would you use a tool that tracks scope creep?" will get enthusiastic yeses from people who would never actually pay — because agreeing to a hypothetical costs nothing. Founders who build on that false signal often spend six to nine months and a chunk of a seed round before discovering the real answer was no.
What we use it for
You believe freelance graphic designers are losing money to scope creep, and you've booked eight customer interviews for next week before writing a line of code — you need questions that will actually surface whether the problem is real and costly, not questions that make you feel good about your idea.
Prompt
Role: Act as a senior product discovery coach who has personally run hundreds of customer interviews and specializes in catching questions that quietly bias the interviewee toward a "yes." Context: - My product hypothesis: [ONE SENTENCE DESCRIBING WHAT YOU BELIEVE CUSTOMERS NEED AND WHY] - My target customer segment: [WHO SPECIFICALLY YOU THINK HAS THIS PROBLEM] - What I've already built or assumed: [E.G., NOTHING YET / A LANDING PAGE / A ROUGH PROTOTYPE] - My biggest fear about this hypothesis: [THE THING THAT WOULD KILL THE IDEA IF IT TURNED OUT TO BE TRUE] Task: Generate 20 open-ended customer discovery interview questions designed to test whether my hypothesis is true — without ever mentioning or hinting at my proposed solution. Organize the questions into four sections: (1) Problem existence and frequency, (2) Current workarounds and their real cost, (3) Willingness to pay or switch, (4) Questions specifically designed to surface my biggest fear. Constraints: - Never ask a leading or hypothetical question (e.g., "Would you use a tool that..."). Every question must be about past behavior or current reality, never a future intention. - No question may reveal or hint at my proposed solution. - After each question, add a one-line note explaining what a "green flag" answer sounds like versus a "red flag" answer. - Keep every question conversational — something answerable in a sentence or two, not a survey-scale item. Output Format: - Four numbered sections as described above, 5 questions each - Each question formatted as: Q: [question] / Green flag: [...] / Red flag: [...] - End with a 3-sentence interview opening script that puts the interviewee at ease without biasing their answers
Result
Hypothesis: Freelance graphic designers lose significant unpaid hours to scope creep on client projects because they have no lightweight way to track when a project has grown beyond its original agreement.
Section 1 — Problem existence and frequency
Q: Walk me through your last three client projects — how did the actual work compare to what you originally scoped?
Green flag: Specific examples of drift, told with visible frustration or resignation.
Red flag: "Pretty much matched what we agreed" with no hesitation.
Q: Tell me about the last time a client asked for "just one more small thing." What happened next?
Green flag: A concrete story with a dollar or hour cost attached.
Red flag: Can't recall a specific instance.
Section 2 — Current workarounds and their cost
Q: How do you currently keep track of what was originally agreed versus what's been added since?
Green flag: A janky manual system (screenshots, a notes app, nothing at all).
Red flag: A confident, working system they're happy with.
Section 4 — Fear-testing questions
Q: Has a client ever pushed back when you tried to bill for extra work? What did you do?
Green flag: They backed down and ate the cost — describes it as just part of freelancing.
Red flag: They successfully renegotiate scope or pricing every time without friction.
Opening script: "Thanks for making time — I'm trying to understand how freelance designers handle client projects day to day, and there are no wrong answers here. I'm not selling anything; I just want to learn from your actual experience. Can we start with your most recent project?"
Most customer discovery interviews fail for a boring, specific reason: the questions are hypothetical. "Would you use a tool that does X?" gets a friendly yes almost every time, because agreeing to an imaginary future product costs the interviewee nothing. That false-positive signal is why CB Insights consistently finds "no market need" as the top cause of startup failure — founders didn't skip discovery, they ran discovery that was structurally incapable of producing a real no.
Why this prompt is built around past behavior, not future intent
The core design decision here is a hard constraint: every question must ask about something that already happened, never something that might happen. "Walk me through your last three client projects" cannot be answered with a polite hypothetical yes — it forces a real story, or a telling silence. This single constraint eliminates the most common way discovery interviews go wrong.
Why the prompt never lets the AI mention your solution
A close second failure mode is questions that accidentally describe the product being validated. Once an interviewee hears your solution idea, even indirectly, their answers start orienting around whether they like your idea rather than whether they have the underlying problem. The prompt's context fields separate the hypothesis (used to generate relevant questions) from the actual proposed solution (which never appears in the output), so the interviewer can probe the problem space without contaminating the data.
Why green flag / red flag framing matters more than the questions themselves
Good interview questions are only half the job — knowing what a real answer sounds like versus a polite deflection is the other half. Founders new to discovery often collect answers without a framework for judging them, and end up interpreting vague politeness as validation. Attaching a green-flag and red-flag interpretation to every question turns a list of questions into an actual decision-making tool.
Why the fourth section exists
Sections one through three cover standard discovery ground: does the problem exist, how do people cope with it now, would they pay to fix it. Section four is different — it's built from the founder's stated fear, the specific way the hypothesis could turn out to be wrong. Most interview scripts avoid this because it feels uncomfortable to interrogate your own worst-case scenario. That discomfort is exactly why it needs to be a required section rather than an optional one.
How to use this well
Fill in all four context fields honestly before running the prompt — especially the fear field. A vague fear like "maybe nobody cares" produces vague questions. A specific fear like "maybe they've just accepted this as normal and don't see it as worth solving" produces sharp, targeted questions that can actually kill a bad idea in week one instead of month nine.