Idea Validation

Idea Validation

When to Use

Use this skill when:

• A user has a business idea and wants to determine whether it deserves further investment of time, money, or team before building anything
• A user asks how to test their assumptions systematically before committing to a product roadmap or fundraise
• A user wants to apply lean startup methodology -- specifically assumption mapping, riskiest assumption testing (RAT), and experiment design -- to a specific idea
• A user has already built something that is not getting traction and wants to go back and validate whether the right problem was ever confirmed
• A user wants to design a 4-8 week validation sprint with specific experiments, metrics, and go/no-go decision points
• A user asks about willingness-to-pay testing, problem-solution fit, or fake door tests for a new concept
• A user is evaluating multiple idea directions and wants a structured way to kill the weakest ones quickly

Do NOT use this skill when:

• The user wants to build a one-page Lean Canvas (use lean-canvas -- assumption mapping here is deeper and experiment-focused)
• The user wants to define what goes into a first shipped product (use mvp-definition -- that skill starts after problem-solution fit is confirmed)
• The user wants a comprehensive business plan with financials, competitive analysis, and operational detail (use business-plan)
• The user wants to design specific customer discovery interview scripts and conversation frameworks (use customer-discovery-interview -- this skill references interviews as one experiment type but does not script them)
• The user already has confirmed problem-solution fit and wants to validate product-market fit at scale (use growth-strategy or pmf-measurement)
• The user has an established product and wants to validate a new feature (use feature-prioritization -- the validation framework differs when you have existing customers and data)

Process

Step 1: Extract and Clarify the Idea

Before mapping assumptions, the idea must be stated precisely. Vague ideas produce vague assumptions. Ask or derive:

• Product or service statement (one sentence): What is being built or offered? Resist compound sentences -- "an app that helps X do Y" is the correct unit, not a paragraph.
• Target customer: Push for a specific, reachable segment. "Small business owners" is too broad. "Independent restaurant owners with 1-3 locations doing $500K-$3M in annual revenue who operate without a dedicated finance role" is testable.
• Problem statement (from the customer's perspective): Write this as a frustration or consequence, not a feature request. "Owners set menu prices by gut feel and leave 8-15% gross margin unrealized" is a problem. "Owners don't have a pricing tool" is a solution disguised as a problem.
• Current alternatives: How do customers solve this problem today? Include the "do nothing" option. Every idea competes with the status quo. Knowing alternatives reveals switching costs and tells you how much better your solution must be.
• Unique value proposition: Why would a customer switch from their current behavior? This is not a tagline -- it is a hypothesis about what makes this 10x better or 10x cheaper or 10x faster than the alternative.
• Revenue model: How does money change hands? Per seat, per transaction, subscription, usage-based, freemium with paid tier? The revenue model carries its own assumptions that must be validated independently.
• Founder's unfair advantage (if stated): Domain expertise, existing relationships, proprietary data, or distribution channels that lower acquisition cost or increase credibility. Note this -- it affects which experiments are accessible and credible.

If the user cannot answer these questions clearly, do not proceed to assumption mapping. Work with them to sharpen the idea first. A fuzzy idea will produce an unmappable assumption list.

Step 2: Map All Assumptions by Category

Every business idea is a stack of assumptions. The job is to make them all explicit before prioritizing them. Most founders operate with 20-40 implicit assumptions and consciously acknowledge 3-5. Surface all of them.

Use the following four categories as an exhaustive taxonomy:

Problem Assumptions (does the problem exist and matter?):

• This specific problem exists for the target customer segment
• The problem is experienced frequently enough to drive behavior change (daily frustration vs. annual nuisance)
• The problem is painful enough that customers would pay money to solve it
• Customers are aware of the problem (not a latent need requiring education)
• Customers actively seek solutions (vs. accepting the status quo)

Solution Assumptions (does your solution solve the problem better?):

• The proposed solution actually solves the stated problem
• The solution is meaningfully better than existing alternatives (10x improvement threshold, not 10%)
• Customers can and will learn to use the solution (adoption friction is manageable)
• The solution solves the problem reliably and consistently (not just in the demo environment)
• Customers trust the solution enough to act on its outputs (especially relevant for AI/data recommendations)

Market Assumptions (is there a real market here?):

• The addressable market is large enough to build a sustainable business (even a niche business needs a minimum viable market)
• Target customers can be identified and reached through accessible, affordable channels
• Customers will pay the proposed price -- not just "something" but specifically this price point
• The market is not controlled by an entrenched incumbent who can easily copy the solution
• Customers will switch from their current solution despite switching costs and inertia

Business Model Assumptions (do the economics work?):

• Customer acquisition cost (CAC) is sustainable relative to customer lifetime value (LTV) -- typically LTV:CAC ratio of 3:1 or higher
• The unit economics at scale allow for a viable margin profile (gross margin appropriate to the model: 60-80% for SaaS, 40-60% for marketplaces, 20-40% for services)
• The business can reach break-even or raise sufficient capital before running out of runway
• The founding team can execute the go-to-market motion (sales capability, technical capability, operational capability)
• Retention is achievable -- the product solves a recurring problem, not a one-time event

List every assumption explicitly in a numbered table. Incomplete assumption mapping is the primary failure mode of this process.

Step 3: Score and Rank Assumptions by Risk

Risk = Criticality × Uncertainty. Prioritize assumptions that score High on both dimensions.

Criticality: If this assumption is wrong, does the entire idea fail?

• High: Yes, the idea is dead or requires a fundamental pivot
• Medium: The idea survives but requires significant adjustment
• Low: The idea can work around this if it is wrong

Uncertainty: How much evidence do you currently have for or against this assumption?

• High: No evidence, pure hypothesis, or contradictory signals
• Medium: Some anecdotal evidence or analogous examples, but not specific to this market
• Low: Direct evidence from data, prior experience, or validated analogies

Scoring guide:

• High Criticality + High Uncertainty = Riskiest (test immediately)
• High Criticality + Medium Uncertainty = Very risky (test in first sprint)
• Medium Criticality + High Uncertainty = Risky (test in second sprint)
• All other combinations = Lower priority (validate later, after core assumptions pass)

Select the top 3-5 assumptions ranked by risk score. These are the Riskiest Assumption Tests (RATs). If any of these fail, the idea is either dead or requires a major pivot. Do not test easier assumptions first to build confidence -- that is validation theater.

Step 4: Design a Specific Experiment for Each RAT

For each riskiest assumption, design the cheapest and fastest experiment that could falsify it. The goal is to disprove the assumption, not confirm it. Confirmation bias is the enemy.

For each experiment, define:

• Hypothesis (if/then/because format): "If [condition], then [measurable outcome], because [underlying mechanism]." Example: "If we show independent restaurant owners a 60-second demo of automated menu analysis, then at least 40% will ask about pricing or express intent to sign up, because pricing is a top-3 frustration they lack tools to address."
• Method: Choose the appropriate experiment type (see Step 5)
• Minimum sample size: Small enough to be fast, large enough to be meaningful. For qualitative problem interviews: 8-12 participants in a clearly homogeneous segment is sufficient to identify dominant patterns. For quantitative tests (landing pages, ad campaigns): 200-500 visitors minimum to measure conversion rates with any statistical confidence.
• Primary metric: One number that determines the outcome. Not "engagement" -- a specific rate, count, or conversion.
• Success threshold (pre-committed): The specific numeric result that validates the assumption. Set this BEFORE running the experiment. "6 out of 10 interviewees name pricing as a top-3 business challenge" is pre-committed. "Most people seemed interested" is post-hoc rationalization.
• Failure threshold (pre-committed): The specific numeric result that invalidates the assumption and triggers a pivot or kill decision.
• Timeline: Calendar days, not "a few weeks." Two weeks maximum per experiment for problem/solution validation. Four weeks maximum for market/demand validation.
• Cost in dollars and hours: Include both. Cheap and fast experiments first is a constraint, not a preference.

Step 5: Select the Right Experiment Type for Each Assumption Category

Different assumptions require fundamentally different experiment designs. Mismatching experiment type to assumption type produces unreliable data.

For Problem Assumptions -- use discovery-oriented methods:

• Problem interviews (qualitative): 8-15 conversations with target customers. Ask about the last time they experienced the problem, what they tried, what it cost them, what they use now. Never ask "would you use X." This is the highest-signal method for problem validation when done with discipline.
• Search volume and keyword analysis: Use Google Keyword Planner data to estimate how many people search for the problem actively. 10K+ monthly searches for a problem-framing keyword is a meaningful signal. Zero searches suggests the problem is not front-of-mind.
• Online community mining: Reddit, niche forums, LinkedIn groups, and industry-specific communities contain raw expressions of frustration. Search for complaint patterns without prompting. Recurring, detailed complaints validate problem existence.
• Support ticket analysis (if applicable): If you or an adjacent company have customer support data, volume and sentiment of complaints related to the problem area is strong signal.

For Solution Assumptions -- use behavioral methods, not surveys:

• Concierge MVP: Deliver the solution manually to 3-5 customers before building anything. Do exactly what the product would do, by hand. If customers adopt the manual version, solution demand is validated. If they do not use the human-delivered version, they will not use the automated one.
• Wizard-of-Oz prototype: Build a front-end interface that looks like a real product but is powered by humans behind the scenes. Users believe they are using the product; the team fulfills requests manually. Tests solution adoption without engineering investment.
• Paper or clickable prototype test: For UI-heavy products, test comprehension and completion rates with a Figma or paper prototype before writing code. Measure task completion rate and time-to-understand. A completion rate below 60% on core tasks indicates usability problems in the solution design.
• Beta test with real usage data: 10-20 users given early access with tracking on feature adoption, return visits, and session depth. If fewer than 30% of beta users return in week 2, retention is failing.

For Willingness-to-Pay and Market Assumptions:

• Fake door / smoke test (landing page + call to action): Build a single-page description of the product with a "Get early access" or "Join waitlist" or "Pre-order" button. Drive traffic via paid ads (minimum $500 budget to get 500+ visitors). Measure conversion rate on the call to action. A 5%+ conversion rate from cold traffic to waitlist signup is a strong positive signal. Below 1% requires explanation -- price too high, message unclear, or market too small.
• Pre-order campaign: Sell the product before it exists. Collect real money (Stripe payment, crowdfunding). This is the strongest willingness-to-pay signal because real money overrides stated preferences. Even 20-30 paying customers from a targeted outreach validates demand.
• Painted door test (B2B): Add a link to a "feature" that does not exist yet within an existing product or website. Measure click rate. If 15%+ of relevant users click on a non-existent feature, demand is real.
• Small-budget paid ad test: Spend $300-$1,000 on Google or Meta ads targeting the customer segment with a clear value proposition. Measure click-through rate (CTR) and cost per click (CPC). A CTR above 2% and CPC under $5 (consumer) or $20 (B2B) for a clear value proposition is a positive channel signal.
• Direct outreach response rate: Send 50-100 cold emails or LinkedIn messages to the exact target customer with a concise problem statement and ask for a 20-minute call. A 15%+ response rate indicates the problem resonates. Below 5% suggests the segment or framing is off.

For Business Model Assumptions:

• Unit economics spreadsheet with sensitivity analysis: Model LTV and CAC at different price points and retention rates. Run three scenarios: pessimistic (churn 8%/month, CAC = $400), base (churn 4%/month, CAC = $200), optimistic (churn 2%/month, CAC = $80). If the pessimistic scenario is a viable business, the model is robust.
• Pricing survey (Van Westendorp Price Sensitivity Meter): Ask four questions -- "At what price would you consider this too cheap to be credible? Acceptable? Getting expensive? Too expensive?" The acceptable range intersection gives a real price window grounded in customer perception, not founder preference.
• Comparable company benchmarks: Find 3-5 analogous businesses (same model, adjacent market) and use their publicly disclosed metrics (average contract value, churn rates, gross margins) as proxies. Not a substitute for your own data, but it frames what "normal" looks like.

Step 6: Define the Three-Outcome Decision Framework Per Experiment

After each experiment concludes, apply a pre-defined decision framework. The decision must be made before seeing results -- the criteria, not the outcome, determine the conclusion.

Proceed: The primary metric met or exceeded the success threshold. The assumption is validated with sufficient confidence to move to the next riskiest assumption. Log the evidence clearly: what method, what sample, what result, what conclusion.

Pivot: The primary metric fell below the success threshold but above the failure threshold, OR the experiment produced unexpected insights pointing to a related but different opportunity. Do not kill the idea -- reformulate the assumption, adjust the segment or framing, design a new experiment, and retest. Pivots are hypothesis refinements, not failures.

Kill: The primary metric fell below the failure threshold for a critical assumption AND the findings do not suggest a viable pivot direction, OR multiple critical assumptions fail in sequence with no clear alternative. Stop investing time and money. Document every finding -- they are valuable for future work and the intellectual honesty of killing a bad idea is itself a competitive advantage.

A crucial rule: you must define the failure threshold, not just the success threshold. Without a floor, every result becomes "encouraging in some ways." The failure threshold is what makes the framework honest.

Step 7: Build the Validation Sprint Timeline

Structure the validation plan as consecutive two-week sprints, each with a single assumption, a single primary experiment, and a hard decision point at the end.

Sprint 0 (Days 1-3): Idea sharpening

• Finalize the idea summary, assumption map, and risk rankings
• Identify the first 3 experiment designs with pre-committed criteria
• Identify 8-15 interview candidates for Sprint 1 if problem validation is the first RAT

Sprint 1 (Days 4-17): Validate the single highest-risk assumption

• Execute the designed experiment
• Collect all data before reviewing results (batch analysis, not rolling rationalization)
• Hold a structured decision meeting: review data against pre-committed criteria, make a proceed/pivot/kill call, document the learning

Sprint 2 (Days 18-31): Validate the second highest-risk assumption

• Same structure; update the assumption map based on Sprint 1 learnings
• If Sprint 1 was a pivot, revise the idea and re-rank the assumption list before beginning Sprint 2

Sprint 3 (Days 32-45): Validate the third highest-risk assumption

• By this sprint, problem validation is typically complete and solution validation or willingness-to-pay is being tested

Gate Decision (Day 46): After three sprints, make the macro go/no-go call. If the top 3 riskiest assumptions have been validated, proceed to Lean Canvas and MVP definition. If not, either redesign and revalidate or kill.

Total time: 6-8 weeks. A validation plan that takes longer than 8 weeks is not a validation plan -- it is a slow build.

Step 8: Synthesize Learnings and Issue a Recommendation

After the full validation sprint (or as much as has been completed), synthesize the results into a structured summary.

• Restate the original idea and the riskiest assumptions tested
• Document each experiment: method, sample, result, verdict (validated / invalidated / inconclusive)
• State an overall confidence level: Low (0-1 critical assumptions validated), Medium (2 validated, 1 in question), High (3+ validated with strong signals)
• Issue a specific recommendation: proceed to MVP definition, pivot and retest with a revised hypothesis, or kill and preserve learnings
• If proceeding, identify the next validation questions that will be answered during the MVP phase itself (not all assumptions must be resolved pre-MVP -- only the critical ones)

Output Format

## Idea Validation Plan: [Idea Name]

### Idea Summary
| Field | Value |
|-------|-------|
| **Product/service** | [One-sentence description -- what it does, not what it is] |
| **Target customer** | [Specific segment with firmographic or demographic qualifiers] |
| **Problem statement** | [Customer frustration in their language, with consequence] |
| **Current alternatives** | [How customers solve this today, including "do nothing"] |
| **Unique value proposition** | [Why customers switch: 10x better/cheaper/faster on which dimension] |
| **Revenue model** | [How money changes hands: subscription/transaction/usage/etc.] |
| **Founder advantage** | [Domain expertise, relationships, data, or distribution edge, or N/A] |

---

### Assumption Map

| # | Assumption | Category | Criticality | Uncertainty | Risk |
|---|-----------|----------|-------------|-------------|------|
| A1 | [Full assumption text] | Problem | H / M / L | H / M / L | H / M / L |
| A2 | [Full assumption text] | Problem | H / M / L | H / M / L | H / M / L |
| A3 | [Full assumption text] | Solution | H / M / L | H / M / L | H / M / L |
| A4 | [Full assumption text] | Solution | H / M / L | H / M / L | H / M / L |
| A5 | [Full assumption text] | Market | H / M / L | H / M / L | H / M / L |
| A6 | [Full assumption text] | Market | H / M / L | H / M / L | H / M / L |
| A7 | [Full assumption text] | Business | H / M / L | H / M / L | H / M / L |
| A8 | [Full assumption text] | Business | H / M / L | H / M / L | H / M / L |

**Riskiest assumptions selected for testing:** A[X] (High/High), A[X] (High/High), A[X] (High/Medium)

**Rationale:** [One sentence explaining why these are the make-or-break assumptions]

---

### Validation Experiments

#### Experiment 1 -- Test Assumption A[X]: [Assumption short title]

| Field | Value |
|-------|-------|
| **Full assumption** | [Complete assumption text] |
| **Hypothesis** | If [condition], then [measurable outcome], because [mechanism] |
| **Experiment method** | [Specific method: problem interviews / landing page / concierge / pre-order / etc.] |
| **Sample size** | [X participants / X page visitors / X email recipients] |
| **Primary metric** | [The one number that determines the outcome] |
| **Success threshold** | [Specific number that validates -- pre-committed] |
| **Failure threshold** | [Specific number that invalidates -- pre-committed] |
| **Decision outcome** | Proceed if ≥ [X] / Pivot if [Y-Z] / Kill if < [Y] |
| **Timeline** | [Start date or sprint] -- [End date or sprint], [X days total] |
| **Cost** | $[X] cash + [X] hours founder time |
| **Data collection method** | [How results will be recorded: interview notes / Typeform / Google Analytics / etc.] |

---

#### Experiment 2 -- Test Assumption A[X]: [Assumption short title]

| Field | Value |
|-------|-------|
| **Full assumption** | [Complete assumption text] |
| **Hypothesis** | If [condition], then [measurable outcome], because [mechanism] |
| **Experiment method** | [Specific method] |
| **Sample size** | [X participants / visitors / etc.] |
| **Primary metric** | [One number] |
| **Success threshold** | [Pre-committed number] |
| **Failure threshold** | [Pre-committed number] |
| **Decision outcome** | Proceed if ≥ [X] / Pivot if [Y-Z] / Kill if < [Y] |
| **Timeline** | [Sprint and days] |
| **Cost** | $[X] cash + [X] hours |
| **Data collection method** | [Method] |

---

#### Experiment 3 -- Test Assumption A[X]: [Assumption short title]

*(Same structure as above)*

---

### Validation Sprint Timeline

| Sprint | Days | Focus | Assumption | Experiment | Primary Metric | Decision Gate |
|--------|------|-------|-----------|------------|----------------|--------------|
| 0 | 1-3 | Idea sharpening | All | Assumption mapping | Assumption map complete | N/A |
| 1 | 4-17 | [Problem / Solution / Market] validation | A[X] | [Method] | [Metric] | Proceed / Pivot / Kill |
| 2 | 18-31 | [Problem / Solution / Market] validation | A[X] | [Method] | [Metric] | Proceed / Pivot / Kill |
| 3 | 32-45 | [Problem / Solution / Market] validation | A[X] | [Method] | [Metric] | Proceed / Pivot / Kill |
| Gate | 46 | Overall decision | All tested | Synthesis | Confidence level | MVP / Pivot / Kill |

---

### Decision Framework

| Decision | Condition | Criteria | Next Step |
|---------|-----------|----------|-----------|
| **Proceed to MVP** | All 3 RATs validated | Primary metrics met success threshold | Use `mvp-definition` skill |
| **Pivot -- reframe problem** | Problem invalidated but related pain found | Interviews reveal adjacent unmet need | Revise idea summary, re-rank assumptions, begin Sprint 1 again |
| **Pivot -- reframe solution** | Problem validated but solution approach rejected | Users want the outcome, not the proposed mechanism | Redesign solution experiment, retest A[X] |
| **Pivot -- reframe segment** | Problem exists but not for stated segment | Different profile emerges in interviews | Redefine target customer, re-rank assumptions |
| **Kill** | Critical assumption invalidated, no pivot signal | Primary metric below failure threshold, no alternative insight | Stop, document full learnings |

---

### Validation Confidence Summary (fill in after experiments)

| Assumption | Status | Evidence | Confidence |
|-----------|--------|----------|-----------|
| A[X] | Validated / Invalidated / Inconclusive | [What data says] | High / Medium / Low |
| A[X] | Validated / Invalidated / Inconclusive | [What data says] | High / Medium / Low |
| A[X] | Validated / Invalidated / Inconclusive | [What data says] | High / Medium / Low |

**Overall Validation Confidence:** Low / Medium / High
**Recommendation:** [Proceed / Pivot / Kill] -- [One sentence rationale]

Rules

1. Test the problem before testing the solution, always. Building a solution for a non-existent or non-painful problem is the single most common cause of startup failure. Problem validation must precede solution validation regardless of how confident the founder feels. Domain expertise does not exempt you from this rule.

2. Pre-commit all success and failure thresholds before running any experiment. If criteria are set after results are seen, the human brain will rationalize any outcome as positive. Write the thresholds in the plan before a single interview is conducted or a single ad dollar is spent.

3. "Would you use this?" is not a valid interview question. People cannot reliably predict their own future behavior. The only reliable interview data comes from past behavior: "Tell me about the last time you experienced this problem. What did you do? What did you try? What did it cost you?" Future-directed hypothetical questions produce optimistic but meaningless responses.

4. Experiments must be cheap enough to be discardable. If an experiment costs more than $5,000 or takes more than 4 weeks, it has crossed from validation into early product development. Redesign it to be cheaper and faster. The whole point of validation is to fail cheaply and quickly, not to invest before you know.

5. Separate the founder's conviction from the evidence. Founders who are deeply passionate about their ideas will unconsciously select confirming evidence. For each experiment result, ask: "If a skeptical investor saw only this data with no context, would they be convinced?" If not, the evidence is not yet sufficient.

6. "Interesting" and "people liked it" are not validated outcomes. The validation plan must translate every experiment into a binary: the threshold was met or it was not. Qualitative summaries like "people were really excited" without a specific, countable backing signal are not validation.

7. A marketplace, platform, or network-effect business requires validating both sides of the market independently. Never declare a two-sided idea validated by testing only one side. Supply-side validation and demand-side validation are separate experiments with separate success criteria.

8. Willingness to pay requires a real behavioral test, not a stated preference. Asking "How much would you pay for this?" produces inflated numbers. Only actual money collected (pre-orders, paid pilots, deposits) or a fake door experiment with real call-to-action conversion validates price point. Survey responses about price are directional only.

9. Document every experiment result, including invalidations. The learning from a failed hypothesis is often more valuable than the result of a successful one. Documented invalidations also prevent re-testing the same failed assumption in a future iteration, which is a surprisingly common waste.

10. Identify the next 3 assumptions that will be tested during the MVP phase. Not all assumptions must be resolved pre-MVP -- doing so would require building the product anyway. The goal of pre-MVP validation is to resolve the assumptions that could kill the idea entirely. Remaining assumptions should be staged into the MVP's metrics plan.

11. A high-signal validation result from a non-representative sample is unreliable. Ten enthusiastic responses from the founder's personal network are not validation -- they are a convenience sample with massive selection and social desirability bias. The sample must come from the actual target customer segment, reached through cold or independent channels.

12. Regulatory feasibility is an assumption in health, finance, insurance, legal, and education ideas. A business model that violates HIPAA, SEC regulations, state licensing requirements, or FTC rules is not a viable business regardless of market demand. Add regulatory feasibility as a critical assumption and validate it early by consulting a domain expert or attorney, not by building first.

Edge Cases

B2B Ideas Where the Buyer and User Are Different People

In enterprise or mid-market B2B contexts, the person who signs the contract (buyer: CFO, CTO, department head) is rarely the person who uses the product daily (user: analyst, operations manager, front-line worker). Both must be validated separately with different experiments. Validate with the buyer: "Will they authorize budget and sign a contract?" Validate with the user: "Will they actually adopt and use this?" Products that buyers purchase but users reject become shelfware within 90 days, resulting in non-renewal. Design one problem interview track for each persona and check for alignment -- sometimes the buyer and user have conflicting incentives (e.g., a cost-reduction tool the buyer wants but the user fears as a job-threat).

Hardware and Physical Product Ideas

Physical prototypes are expensive, making the standard lean startup loop harder to execute. Apply staged validation: First, validate the problem and willingness-to-pay entirely through interviews, online community research, and fake door tests before touching hardware. Second, validate solution viability using 3D renders, explainer videos, or simulations to test desirability before building anything. Third, use pre-order campaigns (with real payment collection via Stripe or Kickstarter) as the willingness-to-pay test before manufacturing. Only after demand and willingness-to-pay are confirmed should a first physical prototype be built. The cost of the first prototype is the cost of learning, not the cost of the product.

Idea in a Two-Sided or Multi-Sided Market

Marketplaces and platforms face a chicken-and-egg problem: neither side has value without the other. The validation challenge is sequencing. Identify which side is the harder supply constraint -- this is almost always the professional, service provider, or inventory side. Validate that side first. Use a "concierge marketplace" approach: manually recruit 10-20 supply-side providers and 10-20 demand-side users and make matches by hand, entirely outside any technology. Track whether transactions actually complete and whether both sides return. If the concierge version does not produce repeated transactions, an automated marketplace version will not solve the underlying problem. Only after manual matching validates both sides should platform development begin.

Technical or Deep Technology Ideas

When the solution depends on technology that may not yet work at the required performance level (AI accuracy thresholds, hardware battery life, material cost curves, latency requirements), technical feasibility itself is a critical assumption that must be staged into the validation plan. Separate technical feasibility validation from market demand validation. Test market demand first (interviews, fake door tests, pre-orders) -- there is no point proving the technology works if nobody wants it. Then validate technical feasibility through minimum technical experiments (proof of concept at lab scale, API prototype, trained model on sample data) before full product development. The sequence is: market risk first, technical risk second.

Founder with Deep Domain Expertise and Strong Prior Conviction

Domain expertise is a genuine asset for identifying real problems and credible solutions, but it carries a specific validation risk: the founder may assume the problem is so obvious that validation is unnecessary, or may unconsciously design validation experiments that are easy to pass. Counter this by requiring cold outreach to customers the founder does not personally know -- familiar contacts are too likely to provide socially encouraging responses. Specifically, require that at least 60% of interview or experiment participants have no prior relationship with the founder. Also require the founder to write down their strongest counter-argument to the idea before validation begins. This surfaces the most important invalidation scenarios and ensures the experiments are designed to probe weak points, not confirm strong points.

Pivot During Validation -- Mid-Sprint Adjustment

Sometimes an experiment produces unexpected signal before the sprint ends -- a different customer profile emerges in interviews, a completely different use case keeps coming up, or the problem as stated is wrong but a related adjacent problem is clearly present. Do not continue the planned experiment mechanically when the data is already pointing elsewhere. Acknowledge the insight, pause the current experiment, and perform a structured pivot assessment: Is the new signal strong enough to change the direction? Does the new direction require a fundamentally different assumption map? Who is the new target customer? Pivots during validation are not failures -- they are the lean startup methodology working correctly. Document the original hypothesis, the unexpected finding, the revised hypothesis, and the new experiment design. Do not simply change direction without updating the formal plan.

Validation for a Regulated Industry (Health, Finance, Legal, Education)

Regulatory constraints can invalidate an otherwise well-validated idea. Treat regulatory feasibility as a critical assumption with its own experiment: identify the specific regulatory framework governing the proposed service (HIPAA for health data, SEC/FINRA for investment advice, state bar requirements for legal services, state insurance licensing, FERPA for education data). Identify whether the proposed business model requires a license, certification, or compliance program that the founding team does not yet possess. Consult with a relevant attorney or compliance expert early -- this is a validation experiment with a cost of $500-$2,000 and a potential outcome of "idea is not viable in current form." This consultation belongs in Sprint 1 alongside problem validation, not Sprint 5 after the product is built.

Example

Input: "I want to start a B2B SaaS service that helps small restaurant owners optimize their menu pricing using data analytics. They would upload their weekly sales data as a CSV and get recommendations on which items to reprice, which to remove, and which to promote. I'm thinking $149/month. I used to work as a food and beverage consultant for 8 years so I know this space well."

Output:

Idea Validation Plan: MenuPulse -- Restaurant Menu Pricing Analytics

Idea Summary

Assumption Map

Riskiest assumptions selected for testing: A1 (H/H), A4 (H/H), A8 (H/H), A7 (H/H)

Rationale: If owners do not feel the pricing problem acutely (A1), there is no market. If they feel it but will not trust automated recommendations (A4), the product does not solve the problem for them. If they trust it but will not pay $149/month (A8), the business model fails. And if they would pay but cannot be reached digitally at a sustainable CAC (A7), the go-to-market is broken. All four must pass for the idea to work.

Validation Experiments

Experiment 1 -- Test A1 + A2: Restaurant owners feel menu pricing is a painful, unsolved problem

…(truncated)