Product Discovery Prover MCP Connector for Claude

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 tool, 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 tool 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 tool (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