O Entrevistador de Descoberta de Clientes: Transforme uma Hipótese de Produto em Perguntas Que Realmente Podem Refutá-la
Porque é que este prompt importa
Teams that run discovery interviews with hypothetical “would you use this” questions get false-positive validation on most calls, because friendly interviewees say yes to be agreeable, not because they'd change their actual behavior. That false confidence is what leads teams to spend months building a feature that ships to under 5% adoption — the failure is invisible during discovery and only shows up as a wasted quarter after launch.
Para que o usamos
You're a solo founder or product manager about to run eight customer discovery calls this week to test a new B2B feature idea, and you need a question set that won't just produce polite, meaningless validation.
Prompt
Act as a customer discovery researcher trained in the Mom Test methodology — the practice of asking about a person's past behavior and specific facts rather than their opinions about a hypothetical product.
Context: We are testing a product hypothesis before building anything. The hypothesis is: [YOUR PRODUCT HYPOTHESIS]. The target customer segment is: [TARGET CUSTOMER SEGMENT]. The problem we believe they have is: [PROBLEM YOU BELIEVE THEY EXPERIENCE]. We have not built anything yet and do not want to pitch a solution during these interviews.
Task: Generate 20 open-ended discovery interview questions organized into five stages: (1) warm-up and context-setting, (2) problem validation through past behavior, (3) current workaround and cost exploration, (4) willingness-to-pay and prioritization signals, (5) closing and referral. For each question, add a one-line note explaining what specific part of the hypothesis it is designed to validate or kill.
Constraints:
- No leading questions ("Wouldn't it be great if...", "Do you think you'd use...").
- No hypothetical future questions ("Would you use a tool that...") — these produce false positives. Ask only about specific past instances and actual behavior.
- Do not mention, describe, or pitch our proposed solution at any point in the questions.
- Each question must be answerable with a concrete story, number, or example — not an opinion or prediction.
- Flag at least 3 questions specifically designed to surface a "the problem doesn't actually exist" signal, not just confirmation.
Output Format: A numbered list of 20 questions grouped under the five stage headers. After each question, include a short italicized note in brackets stating what it validates or kills. End with a 2-sentence guide on how to interpret a "good" vs "concerning" pattern of answers across the 20 questions.Resultado
Hypothesis tested: Engineering managers would pay for a tool that detects early signs of team burnout from calendar and Slack activity patterns. Segment: Engineering managers at 50-200 person tech companies.
Stage 1 — Warm-up and context
- Walk me through what a typical Tuesday looked like for you last week. [Establishes baseline routine before asking about anything problem-related]
- How many direct reports do you currently manage, and how has that changed in the last year? [Confirms segment fit — team size and growth rate]
Stage 2 — Problem validation through past behavior
- Tell me about the last time someone on your team burned out or nearly quit. What actually happened, step by step? [Tests whether the problem is real and recent, not hypothetical]
- What was the first sign you noticed, and when did you notice it relative to when it became serious? [Validates or kills the "early detection" premise — if managers only notice after it's severe, early detection has less value]
- Did you see it coming, or were you surprised? [Concerning signal to watch: if most managers say "surprised," the underlying detection problem is real]
- How did you find out — did the person tell you, did someone else flag it, or did you notice yourself? [Kill signal: if peers or HR usually catch it first, our calendar/Slack angle may not be the actual gap]
Stage 3 — Current workarounds and cost
- What do you currently do to keep tabs on how your team is doing, if anything? [Reveals real workaround — spreadsheets, 1:1 notes, gut feel, nothing]
- Have you ever tried a tool or process specifically for this? What happened to it? [Tests whether people have already tried and abandoned similar solutions, and why]
- Walk me through what it cost you — in time, team disruption, or hiring — the last time you lost someone to burnout. [Quantifies the pain in concrete terms, not abstract severity ratings]
Stage 4 — Willingness to pay and prioritization
- What's the last work tool you personally paid for out of your own budget, without approval from above? [Tests actual spending behavior, not stated willingness]
- If you had $500 of unallocated budget this quarter, what would you spend it on first? [Reveals true priority ranking against real budget constraints]
Stage 5 — Closing and referral
- Who else should I be talking to about this? [Referral chain for further discovery]
- Is there anything I should have asked but didn't? [Surfaces blind spots in the hypothesis itself]
How to read the pattern: A good pattern looks like specific, detailed stories volunteered without prompting, plus evidence of money or serious time already spent on workarounds. A concerning pattern is vague answers, no prior spending on anything adjacent, and managers describing burnout as something HR or peers catch first — that combination means the hypothesis needs rework before you write a line of code.
A maioria das descobertas de clientes falha por um motivo previsível: as perguntas pedem às pessoas o que elas pensam sobre um futuro hipotético em vez do que realmente fizeram no passado. "Você usaria uma ferramenta que faz X?" quase sempre recebe um sim educado, porque concordar não custa nada ao entrevistado.
Este prompt é construído em torno do Mom Test — uma metodologia de descoberta popularizada pelo livro homônimo de Rob Fitzpatrick — que reformula cada pergunta em torno de comportamento passado específico em vez de opinião. Em vez de perguntar se alguém usaria uma ferramenta de detecção de esgotamento, o prompt pede que descreva a última vez que um membro da equipe realmente se esgotou, passo a passo.
A estrutura de cinco etapas existe porque as chamadas de descoberta falham quando não são estruturadas. Perguntas de aquecimento constroem confiança. Perguntas de validação de problema testam se a dor é real e recente. Perguntas sobre soluções alternativas revelam o que as pessoas já tentaram.
As anotações por pergunta são a decisão de design mais importante. Cada pergunta é marcada com exatamente o que ela valida ou refuta. O guia de interpretação no final existe porque fundadores frequentemente coletam os dados certos mas ainda os interpretam mal.