Epic Hypothesis
Frame a large product bet as a testable if/then epic with tiny discovery experiments and measurable validation before committing engineering time.
Overview
Epic Hypothesis is an agent skill most often used in Validate (also Idea research, Build PM) that turns fuzzy roadmap items into testable if/then epics with discovery experiments and validation measures.
Install
npx skills add https://github.com/deanpeters/product-manager-skills --skill epic-hypothesisWhat is this skill?
- Structured If/Then hypothesis with actor, behavior change, and quantified outcome
- Tiny Acts of Discovery: low-cost prototypes, fake-door CTAs, and concierge tests
- Validation Measures pairing quantitative thresholds with qualitative signals
- Contrasts strong vs vague hypotheses (actionable vs "improve dashboard")
- 4-week validation window pattern for time-boxed learning
- 3-part Tiny Acts of Discovery ladder in the good example
- activation target example 40% to 50%
Adoption & trust: 1.2k installs on skills.sh; 5k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have a big feature instinct but no crisp bet, segment, metric, or cheap experiments to prove it before you build.
Who is it for?
Solo SaaS founders validating onboarding integrations, workflow features, or activation levers before multi-week builds.
Skip if: Teams that already have signed PRDs with locked scope, or single-line bug fixes with no strategic uncertainty.
When should I use this skill?
When framing a strategic feature or epic as a testable hypothesis with discovery experiments and measurable validation.
What do I get? / Deliverables
You get a markdown epic hypothesis with if/then framing, tiny discovery steps, and pass/fail measures ready to feed scope docs, landing tests, or writing-plans.
- Markdown epic hypothesis with If/Then block
- Tiny Acts of Discovery experiment list
- Validation Measures with quant and qual gates
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Epic hypotheses sit where solo builders decide what to build next—after an idea exists but before a full implementation plan—so Validate → scope is the canonical shelf. Scope is where you define bounded bets, success metrics, and experiment ladders instead of vague feature wishlists.
Where it fits
Compare two integration ideas by drafting competing epic hypotheses with different activation targets before picking one.
Replace a vague dashboard epic with if/then language, prototype tests, and a 4-week validation checklist.
Pair a Figma flow with explicit CTR and interview gates from the Tiny Acts section before writing tickets.
Attach validation measures to an epic so engineering knows what instrumentation must ship on day one.
How it compares
Use instead of unstructured "we should improve X" roadmap bullets when you need hypothesis-driven discovery before implementation planning.
Common Questions / FAQ
Who is epic-hypothesis for?
Indie builders and small teams who own product scope and want agent help drafting rigorous epic bets without hiring a PM.
When should I use epic-hypothesis?
During Validate scope when prioritizing epics, during Idea research when comparing strategic options, and during Build PM when reframing a feature as a measurable bet before coding.
Is epic-hypothesis safe to install?
It is documentation and template guidance only; review the Security Audits panel on this Prism page before installing any skill from the repo.
SKILL.md
READMESKILL.md - Epic Hypothesis
# Epic Hypothesis Examples ## Example 1: Good Epic Hypothesis ```markdown ### Epic Hypothesis: Google Calendar Integration for Trial Users #### If/Then Hypothesis **If we** provide one-click Google Calendar integration during onboarding **for** trial users who manage multiple meetings and tasks daily **Then we will** increase activation rate (defined as completing setup + creating first task) from 40% to 50% #### Tiny Acts of Discovery Experiments **We will test our assumption by:** 1. Creating a clickable Figma prototype of the integration flow and testing with 10 trial users 2. Adding a "Connect Google Calendar" CTA to the onboarding flow (but it's non-functional) and measuring click-through rate 3. Manually syncing Google Calendar for 5 trial users and surveying them after 1 week on perceived value #### Validation Measures **We know our hypothesis is valid if within 4 weeks we observe:** - Click-through rate on the CTA is > 60% (quantitative) - 8 out of 10 prototype testers say they'd use this feature regularly (qualitative) - Manually synced users report saving 10+ minutes per day on task entry (qualitative) ``` --- ## Example 2: Bad Epic Hypothesis (Vague) ```markdown ### Epic Hypothesis: Improve Dashboard #### If/Then Hypothesis **If we** improve the dashboard **for** users **Then we will** make the product better #### Tiny Acts of Discovery Experiments **We will test our assumption by:** 1. Building the dashboard #### Validation Measures **We know our hypothesis is valid if we observe:** - Users like it ``` **Why this fails:** - "Improve the dashboard" is not specific (improve how?) - "Users" is not a persona (which users? all users?) - "Make the product better" is not measurable - Experiment is "build it" (not a lightweight test) - Validation is subjective ("users like it" = not falsifiable) **How to fix it:** - Specify the hypothesis: "If we add real-time task status updates to the dashboard for project managers, then we will reduce time spent checking task progress from 20 min/day to 5 min/day" - Define persona: "for project managers managing 10+ team members" - Design experiments: "Prototype the dashboard, test with 5 PMs, measure time savings" - Specify validation: "8 out of 10 PMs report saving 10+ min/day" --- ## Example 3: Invalidated Hypothesis (Good Process) ```markdown ### Epic Hypothesis: Slack Integration for Notifications #### If/Then Hypothesis **If we** send Slack notifications when tasks are assigned **for** remote project managers **Then we will** reduce task response time from 4 hours to 1 hour #### Tiny Acts of Discovery Experiments **We will test our assumption by:** 1. Manually send Slack notifications to 10 project managers for 2 weeks 2. Measure response time before/after 3. Survey users on perceived value #### Validation Measures **We know our hypothesis is valid if within 2 weeks we observe:** - Average response time drops from 4 hours to 1 hour (quantitative) - 8 out of 10 users say Slack notifications helped them respond faster (qualitative) --- **Results after 2 weeks:** - Average response time: 3.5 hours (minimal improvement) - User feedback: "I already get too many Slack notifications. I ignore most of them." - **Decision: Hypothesis INVALIDATED. Users don't want more Slack noise. Pivot to in-app notifications or email digests.** ``` **Why this is good:** - Hypothesis was tested (not just built) - Experiments were lightweight (manual Slack messages, not full integration) - Results showed the hypothesis was wrong - Team killed the epic before wasting engineering time --- name: epic-hypothesis 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'l