# Product Discovery Prover MCP for AI Agents AI Agent Connect > Product Discovery Prover blocks engineering waste by demanding hard data, behavioral segments, and proven willingness-to-pay before a single line of code is written. It acts as a validation gate that forces you to prove a problem exists at scale before committing to an MVP. ## Overview - **Category:** productivity - **Price:** Free - **Endpoint:** https://edge.vinkius.com/vk_preview_oRfntTCBhavUOPmcOZLkfPw8gtNLViGrf1SALzQt/ai-agent-connect - **Tags:** product-discovery, lean-startup, mvp-scoping, customer-development, purchase-intent, competitor-analysis, product-management, hypothesis-validation ## Description Building a product on a hunch is a fast way to burn through your budget and waste engineering hours. This gatekeeper for product discovery changes how you move from a raw idea to a validated MVP by acting as a strict validation gate. Instead of letting your team start coding based on a gut feeling, this Connector forces a structured review of your evidence. It ensures you've actually talked to enough people to prove a problem exists at scale, identified a specific group of users based on what they do rather than just who they are, and checked out the competition by actually using their tools. It helps you separate polite compliments from real money on the table. When you use it through the Vinkius catalog, you're not just getting a checklist; you're getting a way to ensure your next project is a calculated bet rather than a gamble. It forces you to define a tiny, testable experiment that can be finished in a few weeks, rather than a bloated platform that takes months to build. It catches common mistakes like solution seeking where you build technology first and look for a problem later, or competitor blindness where you assume no one else is solving the issue. By using this Connector, you move from "I think" to "I know." ## Tools ### validate_product_discovery Forces you to provide evidence of problem scale, behavioral segments, and purchase intent. It gives you a clear verdict on whether your product thinking is ready for engineering. ## Prompt Examples **Prompt:** ``` I want to build a tool that helps florists manage their inventory. Is this a good idea? ``` **Response:** ``` Verdict: SOLUTION_SEEKING_PROBLEM. Stop. You have zero data. 'I think people need this' is not evidence. Before writing code, you need to answer: * How many hours a day do they spend on inventory? * What tools do they use now (paper, spreadsheets, existing apps)? * What is the cost of a mistake in their current process? Bring numbers or do not proceed. ``` **Prompt:** ``` We have 500 people on a waitlist for our new AI legal tool. Can we start building the full platform now? ``` **Response:** ``` Verdict: NO_PURCHASE_INTENT. Three failures. 1. **Compliments vs. Data**: A waitlist is a compliment, not a commitment. Where are the credit cards? 2. **MVP Bloat**: A full platform is not an MVP. 3. **Scope**: Strip it down to one testable hypothesis. **Next Steps:** * Get 10 people to sign a Letter of Intent (LOI). * Build a 1-week experiment (e.g., a manual service) to see if they actually use it. ``` **Prompt:** ``` Our target is busy parents. We want to build an automated meal planner. What's the plan? ``` **Response:** ``` Verdict: SEGMENT_VAGUE. 'Busy parents' is a demographic, not a behavior. There are millions of them. **Refined Behavioral Segment:** * **Who:** Working parents of toddlers. * **Behavior:** Spend 45 minutes every Sunday meal prepping. * **Current Tool:** Hand-written lists and grocery store flyers. * **Pain:** High friction in switching from 'planning' to 'shopping.' **MVP:** A Google Form for 50 parents to log their current prep time. ``` ## Capabilities ### Validate problem evidence Check if the pain point exists at scale using search volume, support logs, and interview data. ### Define behavioral segments Identify your target users by their specific actions and workflows instead of broad demographics. ### Map competitor gaps Analyze existing workflows and switching costs by actually using competitor products. ### Verify purchase intent Distinguish between polite compliments and actual commitments like pre-orders or pilot agreements. ### Scope minimum experiments Convert a massive product roadmap into a testable hypothesis that can be finished in weeks. ## Use Cases ### Validating a new AI feature A PM wants to know if a new AI summary feature is worth building. They use validate_product_discovery to find out if users actually spend time on the manual task. ### Defining a niche for a new tool A founder wants to launch a tool for accountants. They use the Connector to move from small businesses to solo accountants using spreadsheets. ### Analyzing market entry costs A team is unsure about a new market entry. They use the Connector to find out if the switching cost from the current manual workaround is too high. ### Shrinking a bloated MVP A developer wants to build a prototype. They use the Connector to strip a 6-month roadmap down to a 1-week Google Form experiment. ## Benefits - Stop engineering waste by ensuring every project has proven demand before it hits the roadmap. - Move past vague demographics by using validate_product_discovery to target users based on specific behaviors. - Identify real competition by documenting switching costs and lock-in mechanisms instead of just listing names. - Separate vanity feedback from real revenue by verifying pre-orders and pilot agreements. - Keep your MVP lean by scoping experiments that can be completed in under 4 weeks. - Avoid solution seeking by proving the problem exists at scale before choosing a technology. ## How It Works The bottom line is you get a data-backed go or no-go on your product idea. 1. Input your product idea or feature hypothesis into the chat. 2. The Connector analyzes your evidence against Lean Startup and Jobs-to-be-Done principles. 3. You get a clear verdict on whether the discovery is proven or if you have a blind spot to fix. ## Frequently Asked Questions **How does Product Discovery Prover help my team avoid building the wrong features?** It acts as a hard gate that requires you to provide evidence of problem scale and purchase intent before engineering can start. This prevents you from spending months building features that nobody actually wants. **Can Product Discovery Prover help me define my target audience?** Yes. It forces you to move past vague demographics like 'small businesses' and define users by their specific behaviors, current tools, and workflow friction. **What is the difference between interest and purchase intent in Product Discovery Prover?** Interest is a compliment like 'that sounds cool.' Purchase intent is concrete data like pre-orders, letters of intent, or people already spending money on a workaround. **How does Product Discovery Prover help with MVP scoping?** It forces you to define the minimum experiment needed to test a core hypothesis. If your MVP takes more than 4 weeks to build, the Connector will flag it as bloated. **Can I use Product Discovery Prover to analyze my competitors?** Yes. It requires you to actually test competitor products for real tasks and document their strengths, gaps, and the switching costs for your potential customers. **What happens if Product Discovery Prover rejects my product idea?** It identifies a specific blind spot in your thinking, such as a lack of evidence, a vague segment, or a lack of purchase intent. You can then fix that specific issue before you start building. **Why does the tool reject demographic segments?** Because demographics are useless for product design. 'Millennials' is a marketing category, not a workflow. We demand behavioral segments because they isolate users actively experiencing the exact pain point you intend to solve. **What qualifies as valid purchase intent?** Money or legally binding ink. Polite compliments and 'I would use this' are false signals that kill startups. We require active commitment: credit cards on file, signed B2B Letters of Intent (LOIs), or cash deposits. **How should an MVP be scoped?** As a single-variable experiment. Drop the settings panels, user profiles, and polished UI. The MVP must isolate and test the core value hypothesis. Use manual back-end workarounds to deliver the outcome without building the platform.