Use Product Discovery Prover with your AI.

Validate product discovery

You must: (1) PROBLEM EVIDENCE. cite specific evidence the problem exists AT SCALE. User interviews (30+ where THEY raise the pain), search volume, forum posts, support tickets, existing spend on workarounds. "I think people need this" is not evidence, (2) SEGMENT. define the customer by BEHAVIOR, not demographics. Current capability, rejected alternatives, workflow friction, scale of operations, (3) COMPETITORS. test every competitor's product for real tasks for at least 1 week. Document strengths, gaps, switching costs, and lock-in. "No competition" is a red flag, (4) PURCHASE INTENT. show evidence of MONEY commitment, not interest. Pre-orders, LOIs, pilot agreements, current workaround spending. Compliments ≠ data, (5) MVP SCOPE. state the core hypothesis, the minimum experiment to test it, success metric with threshold, and timeline (1-4 weeks). If it takes more than 4 weeks, it is not minimum. If rejected, your product thinking has a blind spot. Fix it before building. Structured reflection capability for product discovery validation. forces evidence-based problem validation, behavioral segmentation, hands-on competitor testing, purchase intent verification, and hypothesis-driven MVP scoping before any "build it" recommendation. Based on Lean Startup (Ries 2011), Jobs-to-be-Done (Christensen 2016), and The Mom Test (Fitzpatrick 2013). Catches Solution-Seeking-Problem (building a technology then searching for someone who needs it. "We built an AI that generates color palettes from text descriptions." Cool technology. Now: who has this problem? Designers? They already have Coolors, Adobe Color, and trained color intuition. Non-designers? They use templates with pre-made palettes. Developers? They copy colors from designs they admire. 47 customer discovery interviews: 0 interviewees described color palette generation as a pain point they would pay to solve. The technology is impressive. The problem does not exist at scale. Start with the pain. not the technology. Evidence of pain: "I spend 3 hours every project choosing colors and my clients always reject them". THAT would be worth exploring), Segment Vague (describing the customer by demographics instead of behavior. "Our target market is small businesses." There are 33 million small businesses in the US alone. A bakery in rural Iowa and a fintech startup in Manhattan are both "small businesses." They have nothing in common. Behavioral segmentation: "Solo accountants who use spreadsheets for time tracking, have tried and abandoned FreshBooks within 30 days, and bill fewer than 20 clients per month at hourly rates." Now you know: their current capability (spreadsheets), their rejected alternative (FreshBooks), their scale (< 20 clients), their pricing model (hourly), and their pain (manual tracking). This segment can be found, reached, and converted. "small businesses" cannot), Competitor Blind (listing competitors without testing their product. "Competitor A has a clunky UI." Have you used it? For how long? "Competitor B lacks integrations." Which integrations? Did you check their API docs? Sign up for every competitor. Use them for real tasks for at least 1 week. Document: what they do well (because customers stay for a reason), what they do poorly (the gap your product must fill), switching cost (what a customer loses by leaving them), and lock-in mechanisms (data export, contract terms, integrations that break). If switching cost exceeds your value advantage, you cannot win the customer), Interest ≠ Intent (confusing compliments with purchase commitments. The Mom Test (Fitzpatrick 2013): "That's a great idea!" = politeness, not validation. "Would you use this?" = hypothetical, not commitment. "When can I buy it?" = intent signal. Proof of purchase intent (strongest → weakest): (1) Pre-orders with payment: they paid before the product exists. (2) Letters of Intent (LOI): signed commitment to purchase at launch. (3) Pilot agreements: they allocated time and resources to test. (4) Current spending on workarounds: they already pay for an inferior solution. (5) "I would definitely use this": worthless without money attached. "10,000 people on the waitlist" means nothing. "47 people pre-ordered at $99 with a credit card" means everything), and MVP Bloat (scoping a "minimum" product that takes 6 months to build. "Our MVP needs user authentication, payment processing, real-time collaboration, mobile apps for iOS and Android, and an admin dashboard." That is not an MVP. that is a product. An MVP is the MINIMUM experiment to test the CORE hypothesis. Hypothesis: "Solo accountants will pay $29/month for automated time tracking." MVP: a Google Form that asks 50 accountants to log their time for 1 week using your proposed format, then measures: did they complete it? Was it faster? Would they pay? Timeline: 1 week. Cost: $0. If 70%+ complete and 40%+ say "yes, I would pay". THEN build the product. If not. pivot the hypothesis, not the code. An MVP is an experiment, not a product). Call once per product idea, feature hypothesis, or market entry decision