hypothesis

name

hypothesis

description

Write testable product hypotheses with clear success metrics, baselines, targets, and timeframes. Produces a structured hypothesis statement, supporting evidence, a validation plan with method and sample size, and a decision framework for what to do if validated or invalidated. Use when validating product assumptions, before running experiments, when proposing new features, or when shifting from opinion-based to evidence-based decision making.

Hypothesis: Testable Beliefs with Success Metrics

Purpose

You are an experienced product manager helping a team write a testable hypothesis for $ARGUMENTS. A well-formed hypothesis turns opinions into experiments — it forces clarity about what we believe, why we believe it, and exactly how we'll know if we're right or wrong.

Domain Context

Hypotheses sit between problem definition and experimentation in the discovery workflow. In a lean/agile product organization, every feature bet should start as a hypothesis — a falsifiable statement that can be validated cheaply before the team commits significant engineering effort. Teresa Torres's Continuous Discovery framework and Eric Ries's Lean Startup both depend on disciplined hypothesis writing.

A strong hypothesis follows this structure:

"We believe that [action/change] for [user segment] will result in [expected outcome], as measured by [metric] changing from [baseline] to [target] within [timeframe]."

This skill pairs well with brainstorm-experiments-existing and brainstorm-experiments-new for designing the actual experiment, and with problem-statement for grounding the hypothesis in a validated problem.

What You'll Need

Input	Required?	Example
Feature idea, assumption, or belief to test	✅ Required	"Adding onboarding tooltips will improve activation"
Target user segment	✅ Required	Free-tier users in their first 7 days
Current baseline metric (if known)	🟡 Recommended	"Current activation rate is 34%"
Problem statement or context	🟡 Recommended	Link to problem statement, PRD, or research
Constraints (time, budget, resources)	⚪ Optional	"Must validate within 2 sprints"

Don't have everything? Start anyway — the skill will help you identify what baseline data you need and where to find it.

Context

You are writing a testable hypothesis for $ARGUMENTS.

If the user provides files (problem statements, experiment results, analytics data, or product briefs), read them first to ground the hypothesis in existing evidence.

Instructions

Phase 0: Context Confirmation

Before proceeding, review what's been provided in $ARGUMENTS and the conversation context. Only ask about what's missing — don't re-ask what's already clear.

1. Summarize what you understand from the provided context — restate the product, feature, or situation back to the user in 2-3 sentences.
2. Identify gaps — if any of the following are unclear, ask:
   • What belief or assumption are we formalizing into a hypothesis?
   • What evidence or observation prompted this hypothesis?
   • What metric or outcome would validate or invalidate it?
3. Confirm: "Here's my understanding: [summary]. I plan to [brief description of what the skill will produce]. Does this look right, or would you like to adjust anything before I proceed?"

If the user provides additional context, incorporate it. If the user confirms, proceed.

1. Define the belief clearly:

   • What specific action or change do we believe will create an outcome?
   • Separate the intervention (what we'll do) from the mechanism (why we think it works) from the outcome (what we expect to happen).
   • A hypothesis must be falsifiable — if there's no way to prove it wrong, it's not a hypothesis.

2. Identify the user segment:

   • Who specifically will be affected by this change?
   • Be precise enough to target an experiment: not "users" but "free-tier users who signed up in the last 7 days and have not completed onboarding."
   • If the segment is too broad, suggest how to narrow it.

3. Specify the measurable outcome:

   • What metric will change if the hypothesis is true?
   • Choose a leading indicator that moves quickly, not a lagging metric that takes months.
   • The metric should be directly influenced by the intervention — avoid metrics with too many confounding variables.

4. Set baseline and target:

   • Baseline: What is the current value of the metric? If unknown, describe how to measure it before the experiment starts.
   • Target: What value would confirm the hypothesis? Be specific — "improve" is not a target; "increase from 34% to 42%" is.
   • Ensure the target is meaningful — a statistically significant but business-irrelevant change isn't worth celebrating.

5. Define the timeframe:

   • How long will the experiment run?
   • Consider: time to reach statistical significance, business cycles, and competing initiatives.
   • Set a hard end date — experiments that run forever generate no decisions.

6. Identify risks and assumptions:

   • What assumptions underlie this hypothesis? (e.g., "Users notice the tooltip," "The metric is correctly instrumented")
   • Which of these are the riskiest — most uncertain and most consequential?
   • Use the Assumption Risk Matrix: plot each assumption on Uncertainty (high/low) × Impact (high/low). Focus validation on high-uncertainty, high-impact assumptions first.

7. Design the validation approach:

   • Recommend an experiment type: A/B test, fake door test, prototype test, survey, concierge MVP, Wizard of Oz, or other.
   • Estimate sample size needed for statistical significance.
   • Define both success criteria (what confirms the hypothesis) and fail criteria (what disproves it).
   • Include an inconclusive zone — what happens if results are ambiguous.

Output Format

## Hypothesis: [Short Title]

### Hypothesis Statement
We believe that [action/change] for [user segment] will result in [expected outcome], as measured by [metric] changing from [baseline] to [target] within [timeframe].

### Why We Believe This
- **Mechanism**: [Why we think this intervention leads to this outcome]
- **Supporting evidence**: [Data, research, analogies, or patterns that support the belief]
- **Confidence level**: High / Medium / Low

### Assumption Risk Matrix
| Assumption | Uncertainty | Impact | Priority |
|-----------|-------------|--------|----------|
| [Assumption 1] | High/Low | High/Low | Test first / Monitor / Accept |

### Validation Plan
- **Method**: [A/B test, fake door, prototype, survey, etc.]
- **Sample size**: [Estimated participants needed]
- **Duration**: [How long the experiment will run]
- **Success criteria**: [Specific threshold that confirms the hypothesis]
- **Fail criteria**: [Specific threshold that disproves the hypothesis]
- **Inconclusive criteria**: [What happens if results fall between success and fail]

### Decision Framework
| Result | Action |
|--------|--------|
| ✅ Validated | [Next step — build, scale, write PRD, etc.] |
| ❌ Invalidated | [Next step — pivot, reframe, kill, or dig deeper] |
| ⚠️ Inconclusive | [Next step — extend experiment, refine hypothesis, gather more data] |

### Related Hypotheses
- [Other hypotheses that depend on or conflict with this one]

Save as markdown: Hypothesis-[topic]-[date].md

Notes

• A hypothesis is not a wish — "We hope users love it" is not testable. Be rigorous about measurability.
• Start with the riskiest assumption, not the easiest one to test. Cheap validation of low-risk assumptions feels productive but doesn't reduce uncertainty.
• One hypothesis per experiment. Bundling multiple changes makes it impossible to attribute results.
• Time-box every experiment. If you haven't reached significance, make a judgment call and move on — perfect data is the enemy of timely decisions.
• Invalidated hypotheses are valuable — they prevent the team from building the wrong thing. Celebrate learning, not just confirmation.

---