Foundation Sprint Founding Hypothesis

Try it: /pm-skills:tool-foundation-sprint-founding-hypothesis "Your context here"

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.

How to Use

Invoke the skill by name (/pm-skills:tool-foundation-sprint-founding-hypothesis on Claude Code, $tool-foundation-sprint-founding-hypothesis on Codex):

/pm-skills:tool-foundation-sprint-founding-hypothesis "Your context here"

Or reference the skill file directly: skills/tool-foundation-sprint-founding-hypothesis/SKILL.md

What This Skill Produces

A single bundled artifact with five sections:

Founding Hypothesis statement: the single canonical sentence (strict template, no paraphrase).
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).
Why we believe this: 3-5 bulleted points naming the evidence base.
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.
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:

Slot	Source	Discipline check
target customer	Basics target customer statement	Must be specific (markers, not segments)
important problem	Basics important problem statement	Must be painful enough to drive switching
approach	Magic Lenses top bet	Must be the top bet, not a softened version
competitors or alternatives	Basics competitor map	Must include “do nothing” if it was named there
differentiators	Differentiation chosen two	Must be both differentiators, not just one

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

What Makes a Good Founding Hypothesis

Quality	What it means
Specific	Names a real customer and a real problem; not “users” and “frustrations”
Comparative	Explains what customers choose today, including doing nothing
Differentiated	States why this solution should win, not just that it should
Testable	Translates into scorecard questions and experiments
Simple	A customer can understand the promise quickly
Uncomfortable enough to be useful	If nobody disagrees or feels exposed, the hypothesis may be too vague

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:

Field	What goes here
Assumption	One sentence, derived from a specific slot of the hypothesis
Why it matters	What would be invalidated if this assumption is wrong
Current confidence	High / Medium-high / Medium / Medium-low / Low
Best next test	Specific test that would change the confidence level

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.

Step 3: Why we believe / what could prove us wrong (5-10 min)

Bulleted lists, 3-5 each. The team writes both in parallel; the second list (proof-of-wrong) is the test of whether the team is holding the hypothesis with calibration.

Step 4: Recommended next test (5 min)

The Decider names the next validation step: Design Sprint, customer research, experiment, etc. The recommended test should attack the highest-risk assumption from the scorecard.

Step 5: Ratification (1 min)

The Decider signs. The sprint ends.

Common Pitfalls

Vague customer or problem. “Readers” or “frustrations” are not slots. The skill rejects them.
Non-falsifiable hypothesis. “We will succeed” is not a hypothesis. “If we help X with Y they will choose us” is. The skill enforces the structure.
Treating hypothesis as strategy doc. The hypothesis is a test target, not a strategic plan. The team’s strategy decisions live in the Mini Manifesto and decision principles; the hypothesis is what you go test.
Skipping the scorecard. The hypothesis is half the value; the test plan (scorecard + recommended next test) is the other half. Without the scorecard, the hypothesis is wall art.
Softening to ratify. Teams will instinctively soften the hypothesis to make it less controversial. The skill counter-acts with the “would anyone push back” check.
Polishing later. The hypothesis must be ratified by end of Day 2. Polishing later means re-litigating; the sprint discipline collapses.

Decider Role

The Decider’s job during Founding Hypothesis:

Draft the canonical sentence (or co-draft with the PM).
Lead the revision pass; push back on vague slots.
Score scorecard assumptions with the team; supervote when confidence ratings are contested.
Name the recommended next validation step explicitly.
Ratify the hypothesis by end of Day 2 even if some slot wording is imperfect; further polishing happens by editing the scorecard, not the hypothesis.

Canonical Sources

Knapp, J., and Zeratsky, J. Click. Founding Hypothesis template and rationale.
Character Capital. “Foundation Sprint guide.” Founding Hypothesis section.
Knapp, J., and Zeratsky, J. “Introducing the Foundation Sprint.” Lenny’s Newsletter. Founding Hypothesis structure with worked examples.

Cross-Skill Usage

Prerequisites: tool-foundation-sprint-magic-lenses. The top bet, backup, and decision rationale are the load-bearing inputs.

The skill inherits the Basics bundled artifact (target customer, important problem, competitors) and the Differentiation bundled artifact (chosen differentiators). All five hypothesis slots are derived from prior sprint outputs.

Next invocation outside the sprint: the recommended next validation step. Most commonly tool-design-sprint-readiness if a Design Sprint is the next test. Sometimes pm-skills:measure-experiment-design or pm-skills:discover-interview-synthesis if a non-sprint test is the right next move.

There is no formal bridge skill between Foundation Sprint and Design Sprint; the transition is narrative content in _workflows/foundation-to-design.md and in both user guides.

Decider Checkpoint

This skill ends with a Decider Checkpoint in references/TEMPLATE.md. The Decider ratifies the hypothesis sentence, the scorecard, and the recommended next test. Ratification closes the Foundation Sprint. Without ratification, the sprint output is incomplete and the team did not produce what it set out to produce.

Output Template

Foundation Sprint Founding Hypothesis: [Initiative name] (Day 2 End)

Founding Hypothesis

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

Slot derivation:

Target customer: [from Basics target customer statement]
Important problem: [from Basics important problem statement]
Approach: [from Magic Lenses top bet]
Alternatives: [from Basics competitor map; must include “do nothing” if named there]
Differentiators: [from Differentiation chosen two]

Assumption Scorecard

[5-7 assumptions recommended; 3-10 accepted. Highest-risk assumption identified at bottom.]

#	Assumption	Why it matters	Current confidence	Best next test
A1	[Assumption text]	[What breaks if wrong]	[High / Med-high / Med / Med-low / Low]	[Specific test that changes confidence]
A2	[Assumption]	[Why matters]	[Confidence]	[Test]
A3	[Assumption]	[Why matters]	[Confidence]	[Test]
A4	[Assumption]	[Why matters]	[Confidence]	[Test]
A5	[Assumption]	[Why matters]	[Confidence]	[Test]
A6	(Optional)
A7	(Optional)

Highest-risk assumption: [Assumption number]. [One sentence naming why this is the riskiest.]

Why We Believe This

[3-5 bulleted points naming the evidence base for the hypothesis.]

[Evidence point]. [Brief expansion citing the prior research, interviews, or domain knowledge that supports the hypothesis.]
[Evidence point].
[Evidence point].

What Could Prove Us Wrong

[3-5 bulleted points naming risks. This section is the team’s calibration check. If the team cannot name what would invalidate the hypothesis, the hypothesis is being held with overconfidence.]

[Risk]. [What invalidation looks like; what behavior or evidence would change the team’s belief.]
[Risk].
[Risk].

Recommended Next Validation Step

Next step: [Design Sprint / customer research / landing page experiment / concierge MVP / etc.]

What it tests: [Which assumption(s) from the scorecard does this attack first?]

Owner: [Name]

Timeline: [When does this start; when does it produce signal]

Decision the next step unlocks: [Build, refine, pivot, stop. What decision is the team making based on the next step’s output?]

Decider Checkpoint

Decider sign-off required to close the Foundation Sprint.

Decider ratifies the Founding Hypothesis sentence verbatim.
Decider confirms the assumption scorecard and the highest-risk assumption identification.
Decider commits to the recommended next validation step with named owner and timeline.
Decider acknowledges the backup plan (from Magic Lenses) is real, not theoretical.
Decider acknowledges the team will not re-litigate the strategic direction without explicit invalidation evidence from the next test.

Signed: [Decider name, role], [ISO date and local time].

Foundation Sprint closed.

Example Output

Foundation Sprint Founding Hypothesis: Brainshelf (Day 2 End)

The Brainshelf team’s Day 2 end output. The Foundation Sprint closes here.

Founding Hypothesis

If we help people who read 25 or more books a year and treat their personal library as memory rather than identity solve “I can’t remember what I’ve read or what I want to read next” with sub-3-second camera-first capture into a private library, they will choose it over Goodreads, StoryGraph, paper journals, and doing nothing because our solution is the fastest way to capture a book and the most useful way to recall what they have read.

Slot derivation:

Target customer: 25+/year readers, books-as-memory framing (from Basics)
Important problem: forgetting what they have read / want to read (from Basics)
Approach: sub-3-second camera-first capture into a private library (Yellow / Approach A from Magic Lenses)
Alternatives: Goodreads, StoryGraph, paper journals, doing nothing (from Basics competitor map)
Differentiators: fastest capture + most useful recall (from Differentiation)

Assumption Scorecard

#	Assumption	Why it matters	Current confidence	Best next test
A1	25+/year readers are switchable from “do nothing” with sub-3-second capture	If false, no capture-speed product can win this segment	Medium	Design Sprint Friday testing (5 customers)
A2	Camera-OCR + cover-recognition can achieve sub-3-second resolution at acceptable accuracy	If false, the differentiation collapses	Medium-high	Thursday prototype build with real OCR API
A3	”Personal recall” is a strong-enough draw without social features	If false, customers churn after initial novelty	Medium	Test recall flow with prototype; post-test interview
A4	Target customer can be reached through organic channels (Riley’s network, content)	If false, CAC pressure forces premature monetization	High	Founder-led growth test post-DS
A5	Paid sync + cross-device monetization model resonates	If false, business model unclear	Medium	Concept-pricing question in Friday script
A6	”Did I already read this?” is felt strongly enough to drive recall use cases	If false, the personal recall pillar is weaker than thought	High	Friday context-question on recall scenarios

Highest-risk assumption: A1. The product depends on it more than any other; the Design Sprint exists to test it.

Why We Believe This

22 customer interviews surfaced the same two pains repeatedly: forgetting books and friction with current tools. The Founding Hypothesis directly addresses both.
Riley’s network is a credible distribution channel for the target segment; warm intros tested in the readiness assessment.
The team’s existing capabilities (Alex on fast-capture UX, Sam on mobile and offline) match the chosen differentiators with evidence.
The “do nothing” baseline is high for this segment, meaning a 10x-better tool can win without displacing an entrenched competitor.
The differentiation is observable to customers (speed, recall) rather than internal-team metrics (architectural elegance).

What Could Prove Us Wrong

Customers nod but don’t capture. “Yes, this looks fast” in interviews but no usage in real life within 7-day follow-up.
OCR accuracy is below acceptable. Customers see 1-in-5 mis-resolutions and lose trust.
Personal recall is a feature, not a habit. Customers capture once and never come back to recall.
Camera-first is awkward in real contexts. People feel weird scanning books at home or in public.
Reading 25+/year segment is too small. TAM-too-narrow for a venture-scale company; the early signal might be strong but the segment cannot grow into a business.

Recommended Next Validation Step

Next step: Design Sprint week of 2026-05-26.

What it tests: A1 (switchable from “do nothing”) first; A2 (OCR accuracy) via the Thursday prototype build; A3 (personal recall draw) via the Friday recall flow test; A5 (pricing) via the Friday Five-Act Interview Act 5 debrief.

Owner: Jamie (founder, PM); Riley owns customer recruiting.

Timeline: Sprint begins Monday 2026-05-26; Friday testing 2026-05-30; Decider call by 16:30 Friday; 7-day instrumented follow-up through 2026-06-06.

Decision the next step unlocks: Build (6-week MVP cycle starting June 2), iterate (refine prototype + re-sprint), pivot to backup (Red Bookstore Mode), or stop.

Decider Checkpoint

Decider sign-off required to close the Foundation Sprint.

Jamie ratifies the Founding Hypothesis sentence verbatim.
Jamie confirms the 6-row assumption scorecard.
Jamie commits to running a Design Sprint week of 2026-05-26 as the next test.
Jamie acknowledges the backup plan (Red Bookstore Mode) is real, not theoretical.
Jamie acknowledges the team will not re-litigate the social-reader direction without explicit invalidation evidence from the Design Sprint.

Signed: Jamie (founder, PM), 2026-05-14 16:55 PT.

Foundation Sprint closed.