L'Intervieweur de Découverte Client : Transformez une Hypothèse Produit en Questions Capables de la Réfuter
Pourquoi ce prompt est important
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.
À quoi nous l'utilisons
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.Résultat
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.
La plupart des découvertes clients échouent pour une raison prévisible : les questions demandent aux gens ce qu'ils pensent d'un futur hypothétique plutôt que ce qu'ils ont réellement fait par le passé. « Utiliseriez-vous un outil qui fait X ? » obtient presque toujours un oui poli, car être d'accord ne coûte rien à l'interviewé.
Ce prompt est construit autour du Mom Test — une méthodologie de découverte popularisée par le livre éponyme de Rob Fitzpatrick — qui recadre chaque question autour d'un comportement passé spécifique plutôt que d'une opinion. Au lieu de demander si quelqu'un utiliserait un outil de détection d'épuisement professionnel, le prompt lui demande de raconter la dernière fois qu'un membre de l'équipe s'est réellement épuisé, étape par étape.
La structure en cinq étapes existe parce que les appels de découverte échouent lorsqu'ils sont non structurés. Les questions d'échauffement établissent une relation de confiance. Les questions de validation du problème testent si la douleur est réelle et récente. Les questions sur les solutions de contournement révèlent ce que les gens ont déjà essayé.
Les annotations par question sont le choix de conception le plus important. Chaque question est étiquetée avec exactement ce qu'elle valide ou réfute. Le guide d'interprétation à la fin existe parce que les fondateurs collectent souvent les bonnes données mais les interprètent encore mal.