Sprint
by Jake Knapp, John Zeratsky & Braden Kowitz · 2016
Google Ventures' shortcut for answering 'will this idea work?' in five days instead of five months.
Worth reading? Sprint and Eric Ries's The Lean Startup solve the same underlying problem -- stop building things nobody's validated -- but at different altitudes. Lean Startup is a philosophy (build-measure-learn, minimum viable product) that you have to translate into your own process. Sprint is the process already built for you: a literal Monday-to-Friday schedule with named steps, roles, and exercises. If Lean Startup left you convinced but unsure what to actually schedule on your calendar, Sprint is the answer. Skip it if you're a solo founder or a very small team -- the whole method assumes a room with a decider, a facilitator, and several people with different expertise, and it doesn't translate well to one or two people iterating alone. For a team that keeps debating a new feature for weeks before testing it on a single real customer, the five-day structure is a genuinely useful forcing function.
| Full Title | Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days |
|---|---|
| Author | Jake Knapp, John Zeratsky & Braden Kowitz |
| Published | 2016 |
| Publisher | Simon & Schuster |
| Category | Business & Money |
| Favorite quote | “A design sprint is a 'greatest hits' of business strategy, innovation, behavior science, and design thinking, packaged into a battle-tested process.” |
The Verdict
Jake Knapp built the sprint process at Google Ventures by watching which parts of product development actually moved fast and which parts were just meetings dressed up as progress. The result is a genuinely usable five-day schedule, not another framework you have to translate into your own process before it’s useful.
your team burns weeks debating a new feature or product before building anything real
you're a solo founder or a two-person team -- the process assumes a cross-functional group in a room
Book Summary
The book's core insight is that most teams solve big product decisions by talking about them endlessly instead of testing them fast, and that a realistic prototype tested with five real users tells you more in five days than months of internal debate. The sprint is a fixed structure to force that: Monday you map the problem and pick a target, Tuesday you sketch solutions individually (not in a group brainstorm), Wednesday you decide which solution to build via structured critique and a single Decider, Thursday you build a realistic-looking facade (not a real product), and Friday you test it with five customers.
A few specific mechanisms do most of the work. Individual sketching before group discussion (including "Crazy 8s," where everyone sketches eight variations in eight minutes) prevents groupthink and the loudest voice in the room from dominating too early. A single named Decider breaks ties instead of letting consensus stall the sprint. And the Friday prototype is explicitly disposable -- built only well enough to answer the sprint's specific question, not to ship.
The underlying philosophy is that speed and realism beat perfect certainty. You're not trying to build the right answer on the first try; you're trying to get a real, if rough, answer to a specific question in the shortest time that still counts as a valid test.
Top 10 Lessons from Sprint
- A five-day structure (Map, Sketch, Decide, Prototype, Test) forces a decision instead of endless debate.
- Sketch solutions alone before discussing as a group -- it prevents groupthink and the loudest voice winning.
- Crazy 8s: sketch eight variations of an idea in eight minutes to force quantity over premature polish.
- A single named Decider breaks ties -- consensus-seeking is what kills most product debates.
- The prototype only needs to look real enough to test one specific question, not to actually work.
- Testing with five real customers on Friday beats another week of internal opinion.
- A clear sprint goal and a specific target customer keep the week from sprawling.
- 'How Might We' notes turn vague complaints into testable design questions.
- Silent, structured critique (not open discussion) gets better ideas heard than free-for-all brainstorming.
- Speed and a rough real answer beat a slow path toward a perfect one.
Top 2 Quotes from Sprint
"A design sprint is a 'greatest hits' of business strategy, innovation, behavior science, and design thinking, packaged into a battle-tested process."
Jake Knapp, John Zeratsky & Braden Kowitz, Sprint
"Prototypes aren't products. They're designed to answer a question, and once the question is answered, the prototype has done its job."
Jake Knapp, John Zeratsky & Braden Kowitz, Sprint
Frequently Asked Questions
Is Sprint worth reading?
Yes, if your team debates new features or products for weeks before testing anything real -- the five-day structure is a genuine forcing function. Skip it if you're a solo founder or a two-person team; the method assumes a cross-functional group in a room.
What is the main idea of Sprint?
Most product decisions get slowed down by endless internal debate. A structured five-day process -- map, sketch, decide, prototype, test with five real customers -- gets a real answer faster than months of meetings.
What happens each day of a design sprint?
Monday: map the problem and pick a target. Tuesday: sketch solutions individually. Wednesday: decide which to build, with one Decider breaking ties. Thursday: build a realistic prototype facade. Friday: test it with five real customers.
Is Sprint better than The Lean Startup?
They complement each other more than compete. The Lean Startup gives you the philosophy (build-measure-learn); Sprint gives you the literal calendar and exercises to run that philosophy in one week.
Ready to read it?
Get Sprint on Amazon
