# Meta Market Validation > Use when use before writing when market assumptions still need field validation. Use the relevant plan-section skill for section drafting. - Skill: `peterbamuhigire/meta-market-validation` (Agent Skill, multi-file: 8 files) - Install (CLI): `npx skillmds@latest add peterbamuhigire/meta-market-validation` - Raw SKILL.md: https://api.skillmd.com/api/skills/peterbamuhigire/meta-market-validation/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: peterbamuhigire (https://skillmd.com/u/peterbamuhigire) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/peterbamuhigire/meta-market-validation --- # Market Validation Meta-Skill ## Overview Use this meta-skill to validate or audit market claims. It supports both pre-plan field validation and post-draft evidence review so market logic is grounded in real customer signal rather than narrative convenience. ## Use When - Use before writing when market assumptions still need field validation. - Use after drafting when market claims need an evidence audit. - Use when the plan's credibility depends on proving demand and customer behaviour. ## Do Not Use When - Do not use to launder speculation into “validated” language. - Do not treat desk research alone as customer validation. - Do not keep validating forever when a clear decision can already be made. - For `meta-market-validation`, route to the relevant plan-section skill instead when the request is section drafting rather than cross-section analysis. ## Required Inputs | Input | Source / provider | Required? | If absent | |---|---|---:|---| | Market Validation brief and decision audience | Client, plan owner, or approved project files | Yes | Stop before making a recommendation; state the missing decision context. | | Claims, assumptions, and supporting evidence | Source register, model, research notes, interviews, or operating records | Yes | Separate known facts from assumptions and return a qualified gap list. | | Authority and delivery constraints | Requesting owner and repository instructions | Yes | Remain read-only and produce a draft or review only. | - Business idea, offer, and target-customer assumptions - Existing market evidence, customer conversations, or draft claims - Country, sector, and channel context where behaviour matters - Adjacent market, target-market, and sales sections where consistency matters ## Workflow 1. Decide whether the task is pre-plan validation or post-plan auditing. 2. Identify the market assumptions or claims that matter most. 3. Gather or test evidence against those claims. 4. Distinguish validated findings from hypotheses and weak signals. 5. Reconcile the results with the plan's narrative and numbers. 6. Flag unsupported claims that should be revised or removed. ### Decision, stop, and recovery controls - **Decision point:** confirm that the requested output is the market-validation evidence pack and that the decision concerns whether demand evidence supports proceed, revise, or stop. - **Stop condition:** halt the affected conclusion if required evidence is missing (customer interviews, observed behaviour, and claim thresholds) or if the work could lead to this identified risk: substituting market size and polite interest for purchase behaviour. - **Recovery:** obtain the missing record or reviewer, repeat the affected check, and update the exception record before release. ## Quality Bar - The output clearly separates evidence from assumption. - Validation work is targeted at decisions that matter. - Weak claims are surfaced rather than buried. - Findings improve the plan's credibility and focus. ## Anti-Patterns - Using anecdote as proof of market demand. - Auditing market claims without checking their financial implications. - Equating interest with purchasing behaviour. - Leaving unsupported claims in place because they “sound strategic”. - Treating a generic market validation template as a conclusion. **Correction:** tie each choice to the named audience, evidence, and operating constraint. - Applying the wrong neighbouring route to meta market validation. **Correction:** confirm the decision and route to the named neighbour before analysis. - Treating an assumption as verified evidence. **Correction:** label it, cite its source or owner, and assign a verification action. - Recommending action without a decision threshold. **Correction:** state the measurable acceptance condition and review trigger. - Recording an unavailable check as passed. **Correction:** mark it `not assessed` and state the consequence for the decision. - Mutating or publishing during an analysis-only task. **Correction:** remain read-only until the owner gives explicit authority. ## Outputs | Artefact | Consumer | Observable acceptance condition | |---|---|---| | Market Validation deliverable | Named decision-maker or plan author | The recommended choice, assumptions, countercase, and next action are explicit. | | Evidence and exception register | Reviewer, funder, board, or implementation owner | Every load-bearing claim is sourced or labelled as an assumption; missing checks are not shown as passes. | - A validation plan, evidence audit, or market-claim review - Clear distinction between validated facts and open assumptions - Recommended revisions or next tests ## When to Use **Mode A Pre-Plan Field Validation:** Before writing the business plan. Use when the entrepreneur has an idea but hasn't yet validated it with real customers. Guides systematic assumption-testing. **Mode B Post-Plan Claim Auditing:** After sections 04-07 are complete. Reviews market claims and flags unsupported assertions before investors do. Both modes can be used sequentially: validate first, write the plan, then audit the plan. ## Mode A: Pre-Plan Field Validation ### Core Philosophy "A startup is a temporary organisation in search of a scalable, repeatable, profitable business model" (Blank & Dorf, 2012). Business plans are collections of untested hypotheses. Customer Development converts hypotheses into facts through systematic testing. **The 14th rule:** There are no facts inside your building get outside. ### Step 1: Classify the Venture's Problem Recognition Level Before designing validation activities, assess where target customers sit on the Problem Recognition Scale (Blank & Dorf, 2012): | Level | Customer State | Validation Approach | |---|---|---| | **Latent** | Have the problem but don't know it | Education-first; validate that the problem exists | | **Passive** | Know the problem but aren't motivated to change | Validate pain severity; quantify cost of inaction | | **Active** | Searching for a solution with a timetable | Validate solution fit; test willingness to pay | | **Vision** | Have cobbled together a workaround | Validate that your solution is better than their hack | ### Step 2: Identify Earlyvangelists Find customers with all five characteristics (Blank & Dorf, 2012): 1. They have a problem or need 2. They understand they have a problem 3. They're actively searching for a solution with a timetable 4. The problem is so painful they've cobbled together an interim solution 5. They've committed or can quickly acquire budget to purchase ### Step 3: Map Stakeholders Use three concentric rings (Alam): - **Target** 1-3 primary beneficiaries/users - **Connected** payers, implementers, gatekeepers who directly influence - **Influenced** community, regulators, adjacent businesses indirectly affected ### Step 4: Conduct Empathy-Based Research Follow the 8-category interview guide (Alam): Introduction Jobs to Be Done Customers Challenges Aspirations Stories Emotions Conclusion. Key engagement rules: - Ask "why?" repeatedly - Encourage stories ("Tell me about the last time...") - Look for inconsistencies between words and actions - Embrace silence don't fill pauses - Never suggest solutions during the interview Build Empathy Maps: Observations Interpretations Insights. See `references/empathy-validation-tools.md`. ### Step 5: Apply Rapid Validation Use Kagan's Golden Rule: **Find 3 paying customers in 48 hours.** Three validation methods: 1. **Direct preselling** use the LOT framework (Listen-Options-Transition) 2. **Marketplaces** post on Facebook Marketplace, local forums, WhatsApp groups 3. **Landing pages** simple page with price and buy button Structure offers using the Price + Benefit + Time formula: > "For [price], I will [benefit] in [time]." When rejected, use the 4-question script: Why not? Who else? What would make it a no-brainer? What would you pay? See `references/rapid-validation-methods.md`. ### Step 6: Document and Track Assumptions Use the Assumptions Tracking Template (Alam): - Classify each assumption as Minor / Major / Critical - Assign owner and due date - Track status: New In Progress Validated / Disproved Calculate Risk Score: `(Minor 1) + (Major 5) + (Critical 25)`. Target: below 100. ### Step 7: Test the Solution (MVP) Follow the MVP Evolution Model (Cooper & Vlaskovits, 2010): | Stage | Interaction | Objective | Currency | |---|---|---|---| | MVP 1 | Landing page / concept | Test problem resonance | Attention | | MVP 2 | Demo / prototype | Test solution approach | Commitment | | MVP 3 | Working product | Test willingness to pay | Money | Evaluate each capability using the BFCE framework (Alam): Better (quality)? Faster (efficiency)? Cheaper (cost)? Easier (experience)? ### Step 8: Measure Product-Market Fit Three-criteria test (Cooper & Vlaskovits, 2010): 1. Customer willing to pay 2. Cost of acquisition < revenue per customer 3. Sufficient evidence market is large enough **Sean Ellis 40% Rule:** If 40% of users say they'd be "very disappointed" without the product, you have product-market fit. ### Step 9: Pivot or Proceed Apply the three-question test (Blank & Dorf, 2012): 1. **Can it scale?** $1 in acquisition produces > $1 in revenue? 2. **Is there a repeatable sales roadmap?** Can others replicate the sales process? 3. **Is the funnel predictable?** Can you forecast conversion at each stage? If any answer is no, pivot (change one or more Business Model Canvas boxes) and return to Step 4. See `references/customer-development-process.md` for pivot methodology. ### Growth Engineering Validation Add-On For SaaS, AI-enabled products, marketplaces, platforms, and digital products, validate the growth system, not only initial interest: - What is the activation event that proves the customer reached first value? - What behaviour predicts retention? - What event data must be captured from day one? - Which acquisition source produces retained users, not just signups? - What experiment will test the highest-risk growth assumption? - What decision rule determines whether to scale, iterate, or stop? Treat a growth claim as unvalidated until it names a behaviour, a metric, a cohort or segment, and a decision threshold. ### Quick Validation Checklist Before writing the business plan, the entrepreneur should have validated: - [ ] The problem exists and is painful (not a vitamin a painkiller) - [ ] Target customers are identifiable and reachable - [ ] At least 3 customers have paid or committed to pay - [ ] Pricing is based on value-based testing, not guesswork - [ ] The market is growing (Google Trends or equivalent check) - [ ] TAM/SAM is calculated bottom-up, not just top-down - [ ] Key assumptions are tracked with impact classifications - [ ] Risk Score is below 100 (or declining) - [ ] MVP has been tested with real users - [ ] Product-market fit evidence exists (Ellis 40% or equivalent) - [ ] For digital/product-led businesses, activation, retention, referral, and revenue loops have measurable event data and at least one experiment plan --- ## Mode B: Post-Plan Claim Auditing Audit the market-facing sections of the business plan (sections 04-07) to ensure claims are defensible and data-backed. ### What to Validate #### 1. Market Size Validation - Is TAM calculated using credible methodology (bottom-up preferred)? - Is SAM a logical subset of TAM with clear narrowing criteria? - Is SOM realistic (typically 1-5% of SAM for startups)? - Are market size sources cited and current (within 2 years)? - Does bottom-up calculation align with top-down? - What is the market type: existing, new, re-segmented, or clone? (Blank & Dorf, 2012) #### 2. Growth Rate Validation - Are growth projections supported by historical data? - Is the cited CAGR from a reputable source? - Are growth assumptions consistent with the market type? (New markets take 3-7 years; existing markets grow incrementally) - Is the business growing faster than the market? If so, why? #### 3. Customer Assumption Validation - Are customer personas based on research or assumptions? - Were earlyvangelists identified and interviewed? - Is the CAC estimate grounded in comparable data? - Is the CLV calculation realistic given churn assumptions? - Is the CLV:CAC ratio defensible (>3:1)? - Has the Problem Recognition Scale been assessed? #### 4. Competitive Positioning Validation - Are all relevant competitors identified (direct, indirect, substitutes)? - Is the market type acknowledged, and does competitive strategy match? - Are competitive advantages genuinely sustainable? - Are competitor weaknesses based on evidence, not wishful thinking? - Has cost-of-entry been assessed? (74%+ = monopoly, 41%+ = leader, 26%+ = unstable, <26% = open; Blank & Dorf, 2012) #### 5. Pricing Validation - Is pricing consistent with the value proposition? - Was pricing tested with real customers (value-based approach)? - How does pricing compare to competitors and workarounds? - Does the pricing model support the revenue projections? - Have the Six Revenue Dials been considered? (Kagan, 2024) #### 6. Validation Evidence Check (new) - Did the plan authors conduct Customer Development activities? - Is there evidence of customer interviews, surveys, or preselling? - Are assumptions documented with validation status? - Is the Risk Score reported and acceptable? - Has product-market fit been measured? ### Claim-by-Claim Output Format For each claim reviewed: ~~~text Claim: [The specific assertion] Source: [Where it appears in the plan] Evidence: [Supporting data found] Validation Method Used: [Interview / Preselling / Survey / Secondary research / None] Status: VALIDATED / NEEDS EVIDENCE / UNSUPPORTED / CONTRADICTED Action: [What to do cite source, conduct research, revise claim] ~~~ ### Validation Summary Dashboard | Area | Claims | Validated | Needs Evidence | Unsupported | Critical Issues | |---|---|---|---|---|---| | Market size | X | X | X | X | [List] | | Growth rates | X | X | X | X | [List] | | Customer data | X | X | X | X | [List] | | Competition | X | X | X | X | [List] | | Pricing | X | X | X | X | [List] | | Validation evidence | X | X | X | X | [List] | --- ## Generation Process ### Mode A (Pre-Plan) 1. Classify the venture's problem recognition level 2. Identify earlyvangelists and map stakeholders 3. Design and conduct empathy-based research 4. Apply rapid validation (Golden Rule: 3 customers/48 hours) 5. Document assumptions with impact classifications 6. Build and test MVP through the evolution model 7. Measure product-market fit 8. Decide: pivot or proceed 9. Compile validated findings as input for business plan writing ### Mode B (Post-Plan) 1. Review sections 04-07 and extract all factual claims 2. Categorise each claim (market size, growth, customer, competitive, pricing, validation evidence) 3. Assess evidence for each claim, including Customer Development evidence 4. Flag unsupported or contradicted claims 5. Suggest validation methods for gaps (preselling, interviews, pilot tests, marketplace tests) 6. Produce validation summary dashboard ## Quality Criteria - Every factual claim is assessed, not just the obvious ones - Validation is objective does not rubber-stamp weak claims - The 9 Deadly Sins are actively checked for (Blank & Dorf, 2012) - Premature scaling warnings are flagged aggressively - Suggested validation methods are practical and affordable for the Ugandan context - Critical issues are highlighted with urgency - Risk Score trajectory is tracked if assumptions data is available ## References - `references/customer-development-process.md` Blank/Dorf's 4-step Customer Development, 14 rules, 9 Deadly Sins, pivot methodology, Business Model Canvas as scorecard - `references/customer-discovery-steps.md` Cooper/Vlaskovits' 8-step Customer Discovery, C-P-S hypotheses, Funnel Matrix, Value Path, Business Ecosystem Mapping, outreach templates, MVP Evolution Model, product-market fit measurement - `references/rapid-validation-methods.md` Kagan's Golden Rule, LOT framework, Dream Ten List, Price+Benefit+Time formula, Rejection Script, validation methods, One-Minute Business Model, Six Revenue Dials, Content Circle Framework - `references/empathy-validation-tools.md` Alam's Transform3+1, stakeholder mapping, empathy research, persona template, journey mapping, BFCE framework, user testing methodology, Assumptions Tracking, Risk Score formula, elevator pitch templates - `references/mckinsey-problem-solving.md` McKinsey's MECE principle (Mutually Exclusive, Collectively Exhaustive) with worked examples; issue tree construction and branching rules; hypothesis-driven analysis (Initial Hypothesis method, three-step generation, insurance leakage anecdote); 80/20 rule as diagnostic jump-start; key drivers framework; fact-based analysis; Forces at Work four-category environmental scan (suppliers/customers/competitors/substitutes); elevator test; presentation structure (one message per chart, prewiring); 10 common analysis mistakes Source: Rasiel (McGraw-Hill). **Read when structuring any analytical section (market analysis, competitive analysis, risk), when building issue trees, or when auditing claims for MECE compliance and fact-based support.** - **72-tool business analysis toolkit**: See `references/business-analysis-techniques-cadle.md` for all 72 BA tools grouped by stage (strategy, investigation, stakeholder analysis, process modelling, options evaluation, change management), a business plan application table mapping each category to plan sections, and Uganda/EA contextualisation notes Source: Cadle, Paul & Turner (BCS, 2010). **Read when structuring a market investigation, designing stakeholder analysis, building process models for the operations plan, evaluating options with CBA/NPV, or auditing a plan's analytical rigour against a structured toolkit.** - **Growth-system validation**: See `../../book-extractions/growth-profit-disruption-systems-extraction.md` for growth engineering, activation/retention metrics, experiment cadence, remarkable growth systems, profit levers, and disruption tests. **Read when validating SaaS, AI-enabled, marketplace, platform, or product-led growth claims.** ## Evidence Produced | Evidence | Format | Acceptance condition | |---|---|---| | Market-validation evidence pack decision trace | Sources, calculations, assumptions, countercase, and selected action | A reviewer can trace the selected action and rejected alternatives to the cited inputs. | | Exception record | Failed and not-assessed checks with owner and due action | The register exposes every unresolved exception that could lead to substituting market size and polite interest for purchase behaviour. | ## Capability and Permission Boundaries Default to read-only inspection while producing the market-validation evidence pack. Read supplied records and run non-mutating checks; recording research evidence; customer outreach needs authority is permitted only when requested. Do not publish, contact third parties, alter live systems, commit funds, or claim legal, tax, audit, valuation, ESG, or investment assurance without the owner's explicit authorisation and the appropriate reviewer. ## Degraded Mode If customer interviews, observed behaviour, and claim thresholds cannot be obtained, return a qualified market-validation evidence pack covering only the checks that remain supportable. Leave this decision unresolved: whether demand evidence supports proceed, revise, or stop. Record the evidence owner and next check; an inaccessible source, tool, or reviewer is never a pass. ## Decision Rules | Decision condition | Action | Failure or risk avoided | |---|---|---| | Evidence is sufficient to decide: whether demand evidence supports proceed, revise, or stop | Record the conclusion, source trail, owner, and review trigger in the market-validation evidence pack. | Risk of substituting market size and polite interest for purchase behaviour | | Material evidence conflicts or remains uncertain | Set the behaviour threshold first, test the disputed demand claim with the named segment, and keep market size outside the pass criterion. | Selecting an option without resolving the decision-relevant uncertainty | | Required evidence is missing: customer interviews, observed behaviour, and claim thresholds | Mark the decision on whether demand evidence supports proceed, revise, or stop `not assessed` in the market-validation evidence pack, and send it to the research lead and plan owner. | Otherwise, the work risks substituting market size and polite interest for purchase behaviour | ## Quality Standards Accept the market-validation evidence pack only when evidence is sufficient for this decision: whether demand evidence supports proceed, revise, or stop. Assumptions and countercases remain visible, calculations and cross-references reconcile, and the reviewer can see how the recommendation addresses the risk of substituting market size and polite interest for purchase behaviour. ## Worked Example Interviewees praise an agritech concept but will not commit to a paid pilot. Record interest separately from purchase behaviour and keep the demand claim unvalidated until the agreed commitment threshold is met. ## Build-Measure-Learn and validated-learning controls Use the smallest reversible experiment that can change a business decision. For every material assumption, create an experiment card containing: problem, assumption, customer segment, baseline, test, expected behaviour, decision threshold, counter-metric, owner, timebox, evidence location, and stop/pivot/continue rule. Treat learning as validated only when observed behaviour or a controlled operational result changes the plan, model, offer, sequence, or risk register. Record interest, intention, usage, commitment, payment, retention, and referral as different evidence levels; never promote a weaker signal to a stronger one. Apply this loop before approving a major spend or scale-up: 1. Build the smallest offer, prototype, process, or landing page that tests the highest-risk assumption. 2. Measure behaviour against the baseline, with a guardrail for cash, quality, trust, mission, safeguarding, or staff capacity. 3. Learn by comparing the result with the pre-registered threshold; choose continue, revise, pivot, pause, or stop. 4. Standardise only the change that passed its guardrail and update the plan assumption register, financial model, owner, and next test. For innovation accounting, show the input, leading behaviour, outcome, and economic implication separately. A favourable vanity metric cannot justify scale if activation, retention, contribution margin, delivery capacity, or control quality deteriorates. Read `references/kaizen-experiment-and-learning.md` for the reusable experiment record and book provenance. Also read `../references/book-driven-commercial-system-and-validation.md` for the whole-system validation and currentness gate, and `../references/marketing-plan-handbook-operating-loop.md` for the customer-first market ladder, segment decision matrix, forecast, budget, metric, and control loop.