---

name: idea-validation
description: "Identify the assumption that kills your idea if wrong, design 3-4 tests that produce real signal, and build a 2-week go/no-go playbook — before writing a line of code."

/idea-validation

Forty hours building something nobody wants is the most common indie hacker mistake — and it's almost never caused by laziness. It's caused by testing the wrong assumption. "Would you use this?" is not a test. A landing page signup is not a test. A Reddit post getting upvotes is not a test. This skill forces you to name the riskiest assumption your idea depends on, design tests that produce falsifiable signal, and set the success criteria before you see the results — so confirmation bias can't sneak in.

Idea Crystallization

• State the problem in one sentence, from the customer's perspective: "People who [are in this situation] struggle to [do this specific thing] because [underlying constraint]."
• Who specifically has this problem — a job title, a life stage, a behavior pattern. Not "small business owners." "Solo consultants who invoice 10-15 clients per month and spend 3 hours a week on billing."
• How are they solving it today? Name the actual tools, workarounds, or behaviors.
• What makes your solution different from just doing it better in the existing tool?
• What does this need to earn (revenue, users, traction signal) to be worth building in full?

The Riskiest Assumption

Every idea has one assumption that, if wrong, makes everything else irrelevant. Not "will people use it" — that's too vague. Which specific assumption kills this?

Common riskiest assumptions:

• "Customers have this problem acutely enough to pay for it" (vs tolerate it for free)
• "The person with the problem is also the person who pays" (vs someone else in the org)
• "Customers will switch from their current solution" (vs add another tool they also don't use)
• "There are enough of these customers reachable at a CAC that works" (distribution assumption)
• "I can build this in a way that solves the problem" (feasibility assumption)

Name your riskiest assumption. If you're not sure, ask: "what is the most optimistic thing I'm assuming that I haven't actually tested?"

3-4 Targeted Tests — each must produce a yes/no signal, not qualitative warmth:

For each test: what you're testing, how you run it, what the success criterion is, and how long it takes.

Good tests:

• "5 people in my ICP pay upfront for early access before the product exists" — tests willingness to pay
• "Post a specific problem description in 3 communities, measure DM rate vs view rate" — tests problem acuity
• "Run a manual concierge version of the product for 3 customers for 2 weeks" — tests whether your solution actually solves it
• "Build a Typeform with a fake 'waitlist' checkout and measure conversion" — tests conversion intent

Bad tests:

• Surveys asking "would you use this?" (people lie to be nice)
• Landing page signups without a payment or commitment gate (cost to sign up is zero)
• Twitter polls (wrong audience, no skin in the game)

Success Criteria — set these before you see results:

For each test: the specific number that makes you proceed vs stop. e.g., "If fewer than 3 of 10 discovery calls result in the person asking how to get early access, the problem isn't acute enough — stop."

Set these before you run the tests. Post-hoc success criteria are how you talk yourself into building things nobody wants.

The 2-Week Playbook

Day 1-3: Problem interviews — 10 conversations with specific, reachable people in your ICP. Goal: confirm the problem is real and acute.
Day 4-7: Demand test — one of the above tests that puts something real on the line (money, commitment, effort from the customer).
Day 8-12: Concierge test — manually deliver the solution to 2-3 people who passed the demand test.
Day 13-14: Decision — apply go/no-go criteria.

Go/No-Go Framework

Go if: [specific thresholds from your success criteria above]
Pivot if: [problem confirmed, solution rejected — different format or ICP]
Stop if: [problem not confirmed, or confirmed but nobody will pay / switch]

Name in advance: what would make you pivot vs stop? The difference is whether people acknowledge the problem but reject your solution, or don't acknowledge the problem at all.

Rules

1. The riskiest assumption must be named before designing tests. Testing the wrong assumption is the root cause of wasted builds.
2. Success criteria must be set before results are visible. Without pre-set criteria, any result can be rationalized as a pass.
3. Demand tests must have a commitment gate — something that costs the tester time, money, or social capital. Costless signals are noise.
4. "I'll know it when I see it" is not a success criterion. If you can't write the number down, you're not ready to run the test.
5. Two weeks is the maximum. If you can't get signal in 14 days, the problem is either too niche to find customers or you don't have distribution to reach them — both are important signals.

The output of this skill is a validation brief: the riskiest assumption, 3 tests with success criteria, the 2-week calendar, and the explicit go/no-go statement — ready to execute the next morning.