# Define Hypothesis

> Defines a testable hypothesis with clear success metrics and a validation approach. Use when forming assumptions to test or aligning a team on what success looks like, before any experiment is designed. To design the A/B test or experiment that will validate the hypothesis, use measure-experiment-design.

- Skill: `product-on-purpose/define-hypothesis` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds add product-on-purpose/define-hypothesis`
- Raw SKILL.md: https://api.skillmd.com/api/skills/product-on-purpose/define-hypothesis/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: Apache-2.0
- Author: product-on-purpose (https://skillmd.com/u/product-on-purpose)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/product-on-purpose/define-hypothesis

---

<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->
# Hypothesis

A hypothesis is a testable prediction about how a change will affect user behavior or business outcomes. It transforms assumptions into explicit statements that can be validated or invalidated through experimentation. Well-formed hypotheses prevent teams from building features based on untested beliefs and create shared understanding of what success looks like.

## When to Use

- After problem framing, before committing to a solution
- When designing experiments or A/B tests
- When team members have differing assumptions about user behavior
- Before investing significant engineering resources in a feature
- When pivoting direction and need to validate the new approach

## When NOT to Use

- You are ready to design the actual A/B test (variants, sample size, duration) -> use `measure-experiment-design`; this skill frames what to test, not how
- The problem itself is still unframed -> use `define-problem-statement` first
- You want to organize many assumptions and ideas into a discovery structure -> use `define-opportunity-tree`
- The team needs the full business-model picture, not one testable claim -> use `foundation-lean-canvas`

## Instructions

When asked to create a hypothesis, follow these steps:

1. **State the Belief**
   Articulate what you believe will happen. Use the structured format: "We believe that [action/change] for [target user] will [expected outcome]." Be specific about the intervention - vague hypotheses can't be tested.

2. **Identify the Target User**
   Define who this hypothesis applies to. A hypothesis about "users" is too broad. Specify the segment: new users in their first week, power users with 10+ sessions, churned users returning, etc.

3. **Define the Expected Outcome**
   What behavior change or result do you expect? Frame it in terms of user actions (complete onboarding, make a purchase, return within 7 days) rather than internal metrics when possible.

4. **Set Success Metrics**
   Choose a primary metric that directly measures the expected outcome. Include secondary metrics that provide context and guardrail metrics that ensure you're not causing harm elsewhere.

5. **Describe Validation Approach**
   How will you test this hypothesis? A/B test, user interviews, prototype testing, cohort analysis? Be specific about sample size, duration, and statistical requirements.

6. **Document Risks and Assumptions**
   What could invalidate this hypothesis beyond the test results? What are you assuming to be true that you haven't validated?

## Output Format

Use the template in `references/TEMPLATE.md` to structure the output. A complete hypothesis document fills every template section: Hypothesis Statement; Background & Rationale; Target User Segment; Success Metrics; Validation Approach; Risks & Assumptions; and Timeline.

## Quality Checklist

Before finalizing, verify:

- [ ] Hypothesis is falsifiable (possible to prove wrong)
- [ ] Success metric has a specific numeric target
- [ ] Target user segment is clearly defined
- [ ] Validation approach is practical and time-bound
- [ ] Pass/fail criteria are unambiguous
- [ ] Hypothesis doesn't assume the solution works

## Examples

See `references/EXAMPLE.md` for a completed example.

