A design sprint squeezes months of back-and-forth into five days. LEGO used it 150 times in a single year to fix a creative process that had been stuck for a decade. The method itself is simple enough to explain in a page, even if the discipline to actually run one is harder. If your company is trying to test a big idea before spending months building it, this is worth understanding.
The story behind it
A few years ago, LEGO's internal creative agency had been running the same way for about a decade, and it wasn't keeping up. Rather than easing into change, the person leading the agency did something drastic: production stopped for two months in 2017, from April to June, and a large part of the internal agency put their regular work aside to run design sprints instead, as the person who led the rollout later described it.
The first week had ten sprints running side by side. By the end of the two-month pause they'd run about sixty. Within a year, they'd completed over 150. LEGO built the method permanently into how its internal agency worked, using it to restructure how the whole team operated. That's an extreme version of the method. Most companies never need to run it at that scale. But the reason LEGO went this far is worth sitting with: testing an idea properly, before building it, is usually faster and cheaper than finding out it doesn't work after months of development.
What a design sprint actually is
A design sprint is a way of testing a new idea in a matter of days instead of months, using a small team and a structured process to define the goal, sketch solutions, and test them with real people before any real development starts. The method was created by Jake Knapp during his time at Google, and later published in the book "Sprint," written together with two colleagues from Google Ventures.
The point isn't to build the actual product in five days. It's to build just enough of it, a clickable prototype, a mockup, a rough version, to put in front of real people and see how they react. You find out if the idea works before you've spent the time and money building the real thing.
How the five days usually break down
The exact structure varies a bit depending on who's running it, but the core shape looks like this:
Day 1, understand the problem. The team gets aligned on what they're actually trying to solve, and picks one specific piece of it to focus on for the week.
Day 2, sketch solutions. Everyone works alone at first, sketching out their own ideas, rather than jumping straight into a group brainstorm that tends to favor whoever talks the loudest.
Day 3, decide. The team reviews all the sketches and picks the strongest ideas to move forward with, without endless debate.
Day 4, build a prototype. Not real, working software. Just enough of a mockup to look and feel real when someone tries to use it. This is the same rapid prototyping principle behind a lot of good product decisions: build the smallest thing that lets you test the idea, not the whole thing.
Day 5, test it with real people. The team watches a handful of actual users try the prototype and reacts to what they see, rather than what they hoped would happen.
By Friday afternoon, you know whether the idea holds up, before writing a single line of production code.
When this makes sense for a growing company
A design sprint is worth running when you're about to make a decision that would be expensive to get wrong. A new feature that would take months to build. A new product direction you're not fully sure about. A redesign that touches something customers already rely on. In all of these, spending five days finding out if the idea actually works is cheap insurance against months of building the wrong thing, and it's the same thinking behind avoiding common product-market fit mistakes before you commit real budget to a direction.
When it's probably overkill
Not every decision needs five days and a room full of people. If the fix is small, or the team already knows the answer, running a full sprint just adds ceremony without adding much insight. It's also not the right tool if the real problem is that nobody has agreed yet on what the business is even trying to achieve. That's a different kind of conversation, one about goals and priorities, not about testing a specific idea.
Design sprint vs a Discovery Workshop
They're not the same thing, even though the logic is similar. A design sprint usually answers one narrow question: will this specific feature or flow work, tested with a prototype and a handful of users. A Discovery Workshop answers a bigger one: what should we actually be building, and in what order, before any of that gets specced out. Think of a design sprint as testing one brick, and a Discovery Workshop as figuring out what you're building with all of them.
Where this fits with how we work
Both exist to answer the expensive question before you've spent the money finding out the hard way. If you've got an idea you're not fully sure about, and building it outright feels like a risk you'd rather not take blind, a Discovery Workshop is built for exactly that conversation.
