Purpose
Surface every assumption a product bet quietly depends on, rank them by how likely they are to be wrong and how cheaply they can be tested, and hand back a prioritized validation queue so teams spend discovery effort on the assumptions that can actually kill the bet — not the ones that feel urgent.
When to Use
Invoke this skill when the user asks to:
- Decide what to validate first before committing engineering to a build
- De-risk a roadmap bet, feature, or new product line before investing
- Pressure-test the logic and assumptions behind a product decision
- Turn a vague "we think this will work" into a concrete validation plan
- Prioritize discovery experiments when there are more questions than time
- Justify to leadership why a bet is or isn't ready to build
Inputs Required
Before starting, collect:
- The bet: 2–4 sentence description of the product, feature, or change being considered
- The expected outcome: What the team believes will happen (the value hypothesis)
- Target user/segment: Who this is for
- Stage: Idea / Pre-build discovery / In development / Post-launch iteration
- Known constraints: Time, budget, engineering capacity, or hard deadlines
- What's already known: Any existing data, research, or signals that bear on the bet
- Risk appetite: Conservative (validate heavily) / Balanced / Aggressive (build to learn)
If risk appetite or stage is missing, assume Balanced / Pre-build discovery and note the assumption.
Instructions
Step 1: Extract the Assumptions
Decompose the bet into its underlying assumptions across four categories. Most bets hide 8–15 assumptions; force at least 2 per category.
- Desirability assumptions: Do users actually want this? Will they care enough to change behavior?
- Viability assumptions: Does this make business sense? Will it drive the metric, monetize, or retain?
- Feasibility assumptions: Can it be built well enough with available resources and tech?
- Usability assumptions: Will users understand and successfully use it without friction?
State each assumption as a falsifiable claim ("Users will pay $X for Y"), not a question. Reframe vague beliefs into testable statements.
Step 2: Score Each Assumption on Two Axes
Risk (how damaging if wrong) — score 1–5:
- 5 = If false, the entire bet collapses (a leap-of-faith assumption)
- 3 = If false, the bet needs significant rework but survives
- 1 = If false, minor adjustment; the bet stands
Weight by both likelihood of being wrong and severity of being wrong. A confident assumption with catastrophic downside still scores high.
Testability (how cheaply/quickly it can be validated) — score 1–5:
- 5 = Can be tested in days with existing data, a quick interview, or a fake-door test
- 3 = Requires a structured experiment, prototype, or a week+ of effort
- 1 = Can only be truly validated by building and shipping it
Step 3: Plot on the Risk–Testability Matrix
Assign each assumption to a quadrant:
- Test Now (High Risk / High Testability): The priority queue — these can sink the bet and are cheap to check. Validate first.
- Plan to Test (High Risk / Low Testability): Dangerous but expensive to test — design the cheapest possible proxy experiment or a staged build to learn.
- Monitor (Low Risk / High Testability): Spot-check if convenient; don't over-invest.
- Note & Move On (Low Risk / Low Testability): Document and accept the risk; not worth discovery time.
Step 4: Build the Validation Plan for Top Assumptions
For every assumption in Test Now and Plan to Test (target the top 5–7), specify:
- Validation method: e.g., user interviews, fake-door/smoke test, prototype usability test, A/B test, data analysis, concierge MVP, willingness-to-pay test
- Success threshold: The concrete signal that validates or invalidates it (e.g., "≥40% of 20 interviewed users describe this pain unprompted")
- Effort estimate: Hours / Days / Weeks
- Kill-or-continue rule: What result would stop the bet vs. justify proceeding
Step 5: Deliver the Sequenced Recommendation
Order the top assumptions into a validation sequence — riskiest-and-cheapest first. State a clear go/no-go gate: which assumptions must hold before any code is written. Be opinionated about whether the bet is ready to build.
Output Format
- Structure: Assumption inventory by category → scored table → quadrant map → validation plans → sequenced recommendation
- Length: 900–1,300 words
- Format: Scored table for the assumption inventory (Assumption | Category | Risk 1–5 | Testability 1–5 | Quadrant); structured bullets for validation plans
- Sections: Assumption Inventory → Risk–Testability Scoring Table → Quadrant Map → Validation Plans (top 5–7) → Sequenced Recommendation & Build Gate
- Tone: Discovery-minded product lead — skeptical, evidence-first, decisive about what to test and what to ignore
Quality Checklist
Before delivering output, verify:
- [ ] At least 8 assumptions extracted, with a minimum of 2 in each of the 4 categories
- [ ] Every assumption is phrased as a falsifiable claim, not a question
- [ ] Each assumption has both a Risk score (1–5) and a Testability score (1–5) and an assigned quadrant
- [ ] Each top validation plan names a specific method, a numeric success threshold, and a kill-or-continue rule
- [ ] The final recommendation sequences assumptions riskiest-and-cheapest first
- [ ] A clear build gate is stated — which assumptions must hold before committing to build
Notes
- The highest-leverage move in discovery is finding the cheapest test for the riskiest assumption — that's why the Test Now quadrant is the deliverable's core.
- Teams systematically over-test feasibility (engineers' instinct) and under-test desirability (the assumption most likely to be wrong). Watch for this skew in the scoring.
- A "leap-of-faith assumption" (Risk 5, Testability 1) is the most dangerous profile — flag any that exist and force the cheapest possible proxy experiment rather than accepting "we'll find out when we ship."
- If the bet has fewer than 6 real assumptions, it's probably described too vaguely — push to decompose the value hypothesis further.
How to use this skill
This file is a Claude Code skill in Anthropic's standard format — markdown with YAML frontmatter at the top.
Installing in Claude Code:
~/.claude/skills/<folder-name>/SKILL.md— auto-loads in every session anywhere on your machine (recommended for skills you'll use across multiple projects)<your-project>/.claude/skills/<folder-name>/SKILL.md— auto-loads only when working in that project (recommended for project-specific skills)
Restart Claude Code or open a new session to register.
Using in Claude.ai, ChatGPT, Gemini, or other AI tools:
- Drag this file into a new chat, or copy and paste its contents
- Send your task or request as your next message — the AI will apply the skill where it fits
For Claude Code skill details: https://docs.anthropic.com/en/docs/claude-code/skills