菜单
Use when testing a product idea before committing to building it, or when a team needs to validate a key assumption with the smallest possible experiment. Triggers on: "hypothesis", "experiment design", "가설 검증", "실험 설계", 최소 테스트", "fake door test",
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/newkayak12/claude-skills --skill hypothesis-driven-dev命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
基于 SOC 职业分类
正在显示 SKILL.md
| name | hypothesis-driven-dev |
| effort | high |
| description | Use when testing a product idea before committing to building it, or when a team needs to validate a key assumption with the smallest possible experiment. Triggers on: "hypothesis", "experiment design", "가설 검증", "실험 설계", 최소 테스트", "fake door test", |
| license | MIT |
| metadata | {"author":"wondelai","version":"1.0.0"} |
| scenarios | ["Help me write a hypothesis for this feature before we start building.","이 아이디어를 검증하기 위한 가장 작은 실험이 뭘까?","Which assumptions are the riskiest in this product bet?","가설 주도 개발로 불확실성을 줄이는 방법을 알려줘.","Design a fake door test for this feature to measure demand.","Build-Measure-Learn 루프를 어떻게 팀에 적용하면 될까?"] |
| compatibility | {"recommended":["think-tool"],"optional":["sequential-thinking","mcp-reasoner"],"remote_mcp_note":"think-tool이 있으면 가설의 반증 가능성과 가장 위험한 가정을 체계적으로 검토하는 데 도움이 됩니다. Claude 설정 → MCP Servers에서 remote SSE 엔드포인트를 추가하세요."} |
A framework for making product decisions based on validated learning rather than opinion, authority, or tradition. Synthesizes Eric Ries's Build-Measure-Learn loop from The Lean Startup with Teresa Torres's Continuous Discovery framework, creating a disciplined path from assumption to evidence to decision.
Every product decision is a hypothesis. The question is whether you test it before or after building it. Hypothesis-driven development makes the implicit explicit: "We believe [action] will result in [outcome] for [customer segment]. We'll know we're right when [measurable signal]." This structure separates what you know from what you assume, and forces you to design the smallest possible test.
The foundation: The core loop is Build-Measure-Learn: form a hypothesis → design the smallest viable test → measure the real signal → decide based on evidence. Teresa Torres adds the opportunity tree: start with the desired outcome → map the opportunity space → generate solution ideas → design experiments. Together, these frameworks create a disciplined alternative to building by instinct or stakeholder pressure.
When a user asks to write a hypothesis, produce:
When a user asks to evaluate their practice, produce:
Goal: 10/10. When evaluating a team's hypothesis-driven practice, rate 0-10. A 10/10 means the team explicitly states hypotheses before building, designs minimum viable experiments, measures real behavior (not surveys), and makes clear decisions based on results. Always provide the current score and specific improvements.
Core concept: A hypothesis is a structured, falsifiable prediction about what will happen if you take a specific action. A well-formed hypothesis has four parts: who the customer is, what action you're taking, what outcome you expect, and how you'll measure it. If any part is missing, the hypothesis cannot be tested.
Why it works: Vague intentions ("improve engagement") cannot be falsified, tested, or learned from. Explicit hypotheses force clarity about assumptions, define success in advance, and create the pre-mortem structure that prevents post-hoc rationalization ("we knew it would work").
Key insights:
Practice applications:
| Context | Pattern | Example |
|---|---|---|
| Feature hypothesis | Full four-part structure | "We believe adding in-app onboarding tooltips for new B2B users will increase 7-day activation from 23% to 35%. We'll know we're right when tooltips-group activation exceeds 35% in a 2-week A/B test." |
| Value hypothesis | Customer want | "We believe SMB owners want automated invoice reminders because late payments are their #1 cash flow problem." |
| Growth hypothesis | Acquisition/retention | "We believe users who invite a teammate in week 1 retain at 2x the rate of solo users." |
| Usability hypothesis | Interaction assumption | "We believe users can complete the new checkout flow without help in under 3 minutes." |
| Abandonment criteria | Pre-commit to stopping | "If the feature doesn't move 7-day retention by at least 5pp in 4 weeks, we remove it." |
Core concept: Before designing any experiment, surface all assumptions embedded in your hypothesis. Map them on two axes: how critical they are to the hypothesis (if wrong, the whole bet fails) and how much evidence you already have. Prioritize testing assumptions that are high-criticality and low-evidence.
Why it works: Teams often jump to testing their solution when the riskiest assumption is about the problem. If your foundational assumption (customers have this pain) is wrong, no solution experiment will save you. Assumption mapping forces you to test in the right order.
Key insights:
Practice applications:
| Context | Pattern | Example |
|---|---|---|
| Assumption extraction | List all "we believe" statements | "We believe: (1) users don't read error messages, (2) they want inline help, (3) inline help reduces support tickets" |
| Risk ranking | Criticality × evidence matrix | "Assumption 1: low evidence, high criticality → test first. Assumption 3: medium evidence, medium criticality → test second." |
| Evidence audit | What do we already know? | "We have support ticket data showing 40% are 'how do I...' questions — this supports assumption 2 with existing evidence" |
| Experiment prioritization | Test the riskiest first | "Don't design the inline help UI until we know users will engage with it — test that assumption first" |
| Assumption invalidation | When evidence contradicts | "Data shows users do read error messages — drop assumption 1, redesign the experiment" |
Core concept: A Minimum Viable Experiment is the smallest, fastest test that produces enough evidence to make a decision. It is not about building the minimum viable product — it is about designing the minimum effort to test a specific assumption. Concierge tests, fake door tests, wizard of oz, and landing page tests are all MVEs.
Why it works: Teams default to building because that's what they know how to do. But building is the most expensive form of learning. An MVE produces the same learning at a fraction of the cost, enabling many more experiments in the same time period.
Key insights:
Practice applications:
| Context | Pattern | Example |
|---|---|---|
| Value assumption | Concierge test | "Before building auto-reminders, manually send reminders via email for 10 customers — measure response rate" |
| Demand assumption | Fake door test | "Add 'Invoice Analytics' to the nav — measure click rate before building the feature" |
| Usability assumption | Clickable prototype | "Figma prototype of new checkout — 5 user sessions with think-aloud, before any engineering" |
| Scale assumption | Wizard of Oz | "Route 'AI suggestions' through a human reviewer for 2 weeks — prove value before building the model" |
| Optimization | A/B test in production | "Test two subject lines for invoice reminder emails — measure open rate and payment completion rate" |
Core concept: The Build-Measure-Learn loop is the operational cadence of hypothesis-driven development. Build: create the minimum necessary to test. Measure: collect the real signal (behavior, not opinion). Learn: decide based on evidence — persevere (the hypothesis was right), pivot (wrong on one assumption, change direction), or stop (the whole bet is wrong).
Why it works: Without an explicit loop, teams build → release → move on. Learning is implicit at best. The loop makes learning the explicit product of every cycle, and forces a decision point after every experiment: what do we now believe, and what do we do next?
Key insights:
Practice applications:
| Context | Pattern | Example |
|---|---|---|
| Full loop | BML cycle | Build: fake door for analytics. Measure: 18% of users clicked. Learn: demand confirmed — persevere to prototype. |
| Persevere decision | Evidence supports hypothesis | "Concierge reminders had 80% response rate — build the automation" |
| Pivot decision | Assumption wrong, direction changes | "Users don't want reminders — they want to see payment status. Pivot to payment tracking." |
| Stop decision | Core bet is wrong | "Even with reminders, no one paid faster — the problem isn't reminders, it's pricing. Stop." |
| Loop documentation | Learning record | "Experiment: fake door. Result: 3% CTR. Decision: demand too low — stop and reassess the opportunity" |
Core concept: An opportunity tree is a visual map that connects the desired outcome (company or product goal) to the opportunity space (customer needs, pain points, desires), to solution ideas, to experiments. It organizes the discovery process so that every experiment connects back to the outcome the team is trying to achieve.
Why it works: Without an opportunity tree, experiments are disconnected: teams run tests based on intuition or stakeholder requests with no clear line to the business outcome. The tree creates a navigable map: "We're trying to achieve X. Here are the opportunities that serve X. Here are solutions for each opportunity. Here are the experiments to validate each solution."
Key insights:
Practice applications:
| Context | Pattern | Example |
|---|---|---|
| Outcome definition | Top of tree | "Desired outcome: increase 30-day retention from 42% to 58%" |
| Opportunity discovery | Level 2, from interviews | "Opportunity: users don't understand what to do after signup — they feel lost" |
| Solution generation | Level 3, multiple per opportunity | "Solutions: (1) in-app checklist, (2) email drip, (3) progress bar, (4) product tour" |
| Experiment design | Level 4, one per solution assumption | "Experiment for solution 1: prototype the checklist, test with 5 new users, measure task completion" |
| Tree pruning | Remove invalidated branches | "3 interviews confirmed the 'feel lost' opportunity — other branches de-prioritized" |
| Mistake | Why It Fails | Fix |
|---|---|---|
| Implicit hypotheses | Can't be falsified; post-hoc rationalization is inevitable | Write the hypothesis explicitly before designing the experiment |
| Testing the solution, not the assumption | Most critical assumptions are about the problem, not the feature | Run assumption mapping first; test the riskiest assumption, regardless of what that requires |
| Using surveys to measure behavior | People say one thing and do another | Measure real behavior: clicks, conversions, retention — not survey responses |
| MVE is not minimum | Teams build full features "to get good data" | Define the smallest test that answers the hypothesis question; build no more than that |
| No decision after the loop | Learning is acknowledged but doesn't change direction | Require a documented decision: persevere, pivot, or stop — after every experiment |
| Skipping the tree | Experiments don't connect to outcomes | Build the opportunity tree before running experiments; trace every experiment to an outcome |
| Pivoting too early | One bad data point triggers a direction change | Define the sample size and confidence threshold before running the experiment; don't pivot on noise |
| Question | If No | Action |
|---|---|---|
| Is every initiative described as an explicit hypothesis? | Decisions are made by opinion or authority | Write the hypothesis before designing the solution: belief + customer + outcome + metric |
| Have the riskiest assumptions been identified and prioritized? | Teams jump to testing solutions before problems | Run assumption mapping; rank by criticality × evidence; test high-risk first |
| Are experiments designed to be minimum viable? | MVPs are too large and take too long | Ask: "What's the smallest thing that tests this specific assumption?" |
| Are real behavior metrics being measured (not surveys)? | Data is self-reported preference, not actual behavior | Instrument real behavior: click tracking, completion rates, retention, conversion |
| Is there a documented decision after each experiment? | Learning happens but direction doesn't change | Require a written learning record: what we tested, what we found, what we're doing next |
| Does the opportunity tree connect experiments to the desired outcome? | Experiments feel disconnected from business goals | Build or update the opportunity tree before the next experiment cycle |
| Claude | You |
|---|---|
| Writes the four-part hypothesis formula and null hypothesis | Validates hypothesis against real business context |
| Identifies riskiest assumptions with criticality × evidence matrix | Conducts the actual customer interviews and experiments |
| Recommends MVE type matched to assumption type | Instruments real behavior tracking and reads results |
| Scores team's hypothesis-driven practice (0-10) | Makes persevere / pivot / stop decisions after each loop |
| Builds opportunity tree structure from provided outcomes | Owns weekly discovery cadence and team alignment |
../customer-research-synthesis/SKILL.md — feeds validated hypotheses into experiment design../feature-prioritization/SKILL.md — high-confidence hypotheses inform RICE impact estimates../product-discovery/SKILL.md — routes to this skill when continuous discovery is the practice../post-launch-retrospective/SKILL.md — retrospective validates original hypothesis resultsHypothesis-driven development synthesizes two lineages. Eric Ries developed the Build-Measure-Learn loop at IMVU and published The Lean Startup in 2011, applying lean manufacturing principles (Toyota Production System) to the startup product process. The core insight — that startups are engaged in a search for a repeatable, scalable business model, not executing a known plan — reframed product development as an experimental discipline. Teresa Torres, a product discovery coach, extended this into continuous practice with her opportunity tree framework, published in Continuous Discovery Habits (2021). Torres's contribution is operationalizing weekly discovery as a team ritual rather than a project phase. Together, these frameworks form the dominant approach to product experimentation in modern tech organizations.