Design Sprint vs Foundation Sprint: How the Two Knapp Sprints Work
The 5-day Design Sprint tests a solution with five customers. The 2-day Foundation Sprint decides what to build in the first place. What each day involves and when to run which.
· 7 min read
A team of six spends four months building a feature, ships it, and watches usage flatline in the first week. The code works. The problem is that the most expensive question ("will anyone want this?") was answered last instead of first. Sprints exist to move that question to the front, and there are now two of them from the same authors: the 5-day Design Sprint, which tests a solution, and the 2-day Foundation Sprint, which decides what the solution should even be.
This guide covers both, how they relate, and how to run them with the Design Sprint Checklist and the Foundation Sprint Worksheet.
Where the two sprints come from
The Design Sprint was developed by Jake Knapp at Google Ventures, where it was run with portfolio companies before being written up in the book Sprint (2016) by Knapp, John Zeratsky and Braden Kowitz. The pitch is simple: in five days, a small team goes from a big problem to a realistic prototype tested with real customers, without writing production code.
The Foundation Sprint is newer. Knapp and Zeratsky developed it at Character Labs, their venture studio, and described it in the book Click (2025). It answers the question that comes before a Design Sprint: who is the customer, what is the problem, and why would your approach beat the alternatives? Its output is a single sentence called the Founding Hypothesis, which a Design Sprint can then put to the test.
| Foundation Sprint | Design Sprint | |
|---|---|---|
| Length | 2 days | 5 days |
| Question it answers | What should we build, and for whom? | Does this solution work for real customers? |
| Main output | A Founding Hypothesis | A tested prototype and interview findings |
| Customer contact | Not required during the sprint | Five customer interviews on day 5 |
| Best moment | Before committing to a direction | Before committing engineering time to a solution |
How the 5-day Design Sprint works
Monday: map the problem. The team "starts at the end" by agreeing a long-term goal and listing the sprint questions that could make it fail. Experts from inside the company are interviewed while everyone writes "How Might We" notes, short reframes of problems as opportunities. By the end of the day the team draws a simple map of the customer journey and picks one target moment on it to focus on.
Tuesday: sketch. The morning starts with lightning demos: three-minute tours of existing products, from any industry, that solve a similar problem well. In the afternoon each person sketches alone using the four-step sketch: notes, rough ideas, Crazy 8s (eight variations in eight minutes) and a final three-panel solution sketch. Working alone together avoids the loudest-voice problem of group brainstorming.
Wednesday: decide. Sketches go on the wall like an art museum. People put dot stickers on the parts they like (the heat map), the group runs a speed critique, everyone casts a straw poll vote, and the Decider (usually the CEO or product owner) makes a supervote. If two strong ideas survive, they can face off in a rumble, both prototyped and tested. The afternoon produces a storyboard, a step-by-step plan for the prototype.
Thursday: prototype. The team builds a facade: a Keynote click-through, a Figma flow or a fake landing page that looks real enough for a customer to react honestly. Anything a tester will not see does not get built.
Friday: test. One interviewer runs five one-on-one sessions while the rest of the team watches on a stream and notes patterns. Five is not arbitrary. It follows Jakob Nielsen's observation that around five users reveal most of the usability problems in a design, and after that you mostly hear repeats.
Running it with the Design Sprint Checklist
The Design Sprint Checklist turns those five days into tabs named Understand, Ideate, Decide, Prototype and Test. The names differ slightly from the book (Map and Sketch become Understand and Ideate), but the activities are the same ones listed above.
Each day has six tasks, 30 in total. Ticking a task updates the overall progress bar, so ticking 9 tasks shows 30% (9 of 30). A green dot appears on a day's tab once all six of its tasks are done. Each day also has a Day Notes and Insights box for decisions, quotes from the expert interviews and the final vote.
A worked example: a team building a freelancer marketplace has set its long-term goal, mapped the problem and run lightning demos. Clicking Load Sample fills in exactly this state, with two Understand tasks and one Ideate task ticked and notes like "Defined core problem: Users struggle to find reliable freelancers quickly". The progress bar reads 10% (3 of 30), and the summary underneath lists each day's count, for example "Day 1: Understand, 2/6 tasks completed".
Your progress is saved in your browser under the key design-sprint, so closing the tab does not lose a half-finished sprint. Load Sample replaces your current progress, so use it on a fresh browser profile if you only want a look. When the week ends, the Text, Image and PDF buttons export the summary for the people who were not in the room.
The Foundation Sprint and the Founding Hypothesis
A Design Sprint assumes you already know the customer and the problem. Many early teams do not, and running a polished 5-day test of the wrong idea is still a waste of a week. The Foundation Sprint covers that gap in two days.
The first part works through the basics: who the customer is, what problem they have, what advantages the team brings and who the real competition is (including "do nothing" and spreadsheets). The team then picks differentiators and plots itself against competitors on a 2x2 chart, looking for a position that is clearly different. Next it compares several possible approaches through different lenses, which Click calls Magic Lenses, before choosing one.
Everything gets compressed into the Founding Hypothesis:
If we help [customer] solve [problem] with [approach], they will choose it over [competitors] because our solution is [differentiators].
The sentence is deliberately testable. Every blank is a claim that a later experiment, or a Design Sprint, can confirm or break.
Using the Foundation Sprint Worksheet
The Foundation Sprint Worksheet is a lighter, solo-friendly take on the same thinking. It is not the full 2-day facilitated workshop from Click, and it does not reproduce the 2x2 chart or the lens exercises. What it gives you is four steps you can work through in an hour:
- Problem Definition: one specific problem, with prompts about frequency and intensity.
- Target Customer: who has it, what they do today and what they use instead.
- Value Proposition: written in Geoffrey Moore's positioning format: "For [target customer] who [statement of need], our [product] is a [product category] that [key benefit]. Unlike [primary competitive alternative], our product [statement of primary differentiation]."
- Validation Plan: lists of Key Assumptions, Success Metrics and Validation Experiments, plus prompts asking why your team is positioned to win.
Load Sample fills in a curated freelance marketplace for small businesses, with assumptions like "SMBs are willing to pay 15-20% premium for pre-vetted freelancers" and experiments like "Manual concierge MVP: Hand-match 20 projects to test demand". That sample is a good model of specificity: every assumption has a number, and every experiment can be done in weeks.
Notice how the worksheet maps to the Founding Hypothesis: Target Customer fills [customer], Problem Definition fills [problem], the Value Proposition holds [approach], [competitors] and [differentiators]. Write the sentence out by hand once you have finished the four steps. If you cannot, one of the steps is still vague. The worksheet saves to your browser under foundation-sprint and exports through the Text, Image and PDF buttons.
Common mistakes
- Skipping the Decider. Without one person who has the authority to make the final call on Wednesday, the team votes for the safest compromise and tests something nobody loves.
- Building too much on Thursday. A prototype that takes three days to make has stopped being a prototype. If the tester will not click it, do not build it.
- Recruiting the wrong testers. Five friends of the founder will be polite. Recruit five people who match the target customer, and screen them with a short survey (the User Survey Designer helps).
- Treating the Founding Hypothesis as a slogan. It is a bet. If interviews contradict it, rewrite it rather than defending it.
- Running a Design Sprint on a problem nobody has. If you are unsure the problem is real, start with the Foundation Sprint Worksheet and some idea validation first.
Which sprint to run next week
If you can already name the customer, the problem and why you are different in one sentence, book five days, recruit five testers on Monday, and work through the Design Sprint Checklist. If that sentence does not come easily, spend an afternoon on the Foundation Sprint Worksheet, write your Founding Hypothesis, and then lay out the business around it with a Lean Canvas (our Lean Canvas guide walks through each box). Either way, the goal is the same: find out you are wrong in days, not quarters.