About idea-validation
A staged idea-validation skill for founders and product teams. It combines demand signals, customer interviews, inexpensive assumption tests, and explicit kill checks to help decide whether to proceed, revise, or stop.
Key features
- 01Four-part problem definition check
- 02Demand signals from multiple sources
- 03Solution-fit assessment
- 04Customer interview and signal tracking
- 05Time-boxed, low-cost assumption tests
- 06Weighted go/no-go scorecard
Use cases
- 01Check whether a problem is clear and worth solving
- 02Use interviews to confirm customer pain and willingness to pay
- 03Test a critical business assumption cheaply
- 04Compare ideas and set priorities
Install
Copy the command and run it in a terminal.
npx skills add https:/ / github.com/ jk-0001/ skills --skill idea-validationAfter installing, type/idea-validationin Claude Code to confirm it loaded.
Details
From the project READMEIdea Validation
Overview
Kill bad ideas fast, confirm good ones cheaply. Walk through every phase in order. Each phase has a kill-check — if the idea fails, document why and stop before wasting further time.
Step 1: Problem Definition
Everything starts here. A vague problem = a vague business.
Answer these four questions precisely:
- Who — The exact person. Not "small businesses." Something like "freelance graphic designers juggling 3-8 client projects at once."
- What — The specific painful moment. "They spend 4+ hours/week manually exporting deliverables and coordinating revision feedback via email chains."
- Why it hurts — The real cost: time lost, revenue lost, stress, missed deadlines, damaged relationships. Quantify where possible.
- What they do now — Their current workaround. This IS your real competition — not just competitor apps, but the status quo itself.
Kill check: Cannot answer all four concretely → problem is not well-defined. Do more discovery first.
Step 2: Demand Signal Gathering
Prove real people care. Do not rely on assumptions or polite friends.
Check 3+ of these signal sources:
| Signal | Where | Positive Signal |
|---|---|---|
| Search volume | Google Trends, Ubersuggest free | Stable or growing volume on core problem keywords |
| Forum pain | Reddit, HN, Slack/Discord | Threads with 10+ comments describing this exact pain |
| Existing tool gaps | G2, App Store reviews | Tools solving adjacent problems with reviews citing the gap you'd fill |
| Job postings | LinkedIn, Indeed | Roles that exist only because this problem is expensive to solve manually |
| Social venting | Twitter/X search, LinkedIn | People publicly complaining about this unprompted |
Kill check: Fewer than 3 positive signals → problem may not be painful enough. Pivot or kill.
Step 3: Solution Fit Check
Pressure-test whether your proposed solution actually solves the problem well enough to build a business on.
- 10x rule: Is your solution 10x better (not 10%) than the current workaround in speed, cost, ease, or quality? Marginally better won't make people switch.
- Workflow change audit: Map exactly what the user must change in their current routine. High friction = low adoption.
- Solo-build feasibility: Can a working MVP be built by one person in weeks-to-a-few-months? If it needs a 10-person engineering team, that's a different company.
- Unfair advantage: Why you specifically? Skills, industry access, data, network, credibility — something competitors can't easily replicate.
Kill check: Fail the 10x rule or have zero unfair advantage → move on.
Step 4: Customer Discovery (Talk to Humans)
10-15 conversations with real potential customers. Non-negotiable. No amount of desk research replaces this.
Finding people:
- Post in 2-3 relevant communities asking for 15-min feedback chats.
- DM matching personas on LinkedIn or Twitter.
- Offer a small incentive if needed (gift card, free future access).
Conversation flow (15-20 min):
1. CONTEXT (2 min)
"Tell me about your work. Walk me through a typical week
around [problem area]."
→ Listen only. Do NOT pitch or explain your idea.
2. PAIN EXPLORATION (5 min)
"What's the most frustrating part of [workflow]?"
"How often does that come up?"
"What have you already tried to fix it?"
"What's still missing?"
→ Ask "why" and "what happens when" repeatedly. Dig.
3. OUTCOME PROBING (3 min)
"If a tool could [describe the outcome, not your feature set],
how would that change things?"
"What would that be worth — in time, money, stress?"
→ Let them quantify. Never suggest a number first.
4. WILLINGNESS TO PAY (2 min)
"Would you pay for something like that? What range feels fair?"
→ Discount stated numbers by ~50% when planning.
5. WARM REFERRAL (1 min)
"Know anyone else who hits this same wall? Mind if I reach out?"
Track across all conversations:
- % who described the problem without prompting (pain signal)
- % currently spending real money or time on workarounds (revenue signal)
- % with clear willingness to pay (demand signal)
- Features multiple people independently requested (product signal)
- Assumptions you held that conversations proved wrong (kill features early)
Kill check: Fewer than 60% confirm pain + willingness to pay → rework or kill.
Step 5: Riskiest Assumption Test (RAT)
One assumption, if wrong, kills everything. Find it. Test it in under 2 weeks and $200.
Common riskiest assumptions and cheap tests:
| Assumption | Minimum Test | Pass Threshold |
|---|---|---|
| People will pay | Landing page + "pre-order" button. Drive 200 targeted visitors. | 3-5% convert to payment/deposit |
| CAC is affordable | Run $100 targeted ad campaign. Measure cost-per-lead. | CPL < 20% of planned customer lifetime value |
| People will change workflow | Offer a manual version of the service to 5 people for free. See if they actually use it. | 3+ out of 5 use it consistently |
| I can build it solo | Build the single hardest technical feature as a prototype first. | Working prototype in ≤ 2 weeks |
Process:
- State the assumption.
- Define what "confirmed" looks like (a concrete, measurable number).
- Design the cheapest possible test.
- Set a hard deadline (max 2 weeks).
- Run it. Record results with zero spin.
Kill check: RAT fails → idea in current form is not viable. Pivot the solution, the customer, or the model — or kill entirely.
Step 6: Go / No-Go Scorecard
| Dimension | Score (1-5) | Weight |
|---|---|---|
| Problem severity & clarity | __ | 20% |
| Demand evidence gathered | __ | 15% |
| Customer discovery confirmation | __ | 20% |
| Solution fit (10x + feasibility) | __ | 15% |
| RAT result | __ | 20% |
| Your unfair advantage | __ | 10% |
Weighted score = Σ (score × weight)
- 4.0–5.0 → GO. Move to MVP planning + business model canvas.
- 3.0–3.9 → CONDITIONAL GO. Resolve the weakest dimension with one more test round first.
- < 3.0 → NO-GO. Kill or fundamentally pivot. Write down lessons.
Idea Validation Mistakes to Avoid
- Not documenting findings in one place — insights scattered across notes, emails, and chats become useless. Keep one running "Idea Validation" doc from day one.
- Letting validation drag on indefinitely. Time-box the entire process to 2-3 weeks max. Validation paralysis is as fatal as skipping it entirely.
- Testing one idea in isolation. Run 2-3 ideas in parallel when possible — the comparison sharpens judgment and reveals which assumptions you're making about all of them.
- Confusing polite interest with real demand. Friends and colleagues will say nice things. Pay-or-commit signals from strangers are the only ones that count.
- Skipping the kill checks. Each phase has a kill check for a reason. Ignoring a failed check and pressing forward wastes weeks or months on a dead-end idea.