--- title: "Design Sprints in the Real World" url: "https://writing.colivetree.com/3/product/25/design-sprints-in-the-real-world" --- **Design Sprints in the Real World** Originally published Jul 27, 2016 When faced with a complex problem, whether in terms of the idea itself (what), its execution (how) or the organizational or personal challenges you’ll face to make it happen (who), the processes of design thinking and lean help you remove some of those barriers through cycles of validated learning. From clearly understanding the problem to finding cheap ways of testing and validating your assumptions, you can magnify your chances of success before writing a single line of code.This is a powerful value proposition and, thankfully, many in the software industry are taking it in and applying it to their projects. It is incredibly important to iterate on your assumptions and increase their exposure to potential customers. This time around, faced with a complex problem with great potential, my team and I turned to one of the most widely known validation methodologies out there — the Design Sprint — to put our assumptions to the test. The Design Sprint is a famous 5-day methodology to go from idea to real world testing, validating your hypotheses and your product-market fit. The book is based on the current Google Ventures approach, but the roots of the methodology go back to IDEO and the Design Thinking principles. Before we go any further — I highly recommend reading the book. It's a great back-up for when you’re running your own design sprint, wondering what to do at any stage. As my career as progressed I've had many instances where getting to a testable prototype that gets people excited about where we're going is valuable. When I need to get **there**, I often think back to the Design Sprint and pick, choose and remix the bits that will help me in that particular context. Here's how using it went for one of my teams: **The good** **#1) SPEED — The Design Sprint did help us accelerate to critical feedback in 5 days.** We had an idea about a complex solution that would help users plan their travel. Taking it to the MVP level would probably take us a couple of months. Iterating on that MVP to get it to a point where it could be out of a beta would definitely take us a couple more. If we had just done that, we would have failed. **#2) VACCINATING US AGAINST FEATURITIS** **— We boiled the product down to its bare essentials, ensuring we would capture just enough to make it loveable.** This bigger idea involved a lot of smaller assumptions about how people would interact with the feature, what would help them understand it, invest their precious time on it and finally tell their friends how great it is. We discussed these assumptions and figured we couldn’t live without supporting them in our design. We were wrong and the methodology told us that. **#3) ALIGNMENT — Sitting people down and talking about the problem will align them around its fundamentals. ** Implementing this idea would involve people from different teams and we would need support from a bunch of others who weren’t as invested in it as we were. It was hard enough to find 5 days to sit all 7 of us down together. We had tried going over it before in meetings and ended up with 3 completely divergent perspectives of the problem. **#4) CREATIVITY — You’ll have great “failed” ideas that you can reuse in other parts of your product or business.** When you’re solving a big problem and you get a bunch of smart people in the same room, they will all come up with great solutions. They will share unique perspectives and attack the same problem in singular ways. Most of these will not stand the test of the 3rd day, when you need to make hard decisions. That’s OK, you might be able to use them elsewhere and stimulate creative thinking about different parts of your product. **#5) Insight — Your “Experts” will offer unique takes on the problem before you even sketch the first prototype. ** Your “Ask the Experts” sessions are unbelievably helpful if done right. You’ll bring in people from different parts of the business who might not usually be as involved in your everyday product discussions. Aim for diversity: We brought in Commercial/Sales people, User Satisfaction, Marketeers and even our CEO. We also brought in other Designers and Product Managers who had tried solving an analogous problem in a unique way. Their insight and domain knowledge is critical to a better product. You’ll get it before you even start coding. **The bad/The ugly** **The Sprint won’t tell you exactly what to do (or not to do)** Although the Design Sprint process does a great job at trying to avoiding groupthink and design by committee it does not entirely avoid it — it couldn’t, you’re all still human. Sometimes, what you can come up with in a day is just not enough. Some users will not have enough context or be able to abstract from the fact that they’re dealing with a prototype. That’s perfectly natural and you should understand that when interpreting their reactions.I would even argue that running a Design Sprint won’t stop you from launching a product no-one wants (unless your idea is absolutely terrible). It will definitely not guarantee your feature/MVP/experiment will be successful if you follow the process and your users sessions go well — remember the context — they’re not using it at their own pace (or paying for it!) **Your vision matters!** You’ll get to the end of these 5 days with a much clearer picture of the problem and the possible solution space. Your team will know what they’re talking about, understand the problem in depth and be aware of the pitfalls. A design sprint will save you development hours, avoid lots of unnecessary meetings and prevent you from making tons of mistakes. But… Your vision still matters! It counts if you’re solving a real problem and you’re confident it will make people’s lives better. The Sprint will ensure you’re on the right track and confront you with varying degrees of excitement about it, but won’t always be magical. You will fail to impress some people and, what’s more, parts of your idea will absolutely suck: That’s OK! When that happens, remember the principles of design thinking. Get back to the drawing board and think again, prototype again, test again. In the end, you might have failed fast — time to pivot? — or ended up with something 10x better because you've done the work to put some shape of it in front of people you thought would care. Isn’t that how great products are born?