Skip to content
pm-skills

Using the Foundation Sprint Tools

Foundation Sprint is NOT an agile / Scrum sprint. Foundation Sprint is a 2-day strategic-alignment workshop methodology from Knapp and Zeratsky. Agile sprints are 1-4 week iteration cycles for software delivery. The word “sprint” is shared but the methodologies are unrelated. If you arrived here expecting agile sprint planning, see _workflows/sprint-planning.md instead. For the full disambiguation, see Workshop Sprints vs Agile Sprints.

The Foundation Sprint is a two-day strategic alignment workshop developed by Jake Knapp and John Zeratsky. It converts fuzzy early-stage product beliefs into a single, testable Founding Hypothesis. This guide walks you through pm-skills’ implementation: 7 tool-foundation-sprint-* skills, plus the standalone tool-note-and-vote decision tool used throughout.

Read the Foundation Sprint concept doc if you want the framework’s reasoning, history, and design decisions. Read the family contract for the formal specification. This guide is for getting started.

The 8 tools at a glance

flowchart LR
    R[/tool-foundation-sprint-readiness<br/>Go / Conditional / Wait?/]
    B[/tool-foundation-sprint-brief<br/>Pre-sprint scope contract/]
    BA[/tool-foundation-sprint-basics<br/>Customer + problem + advantage + competitors/]
    D[/tool-foundation-sprint-differentiation<br/>2x2 + principles + Mini Manifesto/]
    AO[/tool-foundation-sprint-approach-options<br/>3-7 candidate approaches/]
    ML[/tool-foundation-sprint-magic-lenses<br/>Top bet + backup/]
    FH[/tool-foundation-sprint-founding-hypothesis<br/>Single testable promise/]
    NV[tool-note-and-vote<br/>Used at decision moments]

    R --> B --> BA --> D --> AO --> ML --> FH
    NV -.-> BA
    NV -.-> D
    NV -.-> AO
    NV -.-> ML

    style R fill:#e1f5ff
    style B fill:#e1f5ff
    style BA fill:#fff4e1
    style D fill:#fff4e1
    style AO fill:#e1ffe1
    style ML fill:#e1ffe1
    style FH fill:#f0e1ff
    style NV fill:#ffe1e1
SkillWhenOutput
/tool-foundation-sprint-readinessBefore schedulingGo, Conditional Go, or Wait recommendation
/tool-foundation-sprint-briefPrep dayOne-page scope, team, logistics, success criteria
/tool-foundation-sprint-basicsDay 1 AMTarget customer, important problem, team advantage, competitor map
/tool-foundation-sprint-differentiationDay 1 PMScored differentiators, 2x2 chart, decision principles, Mini Manifesto
/tool-foundation-sprint-approach-optionsDay 2 AM3 to 7 candidate approaches as one-page summaries
/tool-foundation-sprint-magic-lensesDay 2 PMApproaches scored through 4 classic plus 1+ custom lens; top bet + backup
/tool-foundation-sprint-founding-hypothesisDay 2 endCanonical hypothesis sentence, assumption scorecard, recommended next test
/tool-note-and-voteDecision moments throughout20-30 min structured group decision

Your first Foundation Sprint

Imagine you are about to start a significant new product bet. The team has strong but scattered beliefs about who the customer is, what the right approach is, and how to differentiate. A Design Sprint is on the calendar, but you cannot yet name the hypothesis it would test. Foundation Sprint is the right tool.

Step 0. Readiness check (30-45 minutes, days before)

Terminal window
/tool-foundation-sprint-readiness "We're starting a B2B retail analytics product; team of 4; founder available; no Decider named yet"

The skill returns Go, Conditional Go (with prerequisites), or Wait. Common Wait verdicts: no Decider available, no concrete project yet, or the team lacks even baseline customer knowledge. A Conditional Go often surfaces a missing prerequisite like “name your Decider” or “do 3 customer interviews first” before the sprint can be productive.

If the verdict is Wait, do not run the sprint. Re-run readiness after addressing the prerequisites.

Step 1. Write the brief (45-60 minutes, prep day)

Terminal window
/tool-foundation-sprint-brief "B2B retail analytics; founders + PM + design + eng; Decider is founder; goal is Founding Hypothesis to feed a Design Sprint two weeks later"

The brief locks scope, team, Decider, facilitator, dates, location, and success criteria before the sprint starts. Distribute the one-page output to participants 2-3 days ahead. Anyone who disagrees with the scope or team list raises it now, not Day 1 morning.

Step 2. Day 1 morning - Basics (90-120 minutes)

Terminal window
/tool-foundation-sprint-basics @brief.md

The skill produces a coherent first-day artifact: who the target customer is, what important problem you are solving, what unique advantage this team has, and which competitors and alternatives the customer might consider. This is the strategic frame the rest of the sprint builds on. Force specificity: “small-to-mid US specialty retailers with 5-50 stores” beats “retail businesses.”

Use /tool-note-and-vote if the team is split between two target customer framings. Twenty minutes of silent ideation plus voting plus a Decider supervote is faster than a 90-minute argument.

Step 3. Day 1 afternoon - Differentiation (120-180 minutes)

Terminal window
/tool-foundation-sprint-differentiation @basics-output.md

The team scores differentiators against competitors on a 2x2 chart, names the decision principles that the product will live by, and writes a Mini Manifesto: a one-page strategic summary including a “what this product is” paragraph and an explicit “what this product is NOT” paragraph. The Mini Manifesto becomes a sanity-check artifact: every later decision in the sprint can be evaluated against it.

/tool-note-and-vote is the typical mechanism for selecting the final 2 axes of the 2x2 chart.

Step 4. Day 2 morning - Approach Options (60-90 minutes)

Terminal window
/tool-foundation-sprint-approach-options @manifesto.md

The team generates 3 to 7 candidate approaches as one-page summaries. The minimum-3 floor is anti-anchoring discipline: the most common Day 2 failure is the team converging on a single approach without generating alternatives. The maximum-7 ceiling protects the afternoon Magic Lenses block from blowing up.

If the team only generates 2 ideas, push back into ideation to force at least one more option before progressing. The minimum-3 floor is anti-anchoring discipline, not a budget. Only pause for outside input (customer research, expert interview) if the team genuinely cannot produce a third candidate after a focused ideation block.

Step 5. Day 2 afternoon - Magic Lenses (90-120 minutes)

Terminal window
/tool-foundation-sprint-magic-lenses @approach-options.md

Each approach is evaluated through 4 classic lenses (customer, pragmatic, growth, money) plus at least 1 custom lens specific to the team’s situation. The custom lens captures team-specific constraints or opportunities the 4 classic lenses miss; this is a ratified requirement of the skill. The output names the top bet and a backup.

/tool-note-and-vote runs at the end to consolidate scoring into a single top-bet supervote.

Step 6. Day 2 end - Founding Hypothesis (30-45 minutes)

Terminal window
/tool-foundation-sprint-founding-hypothesis @magic-lenses.md

The capstone skill writes the canonical Founding Hypothesis: a single sentence in the form “If we help [target customer] solve [important problem] with [approach], they will choose it over [competitors or alternatives] because our solution is [differentiators].” The skill enforces this exact structure strictly; paraphrase is rejected. Strictness forces every slot to be filled specifically, which is the whole point.

The output also includes an assumption scorecard ranking the hypothesis’s component beliefs by risk, plus a recommended next test (Design Sprint, customer research, or focused experiment).

The Decider role

Every Foundation Sprint needs a single Decider with formal supervote authority. Without one, the sprint produces a “team consensus” Founding Hypothesis that nobody is accountable for and that re-litigates the moment the team disagrees on next steps.

The Decider is usually the founder, GM, or product leader. The brief and readiness criteria require the Decider to attend all four sprint blocks (Day 1 AM Basics, Day 1 PM Differentiation, Day 2 AM Approach Options, Day 2 PM Magic Lenses, Day 2 end Founding Hypothesis); the family contract requires every TEMPLATE.md to position a Decider Checkpoint at the end so each artifact has explicit sign-off.

If the Decider can realistically only attend a subset of blocks, the readiness skill returns Conditional Go with explicit checkpoint coverage requirements, not Go. If no Decider can be named, readiness returns Wait. Do not run the sprint without a committed Decider.

How note-and-vote fits in

tool-note-and-vote is a standalone tool, not a family member. It is the structured decision mechanic used throughout Foundation Sprint (and later, Design Sprint) at moments where the team needs to converge in 20-30 minutes rather than argue for 90. Typical Foundation Sprint usage: target customer split (Step 2), 2x2 axis selection (Step 3), approach generation prompts (Step 4), top-bet supervote (Step 5).

A note-and-vote always ends in a Decider supervote. The voting is informational; the Decider’s pick is binding.

Handoff to Design Sprint

The Founding Hypothesis is often the input to a downstream Design Sprint. There is no formal bridge skill in pm-skills because the canonical Knapp/Zeratsky methodology has no formal handoff move. The transition is narrative.

How Foundation Sprint outputs feed Design Sprint inputs:

flowchart LR
    subgraph FS[Foundation Sprint outputs]
        TC[Target customer]
        IP[Important problem]
        TB[Top bet approach]
        AS[Assumption scorecard]
        BP[Backup plan]
    end
    subgraph DS[Design Sprint Day 1 inputs]
        REC[Customer recruiting profile]
        LTG[Long-term goal context]
        PD[Prototype direction]
        SQ[Sprint questions]
        SCO[Scorecard targets]
        PV[Pivot option]
    end
    TC --> REC
    IP --> LTG
    TB --> PD
    AS --> SQ
    AS --> SCO
    BP --> PV
Foundation Sprint outputBecomes Design Sprint input
Target customerCustomer recruiting profile (Design Sprint brief)
Important problem framingDay 1 long-term goal context
Team advantageDay 1 expert interview prioritization + framing of “why us, why now”
Competitors and alternativesDay 1 long-term goal context + Day 4 prototype differentiation framing
DifferentiatorsDay 1 Map and Target + Day 3 storyboard moments of differentiation
Mini ManifestoDay 1 sanity-check during Map and Target; Day 3 storyboard alignment check
Decision principlesDay 2 Decide voting criteria + Day 3 storyboard guardrails
Top bet (approach)Prototype direction (Day 3 storyboard)
Assumption scorecardSprint questions (Day 1 Map and Target)
Highest-risk assumptionPrimary scorecard row (Day 5 Test and Score)
Backup planPivot option if Friday signal is weak

Go / no-go checkpoint: the Decider confirms the Founding Hypothesis is testable through a 5-day prototype before starting the Design Sprint. If the highest-risk assumption cannot be tested that way, the team revisits the hypothesis or chooses a different next test.

Timing: run the Design Sprint within 1 to 2 weeks of Foundation Sprint while the strategic context is fresh. Longer gaps invite re-litigation of the Founding Hypothesis.

Other next steps that are not a Design Sprint: the Founding Hypothesis’s recommended next test is not always a prototype. Sometimes the right answer is more customer research (via discover-interview-synthesis), a focused experiment (via measure-experiment-design), a concierge MVP, or skipping straight to feature kickoff if the hypothesis is already well-validated.

Working with AI during a Foundation Sprint

The pm-skills implementation makes AI a first-class participant in the sprint, but the canonical Knapp/Zeratsky principle still holds: the Decider decides, the team contributes, the AI prepares. Use AI to accelerate the work AI is good at (drafting, synthesizing, generating alternatives, summarizing) and keep humans in charge of the work humans must own (customer empathy, business judgment, the supervote).

Where AI helps

Sprint momentAI usage patternWhy it works
Pre-sprint prepDraft the brief from a paragraph of context (/tool-foundation-sprint-brief @notes.md)Removes the “blank page” friction; the team edits a draft instead of starting cold
Day 1 AM BasicsGenerate competitor map and “do nothing” alternativesAI sweeps faster than the team can recall; humans curate
Day 1 PM DifferentiationDraft Mini Manifesto from the scored 2x2 + principlesFirst-draft language is faster to react to than to compose
Day 2 AM Approach OptionsGenerate the 3rd-7th candidate approaches when the team is anchored on 1-2Anti-anchoring discipline gets easier with a generative collaborator
Day 2 PM Magic LensesDraft scores across the 4 classic lenses; humans curate + supply the custom lensAI handles the symmetric scoring grunt work; custom lens is irreducibly human
Day 2 end Founding HypothesisDraft hypothesis language fitting the strict canonical templateThe strict template constrains output enough that AI drafts are easy to evaluate
ThroughoutCapture meeting notes during note-and-vote and decision momentsReduces facilitator load

Where AI does NOT help (or hurts)

Sprint momentWhy AI fails here
Decider supervoteThe point of the Decider role is single-human accountability; AI input dilutes ownership and erodes team buy-in
Customer empathy claimsAI can summarize prior research; it cannot manufacture customer knowledge. If the team’s input is “we think customers want X,” AI generates more confident-sounding versions of the same guess. Use customer evidence, not AI hallucinations
Team advantage assessment”Why us, why now” requires honest self-assessment that AI cannot perform. AI will rationalize whatever advantage the team proposes
Final Founding Hypothesis sign-offThe hypothesis is the team’s commitment, not a prediction. Treat the AI-drafted version as a candidate, then the Decider says the final words
Picking between approaches when scores tieAI score tie-breaking is fake confidence. Force the Decider to choose, then live with the choice

Specific prompt patterns

When the team is using Claude Code with pm-skills loaded, a few patterns produce consistently better results:

  1. Pass the prior artifact explicitly: /tool-foundation-sprint-differentiation @basics-output.md. Skills auto-discover related artifacts but the explicit pass is faster and avoids ambiguity when multiple Basics artifacts exist.
  2. Tell the skill what’s missing: “Decider unavailable Day 2 AM; will sign at Day 2 end” surfaces it as inference and the Decider Checkpoint flags the gap rather than silently passing.
  3. Re-run when the Founding Hypothesis is vague: the strictness check is the point; re-run with sharper inputs rather than accepting the vague draft.
  4. Use /tool-note-and-vote for any moment the team would otherwise spend 60+ minutes debating: 20-30 minutes silent ideation + voting + Decider supervote is dramatically faster than open discussion.

The “AI co-facilitator” pattern

A working pattern from early Foundation Sprint pilots: one human facilitator, one AI scribe-plus-drafter. The facilitator manages time, attention, and group dynamics; the AI captures notes, drafts artifacts, and offers alternative framings on request. The Decider, PM, and design participants stay focused on judgment work. This is the model the pm-skills toolkit is designed around.

Common pitfalls

  1. Running without a Decider. The sprint produces an unowned hypothesis that re-litigates as soon as anyone disagrees with next steps. Re-run readiness; do not start the sprint until a Decider is named.
  2. Generating only 1-2 approaches. Approach Options enforces a minimum of 3 specifically to break anchoring on the first idea anyone said out loud. If the team genuinely cannot generate 3, treat that as a research gap, not a sprint failure.
  3. Skipping the custom Magic Lens. The 4 classic lenses are generic by design. The custom lens captures a team-specific constraint or opportunity the classics miss. The skill requires at least 1.
  4. Paraphrasing the Founding Hypothesis. The strict canonical structure exists to force specificity. A paraphrased hypothesis is almost always a vague hypothesis. Re-run the skill on the same inputs if the first draft drifts.
  5. Treating the sprint as customer research. Foundation Sprint operates on the team’s existing knowledge. If the team has zero customer or market knowledge, the readiness skill will catch that. Do customer research first.
  6. Inviting too many people. Foundation Sprint works with 3 to 5 people, optimally 4. Bigger groups produce slower decisions and noisier outputs. Use the brief’s team-list slot to enforce this.
  7. Skipping the brief. Without a one-page locked scope distributed in advance, Day 1 morning starts with 60 minutes of scope debate instead of Basics. The brief is cheap insurance.

File naming and outputs

The skills produce bundled artifacts following the family contract’s TEMPLATE.md structure:

Skill suffixFilename convention
readinessfoundation-sprint-readiness_{project}.md
brieffoundation-sprint-brief_{project}.md
basicsfoundation-sprint-basics_{project}.md
differentiationfoundation-sprint-differentiation_{project}.md
approach-optionsfoundation-sprint-approach-options_{project}.md
magic-lensesfoundation-sprint-magic-lenses_{project}.md
founding-hypothesisfoundation-sprint-founding-hypothesis_{project}.md
note-and-votenote-and-vote_{question-slug}.md

Each artifact has a Decider Checkpoint section near the end (last 25% of the TEMPLATE.md by family contract). The Decider Checkpoint is the explicit moment where the Decider ratifies the artifact before moving to the next skill.