Skip to content
pm-skills

Foundation Sprint

Foundation Sprint is NOT an agile / Scrum sprint. It is a 2-day workshop methodology from Knapp and Zeratsky (Character Capital). For the cross-method disambiguation, see Workshop Sprints vs Agile Sprints. For pm-skills’ agile sprint planning content, see _workflows/sprint-planning.md.

Executive Summary

A Foundation Sprint is a two-day workshop for aligning a small team at the beginning of a big project around six strategic questions: who is the target customer, what important problem are we solving, what advantage does this team have, who are the competitors and alternatives, how will the product differentiate, and which approach should be tested first.

The output is not a strategy deck. The output is a single coherent sentence called the Founding Hypothesis that fits the customer, problem, approach, competitors, and differentiators into one testable promise. That hypothesis can then be tested with a Design Sprint, customer research, or a focused experiment.

Foundation Sprint is the strategic-alignment counterpart to Design Sprint. Design Sprint tests a risky idea with a realistic prototype and target customers. Foundation Sprint decides what risky idea is worth testing in the first place. When a team has the resources for a Design Sprint but cannot yet name the hypothesis it would test, a Foundation Sprint is the right tool.

Origins: From Sprint to Foundation Sprint

Why Jake Knapp and John Zeratsky Built It

The Foundation Sprint was developed by Jake Knapp and John Zeratsky, the two co-authors of the original Sprint book, after they left Google Ventures to start Character Capital, an early-stage investment firm. Through Character, they began running Design Sprints with founders of pre-seed and seed-stage startups and noticed a recurring failure mode: teams arrived at the Design Sprint without enough strategic clarity to use the week well.

Design Sprint assumes a team has already chosen the customer, the problem, and the hypothesis worth testing. The five-day method then channels enormous facilitation energy into testing that hypothesis with a prototype. When the inputs are unclear, the prototype tests the wrong thing, the customer interviews produce noisy data, and the Friday scorecard delivers a confident answer to a poorly-chosen question.

Foundation Sprint was designed to be the upstream complement: a faster, lighter workshop whose output is exactly the hypothesis a Design Sprint can then validate.

Canonical Sources

The most authoritative public materials are:

The full reference list appears at the end of this document.

The Conceptual Model

flowchart LR
    A[Big project or new product bet] --> B[Basics]
    B --> C[Target customer]
    B --> D[Important problem]
    B --> E[Team advantage]
    B --> F[Competitors and alternatives]
    F --> G[Differentiation]
    G --> H[Mini Manifesto]
    H --> I[Approach options]
    I --> J[Magic Lenses]
    J --> K[Top bet and backup]
    K --> L[Founding Hypothesis]
    L --> M[Test with Design Sprint or other experiment]

The process deliberately moves from customer and problem clarity, to differentiation, to approach selection, to a testable hypothesis. Each block surfaces a decision the team must make explicit before the next block can produce useful output.

The Core Claim

The value of a Foundation Sprint is not merely alignment. The value is converting fuzzy early-stage product beliefs into a single, testable strategic promise. A team that leaves the workshop with only shared language has improved alignment. A team that leaves with a Founding Hypothesis has a direction it can test.

When to Use a Foundation Sprint

Use it whenSkip it when
Starting a significant new initiative where the wrong starting direction is costlyThere is no concrete project, opportunity, or strategic question yet
The team has multiple plausible approaches and needs to choose a top betThe team has zero customer or market knowledge to draw on
Different stakeholders describe the customer or problem differentlyDeep problem discovery is what’s missing; do that first
The team cannot clearly state why customers would choose this over alternativesNo Decider is available to make strategic calls
Founder or executive beliefs are strong but scattered, not explicitThe hypothesis is already clear; jump straight to a Design Sprint
A Design Sprint is on the calendar but the strategic promise to test is not yet namedThe decision is minor; use a lighter prioritization tool

Foundation Sprint depends on the team’s existing knowledge. It is not a substitute for customer research, market research, or problem discovery when those are what is actually needed.

The Two-Day Breakdown

flowchart TD
    subgraph Day1["Day 1"]
        AM1["Morning: Basics<br/>Customer, problem, advantage, competitors"]
        PM1["Afternoon: Differentiation<br/>Score, generate, choose, chart, principles, Mini Manifesto"]
    end
    subgraph Day2["Day 2"]
        AM2["Morning: Approach Options<br/>List, summarize, select up to 7"]
        PM2["Afternoon: Magic Lenses<br/>Customer / Pragmatic / Growth / Money lenses, top bet, Founding Hypothesis"]
    end
    Day1 --> Day2
    Day2 --> Next["Hypothesis Scorecard<br/>Validation plan"]

Day 1, Morning: Basics

The morning of Day 1 forces the team to make four foundational choices explicit. Each is something the team probably believes implicitly already, but the workshop demands a single chosen interpretation rather than multiple unstated ones.

  1. Choose a target customer in plain language. Real people or organizations, not vague segments.
  2. Choose an important customer problem. A pain strong enough to justify the customer switching, paying, learning, or adopting.
  3. Identify the team’s advantage. The capability, insight, motivation, relationship, data, technology, distribution, or timing edge that makes this team credible.
  4. List competitors and alternatives. Direct competitors, substitute workflows, manual workarounds, internal tools, and crucially, doing nothing.

Each choice is made through Note-and-Vote: independent silent contributions, a silent vote, a brief discussion, and a final Decider supervote. Note-and-Vote appears so often in Foundation Sprint and Design Sprint that Character publishes a separate guide for it.

Day 1, Afternoon: Differentiation

The afternoon converts the morning’s choices into a strategic position the product can occupy.

flowchart LR
    A[Classic differentiators] --> C[Score on customer-perceived dimensions]
    B[Custom differentiators] --> C
    C --> D[Choose 2 differentiators]
    D --> E[2x2 differentiation chart]
    E --> F[Decision principles]
    F --> G[Mini Manifesto]

The team scores how the solution could stand out on standard customer-perceived dimensions (speed, simplicity, price, trust, breadth, depth, and so on), generates custom dimensions specific to its market, then chooses two differentiators worth committing to.

The two chosen differentiators are placed on a customer-perceived 2x2 chart showing where the product could occupy a meaningfully different position from competitors. The team then converts those differentiators into decision principles: rules that will guide future product choices (“we will always prefer X over Y”).

The result is the Mini Manifesto, a one-page strategic artifact summarizing Day 1.

Day 2, Morning: Approach Options

flowchart TD
    A[Generate possible approaches] --> B[One-page approach summaries]
    B --> C{Decider selects up to 7}
    C --> D[Assign identifiers: color/letter/label]
    D --> E[Ready for Magic Lens comparison]

The morning of Day 2 deliberately defers commitment to a single approach. Teams tend to anchor on the first plausible solution; Foundation Sprint forces them to generate alternatives and compare them. The approach summaries describe what the approach is, why it is a good idea, and include a simple doodle or visual.

Day 2, Afternoon: Magic Lenses and the Top Bet

The afternoon evaluates each approach through multiple perspectives, called Magic Lenses.

flowchart LR
    Options[Up to 7 approach options] --> Customer[Customer Lens<br/>What customers will value]
    Options --> Pragmatic[Pragmatic Lens<br/>Easiest to execute]
    Options --> Growth[Growth Lens<br/>Can spread or scale]
    Options --> Money[Money Lens<br/>Strongest business potential]
    Options --> Custom[Custom Lenses<br/>Mission fit, founder excitement, pain, uniqueness, etc.]
    Customer --> Patterns[Pattern Review<br/>Consistent winners, contradictions, tradeoffs]
    Pragmatic --> Patterns
    Growth --> Patterns
    Money --> Patterns
    Custom --> Patterns
    Patterns --> Decision[Decider chooses top bet and backup]
    Decision --> Hypothesis[Write Founding Hypothesis]

Each lens produces a 2x2 chart placing every option relative to the other options on that perspective. Patterns across the charts make tradeoffs visible: an option that wins the Customer Lens but loses the Pragmatic Lens is asking the team to take a feasibility bet; an option that wins on Money but loses on Customer is asking the team to bet that they can shift customer perception over time.

The Decider then chooses a top bet and a backup plan. The backup matters: without it, invalidation of the top bet sends the team back to ambiguous debate. With it, invalidation triggers a pre-decided next experiment.

The Founding Hypothesis

The Founding Hypothesis is the central artifact of the entire sprint. A practical structure:

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

This single sentence forces the team to state customer, problem, approach, competition, and differentiation in one coherent promise.

flowchart LR
    Customer[Target customer] --> Hypothesis
    Problem[Important problem] --> Hypothesis
    Approach[Top-bet approach] --> Hypothesis
    Competitors[Competitors and alternatives] --> Hypothesis
    Differentiators[Differentiators] --> Hypothesis
    Hypothesis[Founding Hypothesis] --> Scorecard[Hypothesis Scorecard]
    Scorecard --> Test[Design Sprint, interviews, experiment]

What Makes a Good Founding Hypothesis

QualityWhat it means
SpecificNames a real customer and a real problem; not “users” and “frustrations”
ComparativeExplains what customers choose today, including doing nothing
DifferentiatedStates why this solution should win, not just that it should
TestableCan be translated into scorecard questions and experiments
SimpleA customer can understand the promise quickly
Uncomfortable enough to be usefulIf nobody disagrees or feels exposed, the hypothesis may be too vague

The Hypothesis Scorecard

The hypothesis is then decomposed into testable parts:

Hypothesis elementTest questionEvidence source
Target customerDo we have the right customer?Interviews, usage, sales signals
Important problemIs the problem painful enough?Interviews, willingness to pay, behavior, support data
ApproachDoes the chosen approach make sense and feel valuable?Prototype testing, concept testing, concierge trial
Competitors and alternativesWould customers choose this over what they do now?Competitive interviews, switching behavior, win/loss data
DifferentiatorsDo the differentiators matter to customers?Prototype testing, message testing
CredibilityWill customers believe the product can deliver the promise?Sales calls, prototype reactions, brand trust signals
ClickDoes the whole promise feel simple and compelling?Design Sprint, landing page test, customer reaction

Any of these rows can become a Design Sprint question, an interview script, or an experiment design.

Core Mechanics: Note-and-Vote and the Decider

Two protocols recur throughout Foundation Sprint.

Note-and-Vote

flowchart LR
    A[Decision question] --> B[Silent individual writing]
    B --> C[Silent voting on contributions]
    C --> D[Brief discussion of vote distribution]
    D --> E[Decider supervote]
    E --> F[Decision recorded]

Each decision is made through Note-and-Vote rather than open discussion. The protocol surfaces independent thinking before group dynamics narrow the option space. It also produces a written trail of the decision and its alternatives, which matters when the team revisits the hypothesis later.

The Decider

The Decider is not symbolic. The Decider has the right to override the team’s votes when needed, accepts responsibility for the outcome, and most importantly, makes decisions visible. Without a Decider, the team can vote indefinitely without converging; the workshop produces options instead of bets.

Team Size and Composition

RoleRequired?Why
DeciderYesMakes the final strategic calls
FacilitatorYesProtects pace, process, decision hygiene, and participation
Product manager or product leadUsuallyBrings customer, product, and business context
Customer expertUsuallyBrings customer understanding from research, sales, success, support
Technical expertUsuallyGrounds approaches in feasibility and constraints
Design or product strategy leadUsuallyHelps visualize options and shape differentiation
Growth or marketing expertHelpfulGrounds promise, channel, positioning, competitive reality
Executive or founderOftenUseful when strategy or company advantage is being set

Character recommends no more than five core decision participants. A group with only executives may become abstract; a group with only practitioners may lack strategic authority.

Foundation Sprint Compared to Design Sprint

flowchart LR
    A[Foundation Sprint<br/>2 days] --> B[Founding Hypothesis]
    B --> C[Hypothesis Scorecard]
    C --> D[Design Sprint<br/>5 days]
    D --> E[Tested prototype and scorecard]
    E --> F{Decision}
    F --> G[Build]
    F --> H[Iterate]
    F --> I[Run another sprint]
    F --> J[Stop or reframe]
DimensionFoundation SprintDesign Sprint
Primary purposeChoose the strategic promise and approachTest a risky idea with customers
DurationTwo daysFive days
Core outputFounding HypothesisTested prototype and scorecard
Best timingBeginning of a big projectAfter a challenge or hypothesis is clear
Main questionWhat should we believe and test?Do customers understand, value, and respond to this?
Primary evidenceTeam knowledge, structured comparison, decision logicCustomer interviews and prototype reactions
Main riskFalse confidence from weak inputsNoisy learning from weak prototype or wrong participants
Typical next stepDesign Sprint, customer research, experiment, or strategy revisionBuild, iterate, retest, or stop

Foundation Sprint is upstream of Design Sprint when the team does not yet know what to test. Design Sprint is downstream when the team has a hypothesis or concept that can be prototyped. They are designed to work together; running a Design Sprint without a strong Foundation Sprint output (whether from a workshop or from existing strategic clarity) is a common failure mode.

Variants and Adaptations

Startup Foundation Sprint

Startups often have strong founder intuition but inconsistent articulation. The Foundation Sprint forces that intuition into a written, testable form.

  • Keep the team extremely small (often three or four people).
  • Focus heavily on differentiation and competitors; founder bias toward “we’re just better” needs explicit pressure.
  • Treat the Founding Hypothesis as a living validation artifact, updated as customer evidence arrives.
  • Follow quickly with prototype testing, founder-led sales conversations, or a Design Sprint.

Enterprise Foundation Sprint

Large organizations distribute customer knowledge, decision authority, technical context, and market insight across many teams.

  • Add pre-work to synthesize customer research, support themes, sales objections, usage data, and technical constraints into a single research packet.
  • Include cameo experts on specific topics instead of expanding the core team beyond five.
  • Identify the real Decider and escalation path before the sprint.
  • Document decisions with rationale and confidence so the output survives organizational handoff.
  • Translate the Founding Hypothesis into downstream artifacts: PRDs, opportunity solution trees, roadmap bets, Design Sprint questions.

AI-Era Foundation Sprint

Character argues that as AI makes building faster, deciding what to build becomes more important. Foundation Sprint is especially relevant when teams can rapidly prototype many product options but still need a differentiated strategic promise.

  • Use AI to prepare inputs (research synthesis, competitor maps, scorecard drafts), not to replace decisions.
  • Use AI to generate alternative approaches, but force human Decider choices.
  • Use AI to draft first-pass hypothesis language, then refine through team discussion.
  • Use human customer evidence to test whether the promise actually clicks.

Common Failure Modes

Failure modeWhat goes wrongMitigation
Confusing alignment with validationThe team aligns on a hypothesis but treats it as provenAlways end with a Hypothesis Scorecard and validation plan
Insufficient customer contextConfident guesses fill knowledge gapsDo problem discovery first; only run when team has real context
Executive dominanceSenior leaders push decisions without practitioner groundingCap team at five; include hands-on customer and product experts
Vague customer segmentsBroad segments produce weak hypothesesPush for named individuals or buyer types
Ignoring “do nothing” as a competitorInertia is often the strongest alternative; teams miss itExplicitly include doing-nothing in competitor maps
Choosing undeliverable differentiatorsDifferentiation is only useful if the team can make it trueTest each chosen differentiator against feasibility and team advantage
Falling in love with the top betThe top bet becomes a strategy rather than the first test candidateAlways pair top bet with backup plan
Skipping the backup planInvalidation sends the team back to ambiguous debateMake backup plan a Day 2 PM requirement
Hypothesis becomes static strategy copyThe output never drives experimentsMake a Hypothesis Scorecard before declaring the sprint complete

How Foundation Sprint Connects to pm-skills

The Foundation Sprint framework lands in pm-skills as a foundation-sprint-skills family under the classification: tool taxonomy, integrated alongside the existing domain, foundation, and utility skills.

Skill Family Map

flowchart TD
    Readiness[tool-foundation-sprint-readiness<br/>Is the team ready?] --> Brief[tool-foundation-sprint-brief<br/>Prep and sprint setup]
    Brief --> Basics[tool-foundation-sprint-basics<br/>Customer, problem, advantage, competitors]
    Basics --> Diff[tool-foundation-sprint-differentiation<br/>Differentiators, 2x2 chart, principles, Mini Manifesto]
    Diff --> Options[tool-foundation-sprint-approach-options<br/>Generate up to 7 approaches]
    Options --> Lenses[tool-foundation-sprint-magic-lenses<br/>Compare approaches, top bet, backup]
    Lenses --> Hypothesis[tool-foundation-sprint-founding-hypothesis<br/>Write the single testable promise]
    Hypothesis --> Handoff[Narrative handoff<br/>Founding Hypothesis becomes Design Sprint context]
    NoteVote[tool-note-and-vote<br/>Standalone decision tool used throughout]

The tool-note-and-vote skill is a standalone tool used by both Foundation Sprint and Design Sprint at decision moments; it is not a family member of either sprint family. The Foundation-to-Design transition is described narratively in _workflows/foundation-to-design.md and in this guide’s companion docs/guides/using-foundation-sprint.md; there is no separate bridge skill because canonical Knapp/Zeratsky methodology has no formal handoff move.

The foundation-sprint workflow chains these skills into a complete two-day facilitation pass. Run the readiness skill first; if the readiness assessment returns Go, the brief and core skills run in sequence; if Wait or Conditional Go, do the prerequisite work (often problem framing or customer research) and re-assess.

See docs/guides/using-foundation-sprint.md for the operational guide.

Practical Applications

Pre-Funding Strategic Clarity

Founders use Foundation Sprint before their seed round to articulate the promise an investor needs to evaluate. The Founding Hypothesis becomes the centerpiece of the pitch deck’s “what we’re building” page.

Pre-Build Strategic Clarity

PMs use Foundation Sprint at the start of a large initiative to align engineering, design, and go-to-market on the strategic direction before scoping begins. The Mini Manifesto becomes a decision-making reference for the next several months of execution.

Re-Alignment After Drift

When an initiative has lost coherence (multiple teams pulling in different directions, conflicting roadmap bets, stakeholder confusion), Foundation Sprint surfaces the unstated disagreements and forces choices.

Pre-Design-Sprint Setup

Teams that have a Design Sprint scheduled but cannot clearly answer “what hypothesis are we testing?” run Foundation Sprint first. The Founding Hypothesis becomes the input to Monday morning of the Design Sprint.

References and Further Reading

Primary Sources

Adjacent Reading (Books)

These books inform the conceptual foundations of Foundation Sprint without being directly canonical to the method. Useful for teams that want deeper background on the underlying ideas.

  • Ries, Eric. The Lean Startup (Crown Business, 2011). Build-Measure-Learn cycle; hypothesis-driven product development. Foundation Sprint produces the testable hypothesis Lean Startup demands at the front end.
  • Blank, Steve. The Four Steps to the Epiphany (K&S Ranch, 2005 / second edition 2013). Customer-development methodology; problem-and-solution-fit framing that the Foundation Sprint Basics step formalizes.
  • Maurya, Ash. Running Lean (O’Reilly, 3rd edition 2022). Lean canvas + customer-development practice. Lean canvas overlaps with Foundation Sprint Basics but is less ritualized.
  • Osterwalder, Alexander; Pigneur, Yves. Business Model Generation (Wiley, 2010). The original BMC; differentiation work in Foundation Sprint borrows from BMC’s value-proposition framing.
  • Osterwalder, Alexander; Pigneur, Yves; Bernarda, Greg; Smith, Alan. Value Proposition Design (Wiley, 2014). Customer-jobs + pains + gains analysis adjacent to Foundation Sprint’s important-problem framing.
  • Torres, Teresa. Continuous Discovery Habits (Product Talk, 2021). Opportunity-solution tree; ongoing customer interviews. Pairs with Foundation Sprint as the post-FS validation cadence.
  • Ulwick, Anthony. Jobs to be Done: Theory to Practice (Idea Bite Press, 2016). Outcome-driven innovation; the JTBD framing that informs Foundation Sprint target-customer + important-problem work.
  • Cagan, Marty. Inspired (Wiley, 2nd edition 2018). Empowered product teams; provides the team-structure context Foundation Sprint assumes.
  • Duke, Annie. Thinking in Bets (Portfolio, 2018). Decision-making under uncertainty; useful framing for Magic Lenses scoring and Decider supervote work.
  • Kahneman, Daniel. Thinking, Fast and Slow (Farrar, Straus and Giroux, 2011). System 1 vs System 2; explains why structured-deliberation moments (like Magic Lenses) outperform informal team discussion.
  • Knapp, Jake; Zeratsky, John. Make Time (Currency, 2018). The authors’ productivity book; useful background on the design-and-decision rhythm that informs Foundation Sprint’s two-day discipline.

Adjacent Reading (Articles + Talks)

  • Brown, Tim. “Design Thinking.” Harvard Business Review (June 2008). hbr.org/2008/06/design-thinking. The HBR article that popularized “design thinking” as an executive concept; useful context for explaining Foundation Sprint to design-thinking-familiar stakeholders.
  • Knapp, Jake. Medium archive at medium.com/@jakek. Various essays on sprint methodology, design facilitation, and the Foundation Sprint origin story.
  • Zeratsky, John. Personal blog at johnzeratsky.com. Posts on the GV-to-Character transition and the rationale for the Foundation Sprint.
  • Reforge. “How to validate a startup idea.” Various authors. reforge.com. Adjacent to Foundation Sprint’s purpose; longer-cycle versions of the same validation question.
  • Silicon Valley Product Group (SVPG). Product discovery articles by Marty Cagan and team. svpg.com. Discovery-focused product practice; Foundation Sprint is one structured tactic within the broader discovery toolkit.
  • Center for Innovation at Mayo Clinic (Maggie Breslin, Christopher Murray, et al.). Service design and prototyping work; useful for teams running Foundation Sprint in healthcare or other regulated contexts.

The following pm-skills cover adjacent practices that compose with or substitute for parts of Foundation Sprint:

  • foundation-lean-canvas - Ash Maurya’s lean canvas. Less ritualized than Foundation Sprint Basics but covers similar territory in 60-90 min.
  • foundation-persona - canonical persona template. Composes with Foundation Sprint Basics target-customer work; can be used as input.
  • foundation-okr-writer - outcome-based OKRs. The Founding Hypothesis is an upstream artifact OKRs flow from at the start of a cycle.
  • define-jtbd-canvas - JTBD canvas. Adjacent framing for important-problem work.
  • define-hypothesis - lightweight hypothesis definition. The Founding Hypothesis is a heavier-weight ritualized version; this skill is the smaller-cycle counterpart.
  • develop-spike-summary - tech spike output. Useful when Foundation Sprint’s recommended next test is a technical-feasibility investigation rather than a Design Sprint.

Part of PM-Skills - Open source Product Management skills for AI agents.