define-hypothesis

Name: define-hypothesis
Author: product-on-purpose

486stars64forks

How to install define-hypothesis?

product-on-purpose/pm-skills/define-hypothesis

$npx -y skills add product-on-purpose/pm-skills --skill define-hypothesis

Installs into the current project.

Summary

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 m

Files · 1

View on GitHub

SKILL.md

1	<!-- PM-Skills \| https://github.com/product-on-purpose/pm-skills \| Apache 2.0 -->
2	# Hypothesis
3
4	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.
5
6	## When to Use
7
8	- After problem framing, before committing to a solution
9	- When designing experiments or A/B tests
10	- When team members have differing assumptions about user behavior
11	- Before investing significant engineering resources in a feature
12	- When pivoting direction and need to validate the new approach
13
14	## When NOT to Use
15
16	- 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
17	- The problem itself is still unframed -> use `define-problem-statement` first
18	- You want to organize many assumptions and ideas into a discovery structure -> use `define-opportunity-tree`
19	- The team needs the full business-model picture, not one testable claim -> use `foundation-lean-canvas`
20
21	## Instructions
22
23	When asked to create a hypothesis, follow these steps:
24
25	1. State the Belief
26	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.
27
28	2. Identify the Target User
29	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.
30
31	3. Define the Expected Outcome
32	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.
33
34	4. Set Success Metrics
35	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.
36
37	5. Describe Validation Approach
38	How will you test this hypothesis? A/B test, user interviews, prototype testing, cohort analysis? Be specific about sample size, duration, and statistical requirements.
39
40	6. Document Risks and Assumptions
41	What could invalidate this hypothesis beyond the test results? What are you assuming to be true that you haven't validated?
42
43	## Output Format
44
45	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.
46
47	## Quality Checklist
48
49	Before finalizing, verify:
50
51	- [ ] Hypothesis is falsifiable (possible to prove wrong)
52	- [ ] Success metric has a specific numeric target
53	- [ ] Target user segment is clearly defined
54	- [ ] Validation approach is practical and time-bound
55	- [ ] Pass/fail criteria are unambiguous
56	- [ ] Hypothesis doesn't assume the solution works
57
58	## Examples
59
60	See `references/EXAMPLE.md` for a completed example.

People who liked this also viewed

6 picks

Type

define-hypothesis

486stars64forks

View on GitHub

How to install define-hypothesis?

product-on-purpose/pm-skills/define-hypothesis

$npx -y skills add product-on-purpose/pm-skills --skill define-hypothesis

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	<!-- PM-Skills \| https://github.com/product-on-purpose/pm-skills \| Apache 2.0 -->
2	# Hypothesis
3
4	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.
5
6	## When to Use
7
8	- After problem framing, before committing to a solution
9	- When designing experiments or A/B tests
10	- When team members have differing assumptions about user behavior
11	- Before investing significant engineering resources in a feature
12	- When pivoting direction and need to validate the new approach
13
14	## When NOT to Use
15
16	- 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
17	- The problem itself is still unframed -> use `define-problem-statement` first
18	- You want to organize many assumptions and ideas into a discovery structure -> use `define-opportunity-tree`
19	- The team needs the full business-model picture, not one testable claim -> use `foundation-lean-canvas`
20
21	## Instructions
22
23	When asked to create a hypothesis, follow these steps:
24
25	1. State the Belief
26	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.
27
28	2. Identify the Target User
29	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.
30
31	3. Define the Expected Outcome
32	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.
33
34	4. Set Success Metrics
35	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.
36
37	5. Describe Validation Approach
38	How will you test this hypothesis? A/B test, user interviews, prototype testing, cohort analysis? Be specific about sample size, duration, and statistical requirements.
39
40	6. Document Risks and Assumptions
41	What could invalidate this hypothesis beyond the test results? What are you assuming to be true that you haven't validated?
42
43	## Output Format
44
45	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.
46
47	## Quality Checklist
48
49	Before finalizing, verify:
50
51	- [ ] Hypothesis is falsifiable (possible to prove wrong)
52	- [ ] Success metric has a specific numeric target
53	- [ ] Target user segment is clearly defined
54	- [ ] Validation approach is practical and time-bound
55	- [ ] Pass/fail criteria are unambiguous
56	- [ ] Hypothesis doesn't assume the solution works
57
58	## Examples
59
60	See `references/EXAMPLE.md` for a completed example.

People who liked this also viewed

6 picks

Type