/epic-hypothesis

name: epic-hypothesis
argument-hint: "[initiative or epic idea]"
description: 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.
intent: >-
  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.
type: component
theme: pm-artifacts
best_for:
  - "Framing a major initiative as something that can be proven wrong"
  - "Forcing an outcome and a validation method before build starts"
  - "Giving a team a shared bet to test instead of a scope to deliver"
scenarios:
  - "Leadership approved a big initiative and nobody can say what would prove it wrong"
  - "I need to frame this epic as a bet with a real validation method, not a delivery plan"
estimated_time: "15-20 min"

Purpose

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.

Input

**Works best with:** The initiative or epic idea, in whatever form it currently exists — a sentence is enough. **Also useful:** The target user, the outcome you expect, and how you might measure it (the skill helps you sharpen all three).

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended `ARGUMENTS:` line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

**Arriving empty-handed? That works too.** The skill asks what the initiative is and who it's for, then builds the if/then hypothesis with you.

**Example invocation:** `Frame as an epic hypothesis: adding usage-based alerts so account admins catch overages before invoice shock.`

Key Concepts

The Epic Hypothesis Framework

Inspired by Tim Herbig's Lean UX hypothesis format, the structure is:

**If/Then Hypothesis:**

• **If we** [action or solution on behalf of target persona]
• **for** [target persona]
• **Then we will** [attain or achieve a desirable outcome or job-to-be-done]

**Tiny Acts of Discovery Experiments:**

• **We will test our assumption by:**
• [Experiment 1]
• [Experiment 2]
• [Add more as necessary]

**Validation Measures:**

• **We know our hypothesis is valid if within** [timeframe]
• **we observe:**
• [Quantitative measurable outcome]
• [Qualitative measurable outcome]
• [Add more as necessary]

Why This Structure Works

• **Hypothesis-driven:** Forces you to state what you believe (and could be wrong about)
• **Outcome-focused:** "Then we will" emphasizes user benefit, not feature output
• **Experiment-first:** Encourages lightweight validation before full build
• **Falsifiable:** Clear success criteria make it possible to kill bad ideas early
• **Risk management:** Treats epics as bets, not commitments

Anti-Patterns (What This Is NOT)

• **Not a feature spec:** "Build a dashboard with 5 charts" is a feature, not a hypothesis
• **Not a guaranteed commitment:** Hypotheses can (and should) be invalidated
• **Not output-focused:** "Ship feature X by Q2" misses the point—did it achieve the outcome?
• **Not experiment-free:** If you skip experiments and go straight to build, you're not testing a hypothesis

When to Use This

• Early-stage feature exploration (before committing to full roadmap)
• Validating product-market fit for new capabilities
• Prioritizing backlog (epics with validated hypotheses get higher priority)
• Managing stakeholder expectations (frame work as experiments, not promises)

When NOT to Use This

• For well-validated features (if you've already proven demand, skip straight to user stories)
• For trivial features (don't over-engineer small tweaks)
• When experiments aren't feasible (rare, but sometimes you must commit before testing)

---

Application

Use `template.md` for the full fill-in structure.

Step 1: Gather Context

Before drafting an epic hypothesis, ensure you have:

• **Problem understanding:** What user problem does this address? (reference `skills/problem-statement/SKILL.md`)
• **Target persona:** Who benefits? (reference `skills/proto-persona/SKILL.md`)
• **Jobs-to-be-Done:** What outcome are they trying to achieve? (reference `skills/jobs-to-be-done/SKILL.md`)
• **Current alternatives:** What do users do today? (competitors, workarounds, doing nothing)

**If missing context:** Run discovery interviews or problem validation work first.

---

Step 2: Draft the If/Then Hypothesis

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:**

• **"If we" is specific:** Not "improve the product" but "add one-click Slack notifications when tasks are assigned"
• **"For" is a clear persona:** Not "users" but "remote project managers juggling 3+ distributed teams" (reference `skills/proto-persona/SKILL.md`)
• **"Then we will" is an outcome:** Not "users will have notifications" but "users will respond to task assignments 50% faster"

**Examples:**

• ✅ "If we add one-click Google Calendar integration for trial users, then we will increase activation rates by 20% within 30 days"