Help us improve
Share bugs, ideas, or general feedback.
How this skill is triggered — by the user, by Claude, or both
Slash command
/pm-skills:define-hypothesisThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->
Designs low-effort experiments like prototypes, A/B tests, spikes, and Wizard of Oz to validate assumptions and test feature ideas for existing products.
Designs A/B experiment plans with hypothesis, primary/secondary/guardrail metrics, audience allocation, holdout strategy, duration estimates, and risks. Use for feature test planning.
Designs A/B experiments specifying hypothesis, variants, metrics, sample size, duration, targeting, and success criteria. Use for validating product changes quantitatively.
Share bugs, ideas, or general feedback.
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 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?
Use the template in references/TEMPLATE.md to structure the output.
Before finalizing, verify:
See references/EXAMPLE.md for a completed example.