What makes a hypothesis strong?

It is falsifiable, specifies a clear target user, links to a concrete measurable outcome, and includes a practical validation plan with defined success criteria.

How should validation be documented?

Specify the validation method, sample size or duration, statistical requirements if testing, and clear pass/fail criteria before running the test.

Define Hypothesis

Scanned

npx machina-cli add skill product-on-purpose/pm-skills/define-hypothesis --openclaw

Files (1)

SKILL.md

3.0 KB

name: define-hypothesis description: Defines a testable hypothesis with clear success metrics and validation approach. Use when forming assumptions to test, designing experiments, or aligning team on what success looks like. phase: define version: "2.0.0" updated: 2026-01-26 license: Apache-2.0 metadata: category: ideation frameworks: [triple-diamond, lean-startup, design-thinking] author: product-on-purpose

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

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.

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.

Source

git clone https://github.com/product-on-purpose/pm-skills/blob/main/skills/define-hypothesis/SKILL.mdView on GitHub

Overview

A hypothesis is a testable prediction about how a change will affect user behavior or business outcomes. It turns assumptions into explicit statements that can be validated or invalidated through experimentation. Well-formed hypotheses create shared clarity on what success looks like.

How This Skill Works

Craft a belief in the form 'We believe that [action/change] for [target user] will [expected outcome]', identify a precise target user, define the expected outcome in user terms, and pair it with a concrete success metric and a concrete validation plan. This structure enables practical A/B tests, prototypes, or cohorts to validate or invalidate the hypothesis.

When to Use It

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

Quick Start

Step 1: State the Belief using the exact format: 'We believe that ...'
Step 2: Identify the Target User and define the Expected Outcome
Step 3: Set a primary success metric and plan the validation method (e.g., A/B test, interview)

Best Practices

Use the exact 'We believe that …' format to state the belief
Specify a clearly defined target user segment (not just 'users')
Define a measurable primary success metric with a numeric target
Choose a practical validation approach with scope, duration, and sample size
Document risks, assumptions, and criteria for fail/pass before testing

Example Use Cases

We believe that offering a 7-day onboarding tip will increase activation within the first week for new users
We believe that showing price comparisons will increase upgrade rate for trial users
We believe that simplifying checkout for returning users will raise completed purchases in a single session
We believe that nudging returning users with in-app reminders will boost daily active sessions by 12% over 14 days
We believe that testing a new search filter will improve average session duration for power users

Frequently Asked Questions

Add this skill to your agents