The Design Sprint is a powerful process for answering important questions quickly. Bring the right people together, understand the problem, generate ideas, build a prototype, and put it in front of customers. In a matter of days, a team can learn something that might otherwise take weeks or months to discover.
But over time, I think there's a risk of focusing too much on the Sprint itself and not enough on the reason it exists. The real value of a Design Sprint isn't the schedule. It's the mindset behind it: test your ideas before making a large commitment to them.
Before the building starts
When an organization has a promising idea, the natural instinct is often to start building. A team forms, requirements are written, resources are allocated, and before long there is significant time and money invested in something that hasn't yet been tested with the people it's intended for.
A Design Sprint creates a useful interruption to that pattern. Instead of asking, "How do we build this?" the team first asks, "Is this worth building?" That distinction can save enormous amounts of effort.
The prototype doesn't need to be production-ready. It doesn't need every feature. It only needs to be real enough to put in front of someone and learn from their response. Sometimes the most valuable result of a Sprint is discovering that an idea needs to change.
The schedule is a tool, not a rule
The original Design Sprint process is deliberately structured. The compressed timeline creates focus, momentum, and a sense of urgency that can be difficult to achieve in a normal product development cycle. But I don't think the calendar should become the point.
I've facilitated different kinds of Sprints and innovation workshops, and they haven't all looked the same. Some have been closer to traditional Design Sprints, while others have been more like focused two-day innovation workshops because the participants were struggling with being able to set aside 3-4 consecutive back-to-back days.
The format can change while the underlying principle remains intact. If the goal is to reduce uncertainty before making a significant investment, then the best process is the one that accomplishes that with the least unnecessary effort.
Discover/Create
This is part of the thinking behind my Discover/Create workshop. I've developed it as a streamlined approach to the Design Sprint, built around two focused phases.
Discover is about understanding the problem, the people, the opportunity, and the assumptions that need to be challenged. Create moves into ideation and concept development. Then optionally as an add-on, a prototyping stage with target market interviews.
Rather than trying to fit every organization into a five-day process, the workshop is designed around the specific questions the team needs to answer. The sessions can be run as two focused half-days during any given week, with time between them to reflect, gather information, or do additional work.
The result is still rooted in the spirit of the Design Sprint: bring the right people together, move quickly, make ideas tangible, and learn before committing significant resources.
What's the smallest thing you can test?
Starting lean means resisting the urge to solve the entire problem at once.
If you're considering a new platform, perhaps you don't need to design the entire platform. You might prototype the one interaction that represents the biggest risk. If you're exploring a new service, perhaps you don't need a complete business model. You might put the concept in front of a few potential customers and see how they respond.
If you're considering a new feature, perhaps you don't need to build it. You might create a realistic prototype and watch someone try to use it. The question becomes: What is the smallest thing we can create that will teach us something important? That question can dramatically change the economics of innovation.
