Skip to main content
skill CX Codex

tool-foundation-sprint-founding-hypothesis — Claude Code skill

Turns the end of a Foundation Sprint into one canonical sentence plus an assumption scorecard. Use it on Day 2 once Magic Lenses is signed.

Install into Claude Code · Skills CLI (Vercel) All methods and platforms ↓
npx skills add product-on-purpose/pm-skills --skill tool-foundation-sprint-founding-hypothesis -a claude-code
Open on GitHub

What tool-foundation-sprint-founding-hypothesis does

The skill bundles five sections: the Founding Hypothesis statement, an assumption scorecard of 5–7 assumptions scored by confidence and tagged with a next test, a why-we-believe list, a what-could-prove-us-wrong list, and a recommended next validation step with owner and timeline. The sentence template is strict — paraphrase is rejected. Five slots get filled from earlier artifacts: target customer, important problem, approach, competitors or alternatives, and differentiators. A vague slot sends the hypothesis back for revision.

The move runs in 45 minutes across four steps: draft the sentence, build the scorecard, write both bullet lists, pick the next test. Roles are facilitator, decider and PM. You need three inputs ready: the basics artifact, the differentiation artifact, and the top bet with its backup.

Only run it after Magic Lenses. With no clear top bet the hypothesis cannot stabilize, and the skill tells you to go back. Deferring the wording to later fails too: without a ratified hypothesis the sprint output is incomplete, and a vague one is worse than none — it gives false confidence and burns trust when validation fails.

What it helps with

  • compress sprint output into one canonical sentence
  • break the hypothesis into assumptions and score confidence
  • find the highest-risk assumption for the next test
  • write down what could prove the hypothesis wrong
  • name the next validation step with owner and timeline

Example prompts for the agent

  • Build the Founding Hypothesis from the sprint artifacts
  • Break the hypothesis into an assumption scorecard and flag the riskiest one
  • Write what could prove us wrong and suggest the next test

How to install tool-foundation-sprint-founding-hypothesis

1Skills CLI (Vercel)

npx skills add product-on-purpose/pm-skills --skill tool-foundation-sprint-founding-hypothesis -a claude-code

2Manually: put the files in place

~/.claude/skills/tool-foundation-sprint-founding-hypothesis/SKILL.md

Copy the whole skill folder; for one project use .claude/skills/tool-foundation-sprint-founding-hypothesis/

Step by step, with commands for each platform: How to install skills in Claude Code: five ways

Questions about tool-foundation-sprint-founding-hypothesis

How do I install tool-foundation-sprint-founding-hypothesis in Claude?

Run npx skills add product-on-purpose/pm-skills --skill tool-foundation-sprint-founding-hypothesis -a claude-code. The skill lands in ~/.claude/skills/tool-foundation-sprint-founding-hypothesis/SKILL.md.

What does tool-foundation-sprint-founding-hypothesis do?

It produces the canonical Founding Hypothesis sentence plus an assumption scorecard with confidence levels, why-we-believe and what-could-prove-us-wrong lists, and a recommended next validation step.

When should I run it?

At the end of Day 2 of a Foundation Sprint, after Magic Lenses is signed and the top bet and backup are named. On an unstable top bet the hypothesis will not stabilize.

Source text

SKILL.md · Apache-2.0
---
name: tool-foundation-sprint-founding-hypothesis
description: Day 2 end capstone move of a Foundation Sprint. Compresses the sprint's full strategic frame into a single canonical sentence (the Founding Hypothesis) plus an assumption scorecard, why-we-believe, what-could-prove-us-wrong, and recommended next validation step. Use after Magic Lenses is signed. Strict canonical template; paraphrase is not accepted in v0.1.0. The Founding Hypothesis is the spine artifact the sprint exists to produce.
license: Apache-2.0
metadata:
  classification: tool
  version: "1.0.0"
  updated: 2026-07-04
  tool: foundation-sprint
  move: founding-hypothesis
  category: problem-framing
  frameworks:
    - foundation-sprint
    - click
  timebox_minutes: 45
  roles:
    - facilitator
    - decider
    - pm
  prerequisites:
    - tool-foundation-sprint-basics
    - tool-foundation-sprint-differentiation
    - tool-foundation-sprint-magic-lenses
  inputs:
    - basics bundled artifact
    - differentiation bundled artifact
    - top bet and backup
  outputs:
    - founding hypothesis statement
    - assumption scorecard
    - why we believe this
    - what could prove us wrong
    - recommended next validation step
  author: product-on-purpose
---

<!-- 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`](../../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)

```text
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:

1. Draft the canonical sentence (or co-draft with the PM).
2. Lead the revision pass; push back on vague slots.
3. Score scorecard assumptions with the team; supervote when confidence ratings are contested.
4. Name the recommended next validation step explicitly.
5. 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.

© product-on-purpose · Apache-2.0 · product-on-purpose/pm-skills

Similar skills

All skills for Notes, tasks and projects →

From the same set68

tool-note-and-vote Runs a structured 25-minute group decision session using silent ideation and a final Decider supervote. Prevents groupthink and status bias in teams of 3 to 10 people. CX Codex +1 628installs tool-foundation-sprint-magic-lenses A skill for day 2 of a Foundation Sprint: it runs candidate approaches through several lenses, surfaces contradictions, and names a top bet with a backup plan. CX Codex +1 622installs tool-foundation-sprint-approach-options Facilitates the Day 2 morning step of a Foundation Sprint. Generates 3 to 7 candidate approaches as one-page summaries before the team locks into a single bet. CX Codex +1 622installs tool-foundation-sprint-brief Builds a one-page brief before a Foundation Sprint: scope, the decision to unlock, roles, logistics and what to bring. CX Codex +1 622installs tool-foundation-sprint-basics Structures the Day 1 morning move of a Foundation Sprint. Helps teams align on target customer, core problem, team advantage, and competitor alternatives. CX Codex +1 621installs tool-foundation-sprint-differentiation A skill for the afternoon of Foundation Sprint Day 1: turns the morning Basics frame into a defensible position and a one-page Mini Manifesto. CX Codex +1 621installs tool-design-sprint-test-and-score Closes out Design Sprint Friday: five customer interviews, a scorecard against the sprint questions, and the Decider's build, iterate, pivot or stop call. CX Codex +1 620installs tool-design-sprint-map-and-target Guides Day 1 of a Design Sprint to produce the Monday artifact: long-term goal, customer map, HMW clusters, and target moment. CX Codex +1 620installs

Project sponsors

Companies that keep this analytics open
Gold sponsor

Impressions, clicks and code copies — open statistics. We keep the numbers public for the same reason NeBlask itself is public. Become a sponsor