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:

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.