5 important tips for your first design sprint + A great bonus
Congratulations! You decided to run your first design sprint. You may be doing it within your company or you have been hired to run one externally. In both cases, you are justly anxious as you are going to gather stakeholders from different parts of the company and spend 2 days with them in an intense workshop. You are expected to deliver huge value and to innovate and the entire team is counting on you to pull it off.
Here are a few tips we learned in our first few sprints we wished someone would whisper in our ear before we started.
!!! a great bonus at the end of this !!!
Stick to the timeline
You will be tempted to extend the sprint over the 4 days that you’ve originally allocated (or 5 if you plan to do the traditional version). Some of your thoughts will be, “We can spread the first day over 2 days or spread the workshop over a week” — especially if you come from a Design Thinking background, and feel that you need more time to interview people, or know your users more. Don’t listen to your instinct! Trust the process, it works! What will happen is that the team will have more time to second guess themselves and their decisions, and this will drag the process in the wrong direction. Remember one of the key principles of the design sprint — getting started is more important than being right. Its not about being right, its about getting something out there and testing it.
You will also be tempted to allocate more time for prototyping. This will put the prototype at risk of being too wide and less focused, resulting in long and tiresome user testing sessions. The one day time frame focuses your team on the main issues that you want to test, the key questions on the product that really matter.
The most common reason to break the time frame is not being able to find users for testing. This is true when the project is B2B, and the users that you’re looking for are seriously hard to find (like Molecular Biologists, or CEOs). In those cases, it can be hard to gather 5 users for the last day of the sprint. This is, IMO, the only place where it may be worth while breaking the process. There is no question that sticking to the original time schedule is best, but getting real potential users is even more important. The users needs to be right and running the sessions a day or two later, in this specific case, is not detrimental. However, it does come at a cost: One: Feedback is better received and understood when presented as close as possible to the strategic decision. Delaying may make it harder to get alignment on what to do if you decide to run an iteration sprint (second sprint that deals with improving the current prototype based on your findings).
Do not cut corners
The first sprint we ran was for an internal product. We wanted to get the feel of it before we actually sell them to our clients, so we decided to run a number of internal sprints. We are a team of very experienced product designers and have produced hundreds of products over the years with changing methodologies, before starting to work with design sprints. We felt pretty confident about our abilities, and thought it would be right to give the original framework and exercises our own twist.
Thinking about that sprint now, I realize that that was a big mistake. The Sprint book is very detailed and each step was well thought out , and it was tested on hundreds of companies before it was published. Its OK to ad lib or change, but if you really want to learn the craft and make it part of your design culture, you need to deeply understand not only the “hows” but also the “whys” in the process. If you want to break the process, you first have to know it well.
Come prepared
The design sprint is a very tight and intensive event. Time is of the essence and you have to come prepared. Here are a few things that we do and recommend before the sprint starts:
- Understand the politics before you start. Talk to each sprint participant individually before the sprint. Explain what is going to happen, understand her agenda, her concerns and ask her “how would success look like” in her eyes. This will motivate her to cooperate and will get you prepared to deal with their drama and politics.
- Make sure the sprint’s goals and challenge are well defined and agreed on by the decider. Sometimes, its good to run a short strategy and priorities session before the actual sprint. Here’s a complete cookbook we made on how to run one.
Do not waive the user testing… it is not a design sprint without it.
Many of the companies I talk with say “we already do design sprints”. But when I further inquire, they admit that they don’t do the user testing part. Well, it’s not a sprint if you do not have user testing, it’s maybe a well run product strategy workshop, maybe its very good and you gained a lot of insights, but its not a design sprint.
The main aim of doing a design sprint is to verify the market fit. If you do not do that, then you are missing probably the most important reason for going through all this effort.
Feed the team!
One of my favorite Napoleon quotes is that “ An army marches on its stomach.”. If your team is not fed well, they will not be able to carry this effectively. Moreover, they will not want to do this ever again. The sprint is intensive and demanding and one thing you do not want is a hungry team, or one that’s too full to think.
Make sure you’re on top of the food issue. Make sure there are healthy vegetables and fruits available, and when its lunchtime, make sure it’s healthy and light. Give enough breaks so that people can hydrate (water!). At the end of the day, you can pop open a few beers and celebrate your amazing achievements.
I hope you’ve gotten a few tips here before you venture into your first sprint. I hope you have a great time, and don’t worry about screwing up, you will, and that’s part of doing it correctly. You’ll learn more as you go along, and it will soon become second nature.
Best of luck!!
And now, for the promised bonus: A complete FREE step-by-step cookbook for a structured decision making workshop based on the sprint principles. Never failed for me, let me know how it went for you!
