Join 31,816 readers for design news, cool links, and updates from Jake & JZ every... once in a while.
Design Sprints are powerful recipes that produce impactful results, but they’re not for everyone or every type of project.
I’ve had people tell me about a successful “sprint” they ran, where they removed the Prototype and Test days, shortened the Map and Sketch phases to two hours, and told everyone it was a hit. Hey man, that’s not a Design Sprint — that’s just an organized and efficient meeting!
Don’t get me wrong, it’s not about hitting a certain number of hours or rigidly following one process. But if you want to know if the Design Sprint process — a high-value, time-saving, product-centered design methodology — is right for your team, here are the three things I always check for before asking a client to invest 36 hours of time and energy in a full five-day Design Sprint.
“How do I know if it’s the right time to run a Design Sprint for my project?”
Last summer I consulted with a university that was trying to figure out the future of their seminary program. We knew there were a few big ideas to try; lower cost, easier access to educational material, and a stronger global community, but there wasn’t one obvious solution. This was an ideal Design Sprint because one of the key things that makes a Design Sprint worthwhile is the opportunity to come up with dozens of solutions and not be limited by a narrow scope. We came up with more than a dozen different ideas, which wouldn’t have happened if there was only one obvious solution (In cases where there is an obvious solution, we often have less unique ideas and everyone’s solutions looks similar). In another sprint with a life science non-profit, we collectively came up with more than 30 ideas in two days. 30 ideas!
If you, your team lead, or CEO has a clear idea of the solution, then you should just prototype and test that solution. You don’t need the commitment and research of the first three days of a Design Sprint. Plus, it’s likely that if the Decider already has a preconceived idea of the solution, they will skew the collaborative voting in their favor and cloud the potential idea innovation.
Running a Design Sprint when there’s no obvious solution is also really good for the early days of defining a new product. You may not even understand the problem yet! An old-school industrial company I worked with makes air and oil filters, primarily for cars. Thanks to electric cars, they realized they need to find how to use the technology they already have (air and oil filters) in a new industry. This is another great place to use a Design Sprint because they are working to understand new customers in a whole new problem space. How can this existing technology be applied in new ways? Who is our best customer? How do we differentiate from competitors? And then, does anyone want this? Design Sprints can help answer those kind of questions.
A Design Sprint is effective when the problem is meaningful enough and challenging enough that employees from different groups need to work together to find a solution. It’s not just a marketing challenge, or an engineering challenge, but something bigger that requires experts from different areas to actually work together. When the team is made up of just designers, that’s probably a design problem. If it can be tackled with just marketers, that more of a marketing problem. Those types of problems can likely be solved by using design thinking techniques, but probably don’t need a full Design Sprint. When the problem needs a cross-functional team to solve it, you know that you’re investing in solving an unknown that’s big and meaningful.
One of the best things about a Design Sprint is how five days in the same room bridges the boundaries between really different teams that don’t usually work together to achieve product decisions within a timeline that doesn’t normally happen. I’ve seen teams who can’t even agree on what the problem is on Day 1 end up agreeing on the solution by Day 3. The problem mapping, idea generation, and single-vision of a Design Sprint allows the team to build a deep, working relationship in a way that a series of meetings never can.
You know what’s crazy? I’ve had C-level execs thank me at the end of the week for leading a design sprint at their company for one reason: decisions were made. I recently consulted with a large, public engineering company. We needed input from user research, user experience, hardware engineering, software engineering, sales, and executives to design a new process at their company. On the first day alone, there were three or four different ideas about the project was, and by the end of the first day everyone not only agreed on the scope of the project but they saw the value of prototyping a solution as soon as possible. The Design Sprint process not only makes room, but is best suited for cross-functional teams to come together, speak the same language, and get ‘er done.
Asking for five days of someone’s work week is a big ask. So it’s important that the problem you’re tackling is big enough that it’s worth investing five days of your cross-collaborative team to solve. When I led a Design Sprint for a startup pitching a product to hedge fund managers, the team was able to close a 7-figure contract based on the prototype we put together. Those five days with the head of engineering, head of data science, head of sales, and CEO led to exponential returns. Going into the Design Sprint, everyone agreed this was worth their time because it was literally worth more than $1M to the company if the project was successful.
Time is our most valuable asset. It’s no surprise that aligning schedules and convincing people that it’s worth 36 hours of their time is one of the most difficult tasks in organizing a Design Sprint. However, it’s also the best part of a Design Sprint. If you can convince someone to give you 36 hours of their time, it’s probably a problem worth tackling.
OK, so it’s a lot of time, but the other thing people are thinking is, “Do we really need to change the way we currently work to solve this problem?” and “Why can’t we do it the way we’ve always done it?” Well, it’s simple. When you do things the way you’ve always done them, you end up with the same results.
A Design Sprint is a fundamentally different approach to problem-solving. The way people work today is setup to make incremental improvements in projects, to maintain the way things are going. We send off one email at a time, make small changes to get meager feedback, and then wonder why we aren’t seeing bigger strides of improvement. This is fine for companies with already successful products that just need to keep doing what they’re doing, but not for companies and teams that need to constantly be innovating. A Design Sprint is a process for generating deep, uninterrupted work which is where big innovation comes from! Make sure your problem deserves that kind of commitment, and then help your team commit.
If your challenge meets these three requirements then you’re in a fantastic, exciting place, and ready to kickoff a Design Sprint.
