# Product Discovery Prover MCP > Product Discovery Prover is an MCP server that forces product teams to validate market needs before writing code. It requires hard data on problem scale, defines customers by specific behaviors, mandates hands-on competitor testing, and verifies actual financial commitment to prove a concept. ## Overview - **Category:** productivity - **Price:** Free - **Tags:** product-discovery, lean-startup, mvp-scoping, customer-development, purchase-intent, competitor-analysis, product-management, hypothesis-validation ## Description You got product ideas that sound great in a meeting room but fall apart when they meet reality. Don't waste time and money building something nobody needs. The `validate_product_discovery` tool forces you to prove your concept is real—it runs a structured review on any hypothesis, demanding hard proof across five critical areas before an engineer writes a single line of code. This isn't a suggestion list; it’s a gate that requires documented evidence. You gotta show the problem exists at scale and that people are ready to pay for the fix. To prove problem existence at scale, you can’t just say 'it's a pain point.' The tool demands specific metrics showing genuine market need. It makes you cite actual data points—things like sustained high search volume on problem-related keywords or documented trends in existing support ticket logs that track the severity of the issue. You gotta show quantifiable proof that the struggle is widespread and persistent. The server forces definition of customers by observable behavior, not vague demographics. Forget saying 'small businesses.' Instead, you'll define segments based on actions: maybe it’s 'solo accountants who are currently using three different spreadsheets to track payroll,' or 'freelance designers whose workflow consistently breaks when they move files between programs.' The system requires mapping these behavioral friction points—the abandoned alternatives and the specific steps in a user's current process that cause headaches. You must map out competitor weaknesses by documenting hands-on testing results. You don’t get to just read their website; you have to test their actual products against real tasks for at least one week. The tool forces you to identify clear, exploitable gaps—where they fail or where the user hits a wall—and calculate the switching cost. If your solution isn't dramatically easier than what they offer right now, you haven’t proven anything. The server separates genuine intent from polite compliments when verifying financial commitment. It demands evidence of concrete spending readiness. You need proof like pre-payments or signed Letters of Intent (LOIs) that show someone is willing to put money down before the product exists. If people are just saying, 'I love this idea,' you fail this check. You gotta prove actual capital commitment. Finally, it constrains your efforts by scoping rapid experiments. It forces you to define a core hypothesis and an experiment so minimal that you can test it in four weeks or less. This isn’t about building the whole product; it's defining the single riskiest assumption and proving it wrong—or right—as fast as possible. If your proposed scope drags out past one month, it ain't an MVP, and you don't get to test it here. This process strips away assumptions that founders build their careers on. It prevents solution-seeking problems by demanding proof of pain and demand *before* the first line of code is written. You walk into development with hard data backing up every claim. ## Tools ### validate_product_discovery Runs a structured review on any product hypothesis, demanding evidence of problem scale, user behavior segmentation, competitor weaknesses, purchase intent, and MVP scope. ## Prompt Examples **Prompt:** ``` Let's build an AI assistant for lawyers. It will help them read contracts faster. The market is huge and lawyers will love it. ``` **Response:** ``` Verdict: SOLUTION_SEEKING_PROBLEM. Stop. You have zero data. 'The market is huge' is not evidence — it is a guess. Before writing code: how do lawyers review contracts today? How many hours per week? What does a missed clause cost them? Bring numbers or do not proceed. ``` **Prompt:** ``` Idea: AI contract tool. Problem: solo lawyers spend 10+ hours/week reviewing standard vendor agreements. Keyword 'contract review tool' has 1.2K searches/month. Segment: solo corporate lawyers in boutique firms who use Word. Alternatives: Manual reading, paralegals, enterprise tools. Will pay: 8 lawyers pre-ordered at $99/month on our landing page. MVP: PDF upload + OpenAI prompt producing a 3-bullet summary. Tested in 2 weeks. ``` **Response:** ``` Verdict: DISCOVERY_PROVEN. Right. Problem quantified at 10+ hours/week. Search demand confirmed at 1.2K/month. Segment is behavioral — not 'lawyers' but 'solo corporate lawyers in boutique firms using Word.' Competitors mapped. 8 pre-orders at $99/month — that is real money. MVP scoped as a 2-week experiment, not a platform. Ship it. ``` **Prompt:** ``` Idea: AI contract summarizer. Problem: corporate lawyers spend 10+ hours/week. Segment: lawyers who use Microsoft Word. Competitors: Manual reading. Will pay: 20 people signed up to our waitlist saying 'it sounds like a great tool'. MVP: landing page, upload portal, settings dashboard, API integration, and analytics. ``` **Response:** ``` Verdict: NO_PURCHASE_INTENT. Three failures. First — 'lawyers who use Word' is a tool preference, not a behavioral segment. Second — 'it sounds great' is a compliment, not a commitment. Money is data. Where are the credit cards? Third — your MVP has 5 features. That is not an MVP, that is a product. Strip it to one testable hypothesis. ``` ## Capabilities ### Prove problem existence at scale The tool demands specific data points, like high search volume or existing support ticket trends, to confirm a genuine market need. ### Define customers by behavior It forces the definition of user segments using observable actions (e.g., abandoned alternatives, workflow friction) instead of vague demographics. ### Map competitor weaknesses You must document hands-on testing results against competitors' products to identify clear gaps and switching costs. ### Verify financial commitment The server separates polite compliments from genuine intent by requiring evidence of pre-payments or signed Letters of Intent (LOIs). ### Scope rapid experiments It constrains the product scope to a minimum viable experiment, defining a core hypothesis and a measurable success threshold within 4 weeks. ## Use Cases ### A founder wants to build an AI legal contract tool The founder submits the idea. The agent responds by demanding specific evidence: How many hours per week do lawyers spend? What is the average cost of a missed clause? Without numbers, the process stops immediately. ### A team proposes an internal workflow optimization tool The agent forces segmentation away from 'all employees' to a group like 'marketing managers in departments with >3 people who manually generate weekly reports.' This pinpoints the exact user and pain point. ### A PM wants to validate a niche B2B SaaS The agent forces the PM to check competitor APIs and sign up for rival services. The output details which integrations are missing or whose switching cost is too high, guiding the product pivot. ### A team wants to scale a service based on word-of-mouth The agent rejects 'high waitlist numbers.' It demands concrete proof: How many people pre-ordered with actual credit cards? This forces the conversation from hype to hard capital. ## Benefits - Prevents wasted development effort by acting as a hard gate against building software nobody wants or needs. The server forces proof of concept instead of intuition. - Elevates your MVP scope from an unstructured build into a rapid, defined experiment with clear success metrics and timelines (1-4 weeks). - Forces behavioral segmentation, ensuring you target specific user workflows—like 'solo accountants who use spreadsheets'—not vague groups like 'small businesses.' - Distinguishes between compliments ('I love this idea') and real money. The tool requires pre-orders or LOIs to confirm genuine purchase intent. - Documents required competitor testing: you must sign up for every existing rival product and test it with real tasks for a week, documenting the gaps. ## How It Works The bottom line is that you can't start building until the server confirms proof of pain, money commitment, and a tightly scoped test plan. 1. Submit your initial product idea or feature hypothesis to trigger `validate_product_discovery`. 2. The server runs through five mandatory checks: gathering evidence on pain points, identifying behavioral segments, mapping competitor gaps, demanding purchase intent proof, and scoping the MVP scope. 3. You receive a verdict (e.g., DISCOVERY_PROVEN or NO_PURCHASE_INTENT) detailing exactly where your product thinking failed, requiring specific data updates before proceeding. ## Frequently Asked Questions **How does Product Discovery Prover MCP Server validate purchase intent?** It moves beyond compliments by requiring concrete financial evidence. The server accepts proof points like Letters of Intent (LOIs) or actual pre-payments, rejecting mere interest signals. **Can I use Product Discovery Prover MCP Server for simple feature ideas?** Yes, but you must treat the small feature as a hypothesis. The server will still force you to prove that specific feature solves a painful problem at scale and that users are willing to pay extra for it. **What is 'behavioral segmentation' in Product Discovery Prover MCP Server?** It means defining your customer by what they actually do—the tools they use, the alternatives they abandoned, or where their workflow breaks. It skips demographics entirely. **Is Product Discovery Prover MCP Server better than a simple market report?** Yes. A market report provides general data. This server runs targeted validation checks that force you to connect specific pain points (e.g., manual workarounds) with measurable financial commitment. **How does Product Discovery Prover MCP Server integrate with my existing AI client?** It connects via the open Model Context Protocol (MCP) standard. You simply link your preferred agent—like Cursor or Claude—to our server endpoint in Vinkius. Your agent handles all data routing, so you don't need to worry about API keys or complex setup. **If my market evidence for validate_product_discovery is unstructured text, how should I format it?** The system expects structured, quantifiable inputs. Instead of dumping paragraphs, break your data into clear lists: 'Behavioral Segments,' 'Workaround Spending,' and 'Search Volume.' Use bullet points or JSON structures to make the evidence explicit. **What should I do if Product Discovery Prover returns a 'SOLUTION_SEEKING_PROBLEM' verdict?** Treat that result as mandatory feedback, not failure. The verdict means your hypothesis lacks sufficient hard data in one or more areas (e.g., monetary commitment). You must go back to the source and gather concrete evidence before trying again. **Is there a rate limit when running validate_product_discovery for multiple product ideas?** The server is designed for iterative validation, allowing you to test multiple hypotheses in sequence. If you hit limits, wait a few minutes or consider chunking your inputs into smaller groups of related evidence. **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.