Epic Hypothesis

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.

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