A brief history of Design Sprints: where they came from, and why they still matter
Design Sprints are now a familiar tool in product, strategy, and innovation circles. They’re often described as a fast way to make decisions, test ideas, or unblock teams. But the Sprint itself didn’t appear fully formed. It’s the result of decades of thinking about how teams learn, decide, and reduce risk under uncertainty.
Understanding that history helps explain both why Sprints work — and why they’ve evolved beyond their original five-day format.
The foundations: design thinking and rapid learning
The intellectual roots of Design Sprints lie in design thinking, a discipline shaped in the late 20th century by firms such as IDEO and academic institutions like Stanford d.school.
Design thinking reframed problem-solving around:
a deep understanding of users,
rapid exploration of alternatives,
and learning through making, rather than debating.
Influential thinkers such as Herbert Simon had already argued that design was fundamentally about navigating ill-defined problems under constraints. Later, IDEO popularised practical methods — ethnography, prototyping, and iterative testing — that made this approach accessible to teams well beyond traditional design roles.
At the same time, software development was undergoing its own shift. Agile and Lean methods emphasised small bets, fast feedback, and learning cycles over long-range prediction. Eric Ries’ The Lean Startup crystallised this mindset for startups, but its influence quickly spread into larger organisations.
The conditions were set: teams needed a way to combine design thinking’s exploration with Agile’s speed.
Early experiments at Google
The immediate precursor to the Design Sprint emerged inside Google in the early 2010s. Product teams there were struggling with a familiar problem: too many ideas, too many opinions, and too much time spent debating before anything concrete happened.
Designer Jake Knapp began experimenting with compressed workshops that forced teams to:
agree on the problem,
explore multiple solutions independently,
make a clear decision,
and test assumptions quickly.
These experiments were refined through repeated use on real Google products. Crucially, they weren’t theoretical exercises; they were pragmatic responses to organisational drag.
When Knapp later joined GV (formerly Google Ventures), the Sprint was stress-tested further. GV needed a way to help portfolio companies reduce risk quickly, often before committing significant engineering effort or capital. The Sprint became a repeatable intervention for exactly that purpose.
The canonical five-day Design Sprint
In 2016, Knapp formalised the method in Sprint, co-authored with John Zeratsky and Braden Kowitz. The book described the now-familiar five-day structure:
Understand — align on the problem, users, and constraints
Sketch — generate a wide range of possible solutions
Decide — converge on one direction
Prototype — create a realistic façade
Test — learn from real users
This structure mattered because it balanced divergence and convergence deliberately. It created space for exploration early on, then imposed clarity and commitment later.
Just as importantly, the Sprint was designed to short-circuit common organisational failure modes:
endless meetings without decisions,
outcomes driven by seniority rather than evidence,
and analysis that never quite turns into action.
Adaptation and evolution
As Design Sprints spread beyond startups into enterprises, consultancies, and the public sector, teams began to adapt them.
Some of this was practical. Not every organisation could spare a full cross-functional team for five consecutive days. But deeper changes were also happening. Many teams weren’t trying to validate a single product idea — they were grappling with strategic questions, organisational complexity, or competing priorities.
This led to:
shorter Sprints (two- or three-day variants),
remote and asynchronous adaptations,
and Sprints focused on strategy, service design, or internal systems rather than customer-facing products.
Over time, the Sprint stopped being just a product-design tool and became a more general framework for structured decision-making.
From Design Sprints to Spikes
That evolution is the context in which Spikes sit on this website.
Spikes keep the core principles that made Design Sprints effective — structured exploration, explicit trade-offs, and time-boxed decision-making — but adapt them to the realities most leadership teams now face. They are shorter, more flexible, and designed to tackle strategic and organisational questions just as often as product ones.
Where the original Design Sprint was optimised for prototyping and user testing, Spikes are optimised for clarity: helping small groups of decision-makers align, choose, and move forward with confidence, without the overhead of a full five-day process.
In that sense, Spikes aren’t a rejection of Design Sprints. They’re what happens when a good idea keeps evolving to meet the problems it was always trying to solve.
Further reading & references
If you’d like to go deeper into the thinking behind Design Sprints — and how they connect to wider product, design, and decision-making practice — the sources below are a good place to start.
Design Sprints (primary sources)
Sprint — Jake Knapp, John Zeratsky & Braden Kowitz
The definitive account of the five-day Design Sprint, including its origins at Google and GV.
GV — Design Sprint resources
Case studies and practical adaptations developed through real startup engagements.
Jake Knapp — talks and essays
Useful for understanding the rationale behind the Sprint structure, not just the mechanics.
Design thinking foundations
IDEO — Design Thinking field guides
Foundational material on human-centred design, prototyping, and learning through making.
Stanford d.school — teaching resources
Clear explanations of divergence, convergence, and structured creativity.
Herbert Simon, The Sciences of the Artificial
A classic text on problem-solving and decision-making in complex systems.
Lean, Agile, and rapid learning
The Lean Startup — Eric Ries
Introduced the idea of fast feedback loops and learning under uncertainty.
Lean UX — Jeff Gothelf & Josh Seiden
Bridges Agile delivery and design thinking, with a strong focus on outcomes over outputs.
Decision-making and organisational clarity
Thinking, Fast and Slow — Daniel Kahneman
Explores cognitive bias — one of the challenges Sprints were explicitly designed to counter.
Decisive — Chip & Dan Heath
A practical look at structured decision-making, closely aligned with Sprint principles.
