Tool Foundation Sprint Founding Hypothesis

<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->

Foundation Sprint Founding Hypothesis

Day 2 end of a Foundation Sprint. The team compresses the full sprint output into a single canonical sentence plus a testable scorecard. This is the artifact the sprint exists to produce; everything before this skill was preparation. Without a ratifiable Founding Hypothesis, the sprint failed.

Family contract: docs/reference/skill-families/foundation-sprint-skills-contract.md. This skill is a member of foundation-sprint-skills.

When to Use

• Day 2 end of a Foundation Sprint.
• Magic Lenses is signed; top bet and backup are named.
• The team has 30-45 minutes left in Day 2 and the energy to write the sentence carefully.

When NOT to Use

• Magic Lenses did not produce a clear top bet. Return to Magic Lenses; the Founding Hypothesis cannot stabilize on an unstable top bet.
• The team wants to "polish the hypothesis later." The hypothesis must be ratified by end of Day 2 or the sprint output is incomplete. Polishing later means re-litigating; that defeats the sprint's purpose.
• The team wants to ratify a vague hypothesis to "ship the sprint." A vague hypothesis is worse than no hypothesis; it gives false confidence and burns trust when validation fails.

What This Skill Produces

A single bundled artifact with five sections:

1. Founding Hypothesis statement: the single canonical sentence (strict template, no paraphrase).
2. Assumption scorecard: 5-7 assumptions extracted from the hypothesis, each scored on current confidence and tagged with a best next test (3-10 accepted; recommended range is 5-7).
3. Why we believe this: 3-5 bulleted points naming the evidence base.
4. What could prove us wrong: 3-5 bulleted points naming the risks. This section is the test of whether the team is in love with the hypothesis or holding it with calibrated confidence.
5. Recommended next validation step: Design Sprint, customer research, experiment, landing page test, or other. Names the specific test, owner, and timeline.

See references/TEMPLATE.md for the canonical template and references/EXAMPLE.md for the Brainshelf example.

The Canonical Template (Strict)

If we help [target customer] solve [important problem]
with [approach], they will choose it over [competitors or alternatives]
because our solution is [differentiators].

This template is strict for v0.1.0 (per ratified spec decision). Paraphrase is not accepted. Variations like "Because we help X with Y..." or compressing two slots into one ("solve [problem] with [approach]") are rejected by the skill. The strictness is intentional: forcing the template forces the team to fill every slot specifically.

The five slots are:

If any slot is vague, the skill rejects the hypothesis and prompts for revision.

What Makes a Good Founding Hypothesis

The "uncomfortable" quality is the hardest to enforce: teams unconsciously soften the hypothesis to make it ratifiable. The skill counter-acts by asking, in the discussion phase, "Who in this room would push back on this if they weren't on this team?" Silence is a signal that the hypothesis is too safe.

Assumption Scorecard

Decompose the hypothesis into 5-7 assumptions (recommended; 3-10 accepted per ratified spec decision). For each:

The highest-risk assumption (lowest current confidence, highest blast-radius-if-wrong) is the assumption the next validation step (often a Design Sprint) should test first.

Sequence (45 minutes)

Step 1: Draft the hypothesis (10-15 min)

The Decider drafts the canonical sentence by filling the 5 slots from prior sprint outputs. The team reviews, identifies vagueness, and revises until each slot is specific. This is the most important 15 minutes of the sprint.

Step 2: Build the scorecard (15-20 min)

Decompose the hypothesis into 5-7 assumptions. Score each. Identify the highest-risk one.