I’m Jake Knapp. I created the design sprint at Google in 2010, ran over 100 sprints with startups at Google Ventures from 2012–2017, and then wrote the book Sprint about the process. Today, I’m working on writing more books and teaching people how to run their own sprints.
I recently facilitated DesignBetter.Co workshops in Seattle and Los Angeles doing just that. The following post was inspired from these experiences. Want to join me next time? Check out the upcoming cities and topics.
1. Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days came out a couple years ago. Has anything changed?
By the time the book came out, I’d led more than 100 sprints, and the process was very stable. So, what’s in the book absolutely works—but a few steps have benefited from improved techniques. With these tweaks, the sprint process is even better today.
Some of those tweaks are things we originally started doing at Google Ventures, but decided not to include in the book for complexity, or because we came up with them after it was published.
A few of these optimizations were discovered by people running their own design sprints, like AJ&Smart in Berlin, Design Sprint in Switzerland, and AQ in Tokyo and Paris. Some of those are really good additions to product design sprints—and I totally wish I’d thought of them!
Again, the process in the book absolutely works, but there are some excellent “power ups” that people are discovering every day, like Note-N-Map and Storyboarding 2.0 (you can find those and my other favorites in the book.)
2. Are design sprints overhyped?
Ah, this is a good question!
Erika Hall, one of the folks in design I admire most, wrote a post called, “Design Sprints are Snake Oil.” I think her argument is a fair one; some people have used design sprints to be a solution for everything.
Read more: Bringing design sprints inside your company
To be honest, that was sort of exciting to me at first. Just imagine, there may be places where people ask for design sprints all the time! When I stop being excited about the idea, I totally understood the “overhype” concern.
“You don’t want people asking for design sprints every week instead of doing the hard, detailed work that comes before and after. You don’t want people to assume that design sprints are everything.”
The design sprint is a tool for a very specific situation:
- You have a big project or big problem to solve
- You’re just starting out
- You don’t have the answer
- It’s going to cost a lot of time or money
I would say that as of 2018, most people are not doing design sprints in those situations. Most people are raveled up in old-fashioned office behaviors: endless arguments, decision churn, extroverts dominating group brainstorms, following hunches and wasting months or years. Until that stops, I don’t think design sprints are overhyped. But I hope to get there!
3. Do design sprints work in big companies?
Yes, but it can take time. My two favorite examples are Google and LEGO.
Google is sort of an obvious one—it’s where I created the design sprint in the first place, but I think it’s worth noting that Google is a really big company and the process has absolutely stuck. Today there are hundreds of people trained to facilitate design sprints, they’re running an annual design sprint conference, and sprints are happening all the time.
LEGO is also a great example because, well, it’s LEGO! It’s not just a great example because it’s a cool product everyone loves—LEGO is also a very big, old, and in many ways, traditional company. They manufacture products and ship them around the world, they have advertising and marketing and everything, right down to box design, in house.
Still, they’ve made a dramatic transformation in the last year or so to scale design sprints. This podcast interview with one of the leaders who brought the process to LEGO is pretty cool (also he has an amazing voice).
4. Can my team do a sprint in less than 5 days?
I always recommend that people follow the 5-day recipe the first time they do a sprint. After that, you can condense the sprint to four days by basically smooshing Map, Sketch, and Decide—which are normally three days—into two days.
Below four days is very challenging. I’ve heard about many teams doing all five sprint steps in just three days, but that requires very long hours and that’s not my vision for sprints. It’s not a great way to work. You can’t do your best thinking, it’s not sustainable, and next time you propose a sprint, people are going to say, “Ugh, that was miserable.”
Read more: When a design sprint isn’t the answer
The other way people condense sprints is by cutting off the prototyping and/or the testing. If you do this, you’ve missed the whole point of the sprint. You might end up with an idea that seemed smart, but isn’t actually any good.
5. Why do you teach workshops?
I started doing it sort of by accident—I was invited to teach a workshop in Italy. I’d just left my job at Google, and I thought, “Hey, I can go teach a workshop in Italy if I want to! Heck yeah I’ll do it!”
So I did, and it was really fun. Beyond being in Italy, the workshop itself was so much fun for me. It helped me realize it was a great way to share the ideas and principles in the design sprint that goes beyond what’s in the book, or what I can communicate in a video or blog post or even a talk.
In a workshop, I can simulate what it’s like to be part of a real sprint. I can help people build muscle memory for their first go, or help them level up if they’re already experienced. All of those extras, all the improvements and the things that aren’t in the book that I mentioned before—well, I can share those, too, as well as nuances, ways to handle difficult situations, ways to talk about the methods, and on and on.
You can do a lot in person that’s hard to do on paper.
All of that is great, and it makes sense, and of course that’s the tangible reason to go to a workshop or teach a workshop.
There’s also an amazing sense of community and energy in the sprints themselves. That sounds a little hippy-dippy, but if you come to a workshop, you’ll know what I mean!
More design sprints posts you’ll like:
by Jake Knapp
Jake spent 10 years at Google and Google Ventures, where he created the Design Sprint process. He has since run it over 150 times with companies like Nest, Slack, 23andMe, and Flatiron Health. Today, teams around the world (including the British Museum and the United Nations) use design sprints to solve big problems and test new ideas. Previously, Jake helped build products like Gmail, Google Hangouts, and Microsoft Encarta. He is currently among the world’s tallest designers.
