Frame an epic as a testable hypothesis with target user, expected outcome, and validation method. Use when defining a major initiative before roadmap, discovery, or delivery planning.
How this skill is triggered — by the user, by Claude, or both
Slash command
/product-manager-skills:epic-hypothesisThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Frame epics as testable hypotheses using an if/then structure that articulates the action or solution, the target beneficiary, the expected outcome, and how you'll validate success. Use this to manage uncertainty in product development by making assumptions explicit, defining lightweight experiments ("tiny acts of discovery"), and establishing measurable success criteria before committing to fu...
Frame epics as testable hypotheses using an if/then structure that articulates the action or solution, the target beneficiary, the expected outcome, and how you'll validate success. Use this to manage uncertainty in product development by making assumptions explicit, defining lightweight experiments ("tiny acts of discovery"), and establishing measurable success criteria before committing to full build-out.
This is not a requirements spec—it's a hypothesis you're testing, not a feature you're committed to shipping.
Inspired by Tim Herbig's Lean UX hypothesis format, the structure is:
If/Then Hypothesis:
Tiny Acts of Discovery Experiments:
Validation Measures:
Use template.md for the full fill-in structure.
Before drafting an epic hypothesis, ensure you have:
skills/problem-statement/SKILL.md)skills/proto-persona/SKILL.md)skills/jobs-to-be-done/SKILL.md)If missing context: Run discovery interviews or problem validation work first.
Fill in the template:
### If/Then Hypothesis
**If we** [action or solution on behalf of the target persona]
**for** [target persona]
**Then we will** [attain or achieve a desirable outcome or job-to-be-done for the persona]
Quality checks:
skills/proto-persona/SKILL.md)Examples:
Before building the full epic, define lightweight experiments to test the hypothesis:
### Tiny Acts of Discovery Experiments
**We will test our assumption by:**
- [Experiment 1: low-cost, fast test]
- [Experiment 2: another low-cost, fast test]
- [Add more as necessary]
Experiment types:
Quality checks:
Examples:
Specify what success looks like and the timeframe for evaluation:
### Validation Measures
**We know our hypothesis is valid if within** [timeframe in days or weeks]
**we observe:**
- [Desirable quantitative, measurable outcome]
- [Desirable qualitative, measurable outcome]
- [Add more as necessary]
Quality checks:
Examples:
Once the hypothesis is validated, break the epic into user stories:
### Epic: [Epic Name]
**Stories:**
1. [User Story 1 - reference `skills/user-story/SKILL.md`]
2. [User Story 2]
3. [User Story 3]
See examples/sample.md for full epic hypothesis examples.
Mini example excerpt:
**If we** provide one-click Google Calendar integration
**for** trial users managing multiple meetings
**Then we will** increase activation rate from 40% to 50%
Symptom: "If we build a dashboard, then we will have a dashboard"
Consequence: You're describing output, not outcome. This doesn't test anything.
Fix: Focus on the user outcome: "If we build a dashboard showing real-time task status, then PMs will spend 50% less time asking for status updates."
Symptom: "We'll test our assumption by building the full feature"
Consequence: You've committed to building before validating. Not a hypothesis—it's a feature commitment.
Fix: Design lightweight experiments (prototypes, concierge tests, landing pages) that take days/weeks, not months.
Symptom: "We know it's valid if users are happy"
Consequence: Success criteria are subjective and unmeasurable.
Fix: Define specific, falsifiable metrics: "80% of surveyed users rate the feature 4+ out of 5" or "Response time drops by 50%."
Symptom: "We know it's valid if within 6 months revenue increases"
Consequence: Too slow to inform decisions. By then, you've already built it.
Fix: Aim for 2-4 week validation cycles. If you can't measure in that timeframe, choose a leading indicator (e.g., activation rate, not annual revenue).
Symptom: "We already told the CEO we're shipping this, so we have to validate it"
Consequence: Experiments are theater—you're going to build it regardless of results.
Fix: Frame epics as hypotheses before making commitments. If stakeholders need certainty, explain the risk of building unvalidated features.
skills/problem-statement/SKILL.md — Hypothesis should address a validated problemskills/proto-persona/SKILL.md — Defines the "for [persona]" sectionskills/jobs-to-be-done/SKILL.md — Informs the "then we will" outcomeskills/user-story/SKILL.md — Validated epics decompose into user storiesskills/user-story-splitting/SKILL.md — How to break validated epics into storiesprompts/backlog-epic-hypothesis.md in the https://github.com/deanpeters/product-manager-prompts repo.Skill type: Component
Suggested filename: epic-hypothesis.md
Suggested placement: /skills/components/
Dependencies: References skills/problem-statement/SKILL.md, skills/proto-persona/SKILL.md, skills/jobs-to-be-done/SKILL.md
Used by: skills/user-story/SKILL.md, skills/user-story-splitting/SKILL.md
npx claudepluginhub deanpeters/product-manager-skills --plugin workshop-facilitationCreates testable hypotheses with success metrics and validation approaches. For forming assumptions before experiments, use along with define-problem-statement or measure-experiment-design.
Guides teams through Jeff Gothelf's Lean UX Canvas v2 to frame business problems, surface assumptions, and define testable hypotheses before building.
Activate for: assumption, hypothesis, assumption map, MVP, minimum viable product, lean startup, what assumptions am I making, test my idea, what could go wrong, assumption risk, validate assumption, kill my idea, stress test, what should I test first, MVP design, MVP scoping, what to build, minimum feature set, success criteria, failure criteria, pivot criteria, build plan, riskiest assumption, leap of faith assumption, critical assumption. NOT for: idea generation (use idea), customer discovery (use discovery), pilot results analysis (use validate).