Tool Foundation Sprint Founding Hypothesis

What the source does

• FilesystemNone observedNo reads or writes in the source
• NetworkNone observedNo outbound calls in the source
• ShellNone observedNo commands run in the source
• DependenciesPinnedNothing floats
• SecretsNone foundNo keys in source

Five audit layers

Gates applied: no behavioural pass.

Audit 0.4.1 · source sha 2abfbb961d31 · 19 Oct 2026Report an issue or request a re-scan

• Publisherproduct-on-purpose GitHub organizationOwner of the repository this skill is read from
• Source folderproduct-on-purpose/pm-skills/skills/tool-foundation-sprint-founding-hypothesisThe exact folder we audited
• LicenceApache-2.0As the repository states it
• Commit pinned for this verdict2abfbb961d31A new audit runs when the source changes
• Repository statusNot archivedLast push 1 day ago
• Sandboxed runNot runSkills are read, not executed; layer L4 is skipped

Its 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,…

---
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 

Excerpt, first 6,000 characters of SKILL.md, verbatim from the audited commit. It is text from someone else’s repository, quoted so you can judge it before your agent reads it.

git clone https://github.com/product-on-purpose/pm-skills
git -C pm-skills checkout 2abfbb961d31

Works in

1. 2026-10-19
   ✓SAFE B 89 / 100

   first audit · source 2abfbb961d31

Questions about Tool Foundation Sprint Founding Hypothesis

• github.com/product-on-purpose/pm-skills/tree/main/skills/tool-fo — the audited source at commit 2abfbb961d31 and every finding aboveObserved · 19 Oct 2026

Spotted something wrong? Report a correction · Methodology