epic-hypothesis

intent

frame epics as testable hypotheses using an if/then structure that articulates the action, target beneficiary, expected outcome, and validation approach. this skill manages uncertainty in product development by making assumptions explicit, defining lightweight experiments to test those assumptions, and establishing measurable success criteria before committing to full build-out. use this when exploring new features early-stage, validating product-market fit, or prioritizing backlog. this is not a requirements spec or a feature you're committed to shipping. it's a bet you're placing and testing.

inputs

• problem statement: reference skills/problem-statement/SKILL.md. what user problem does this epic address. if you don't have this, run discovery interviews first.
• target persona: reference skills/proto-persona/SKILL.md. who benefits from solving this. be specific: not "users" but "remote project managers juggling 3+ distributed teams".
• jobs-to-be-done context: reference skills/jobs-to-be-done/SKILL.md. what outcome is the persona trying to achieve. informs the "then we will" section.
• current state map: what do users do today to solve this problem. document competitors, workarounds, or the "doing nothing" option.
• stakeholder constraints: any hard limits on timeframe, budget, or feasibility that affect experiment design.

procedure

step 1: gather context

inputs: problem statement, proto-persona, jobs-to-be-done research, competitive landscape notes

• review the problem statement you're addressing. if it's not documented, stop and run problem validation first.
• confirm your target persona is named and specific (reference proto-persona skill).
• list current alternatives: what do users do today instead. include "do nothing" as an option.
• document any known constraints (legal, technical, resource) that limit what you can test.

outputs: a 1-page context summary with problem, persona, alternatives, and constraints

step 2: draft the if/then hypothesis

inputs: context summary from step 1

• fill in the template structure: "if we [action], for [persona], then we will [outcome]".
• ensure "if we" describes a specific action or solution, not a vague improvement. bad: "improve the product". good: "add one-click Slack notifications when tasks are assigned".
• ensure "for" names a clear persona with context. reference proto-persona skill.
• ensure "then we will" names a measurable user outcome, not a feature output. bad: "users will have notifications". good: "users will respond to task assignments 50% faster".
• run three quality checks: is the action specific enough to build. is the persona clearly defined. is the outcome falsifiable.

outputs: one formatted if/then hypothesis statement. example: "if we provide bulk delete functionality for power users managing 1000+ items, for operations managers at mid-market SaaS companies, then we will reduce time spent on cleanup tasks by 70%".

step 3: design tiny acts of discovery experiments

inputs: validated if/then hypothesis from step 2

• list 2-4 lightweight experiments designed to test your hypothesis without full engineering build.
• choose experiment types based on speed and cost: prototype plus user testing (fake the feature with a clickable prototype, test with 5-10 users), concierge test (manually perform the feature for a few users), landing page test (describe the feature, measure sign-ups or interest), wizard of Oz test (present as automated but do manually behind scenes), A/B test if feasible (test lightweight version vs. control).
• for each experiment, specify: what you're testing, who you're testing with (sample size and sourcing method), how long it takes, what data you'll collect.
• quality check: each experiment should be completable in days or weeks, not months. avoid full engineering builds.

outputs: a "tiny acts of discovery" section with 2-4 experiments, each with methodology and expected data points. example: "create a Figma prototype of bulk delete flow and test with 5 power users over 1 week. measure: task completion time, confidence rating 1-5, open-ended feedback on friction points".

step 4: define validation measures

inputs: hypothesis from step 2, experiments from step 3

• set a realistic timeframe for validation (typically 2-4 weeks). timeframe should allow enough data to emerge but not so long that you've already committed to building.
• define at least one quantitative measure (specific, numeric outcome). bad: "more users". good: "activation rate increases from 40% to 50%".
• define at least one qualitative measure (observable behavioral or sentiment signal). bad: "users like it". good: "8 out of 10 users say they'd pay for this feature" or "75% of surveyed trial users report saving 30+ minutes per week".
• quality check: are measures falsifiable. could you observe the opposite result.

outputs: a "validation measures" section with timeframe and at least 2-3 specific success criteria. example: "within 4 weeks, we observe: (quantitative) activation rate increases from 40% to 50%. (qualitative) 75% of surveyed trial users say the integration saved them time. (observational) bulk delete is used in at least 30% of power user sessions".

step 5: run experiments and evaluate

inputs: experiment designs from step 3, validation measures from step 4

• execute all designed experiments in parallel if possible to minimize validation cycle time.
• collect and document all data (quantitative metrics, user feedback, behavioral signals).
• measure results against validation measures. determine outcome: hypothesis validated (proceed to step 6), hypothesis invalidated (kill or pivot), or inconclusive (run additional experiments or tighten measures).
• document decision rationale: why you're proceeding, killing, or pivoting based on evidence.

outputs: experiment results document with data, analysis, and go/kill/pivot decision. include raw feedback snippets and metrics.

step 6: convert validated hypotheses to user stories

inputs: validated hypothesis and experiment results from step 5

• if hypothesis is validated, break the epic into 3-5 user stories (reference skills/user-story/SKILL.md and skills/user-story-splitting/SKILL.md).
• if hypothesis is invalidated or inconclusive, document learning and archive the epic hypothesis for future reference.
• do not proceed to user stories unless validation measures are met.

outputs: set of user stories with acceptance criteria derived from the validated hypothesis. example: "as a power user managing 1000+ items, i want to select multiple items and delete them in one action, so i can reduce cleanup time from 2 hours to 36 minutes per week".

decision points

• if context is missing (problem, persona, alternatives not documented): stop. run problem-statement, proto-persona, and jobs-to-be-done skills first. do not draft a hypothesis on incomplete research.
• if hypothesis is vague or output-focused (describes a feature, not an outcome): reject and rewrite. a hypothesis must be falsifiable and outcome-centered, not feature-centered.
• if experiments are full builds (require 4+ weeks of engineering): redesign. swap for lighter tests: prototypes, manual concierge, landing pages. if lightweight experiments are impossible, this may not be a hypothesis-driven problem.
• if validation timeframe exceeds 4 weeks: tighten measures or choose leading indicators (e.g., prototype feedback instead of production metrics). long cycles delay decision-making.
• if validation measures are subjective ("users are happy"): reject. redefine with specific, falsifiable criteria (e.g., "7 out of 10 users rate 4+ out of 5").
• if experiments show inconclusive results: run 1-2 additional targeted experiments or tighten success thresholds. document why results were unclear.
• if validation measures are NOT met after experiments: kill the epic or pivot to a different hypothesis. do not build unvalidated features. this is the core discipline of hypothesis-driven development.
• if stakeholders expect certainty: reframe the work as managed risk. explain that experiments reduce but don't eliminate failure risk. hypothesis-driven development is risk reduction, not risk elimination.

output contract

format: markdown file (suggested filename: epic-hypothesis.md or [epic-name]-hypothesis.md)

location: /skills/components/ or project-specific backlog folder

sections required:

1. if/then hypothesis statement (one clear sentence)
2. tiny acts of discovery experiments (bulleted list with methodology)
3. validation measures (timeframe plus 2-3 specific criteria)
4. experiment results (if executed, with data and decision rationale)
5. derived user stories (if validated, with acceptance criteria)

data format for metrics:

• quantitative: "activation rate increases from 40% to 50%" (baseline, target, unit)
• qualitative: "8 out of 10 users report [specific outcome]" (sample size, finding, specificity)
• observational: "feature used in 30% of target user sessions" (measurable behavior)

decision artifact: a one-line go/kill/pivot decision with supporting evidence. example: "kill. hypothesis invalidated. 0 of 5 users would pay for feature. manual process takes 8 minutes, feature would save 3. roi negative."

outcome signal

you know this skill worked when:

1. hypothesis is written and falsifiable: someone else can read your if/then statement and clearly understand what would prove it right or wrong. no ambiguity.
2. experiments are running: teams are executing lightweight tests (prototypes, concierge, landing pages) in parallel. no full builds without validation first.
3. validation cycle is 2-4 weeks: you have data on your hypothesis within a sprint or two, not months.
4. decision is clear and evidence-based: go/kill/pivot decision is documented with specific metrics and feedback. no guessing.
5. unvalidated epics are not shipped: the team stops committing to features without hypothesis validation. this is the hardest and most important signal.
6. stakeholders frame work as bets, not promises: language shifts from "we're building X" to "we're testing the hypothesis that X will improve [outcome]".

early signals:

• context documents are complete before hypothesis is drafted (problem, persona, alternatives all documented).
• hypothesis rewrites happen (first draft is rejected as vague or output-focused).
• experiments are discussed in terms of speed and cost ("can we fake this in Figma in 3 days").
• qualitative feedback is captured verbatim, not summarized as "positive" or "negative".

lagging signals:

• validated hypotheses convert to user stories without rework.
• kill decisions are made with confidence (team understands why the hypothesis failed).
• backlog prioritizes validated hypotheses higher than unvalidated epics.

credits: original framework by dean peters, adapted from tim herbig's lean ux hypothesis format, inspired by jeff gothelf and josh seiden's lean ux, alberto savoia's pretotype it, and eric ries's the lean startup.