Sprint: How to Solve Big Problems and Test New Ideas in Just Five Daysby Published 08 Mar 2016
|Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days.pdf|
From three design partners at Google Ventures, a unique five-day process for solving tough problems using design, prototyping, and testing ideas with customers.
The startups that Google Ventures invest in face big questions every day: Where’s the most important place to focus your effort, and how do you start? What will your ideas look like in real life? How many meetings and discussions does it take before you can be sure you have the right solution to a problem? Business owners and investors want their companies and the people who lead them to be equipped to answer these questions—and quickly. And now there’s a sure-fire way to solve their problems and test solutions: the sprint.
While working at Google, designer Jake Knapp created a unique problem-solving method that he coined a “design sprint”—a five-day process to help companies answer crucial questions. His ‘sprints’ were used on everything from Google Search to Chrome to Google X. When he moved to Google Ventures, he joined Braden Kowitz and John Zeratsky, both designers and partners there who worked on products like YouTube and Gmail. Together Knapp, Zeratsky, and Kowitz have run over 100 sprints with their portfolio companies. They’ve seen firsthand how sprints can overcome challenges in all kinds of companies: healthcare, fitness, finance, retailers, and more.
A practical guide to answering business questions, Sprint is a book for groups of any size, from small startups to Fortune 100s, from teachers to non-profits. It’s for anyone with a big opportunity, problem, or idea who needs to get answers today.
"Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days" Reviews
In January 2018 I will be taking part in a Design Sprint, and I've been reading the book to dig into the details. Only then I will feel I have all the information needed to rate the book since it is basically a practical guide to put the methodology in practice.
Although there is mostly step by step instructions (well explained), there are also some good bits and pieces that are valuable on their own. One of my favorite was a chapter on prototyping where they talked about what they refer to as "The Prototype Mindset"; after listening to the chapter I ran a Google search and found this post by Eric Ries with an excerpt of precisely that part, so go ahead and read it yourself: http://bit.ly/2BqC6Vu
I will come back to this review after running the sprint and share here my perception of the book after putting into practice.
Update: After my first design sprint! (January 27, 2018)
Last week (Jan 15 to Jan 19) I finally took part of my first design sprint and I have to say: it was worth it!
The initial promise was real and immediately perceived by all of us who took part in it, but the real value to the end users will come after we move forward with what just started, so the true test lies ahead. However, I can already feel that the framework helped us accelerate at a pace that would have been otherwise a thing of months.
The things that I believe made the framework work are all described in the book, but I see them in a whole new differently light after having put them into practice. Here’s a summary of the ones that stuck out to me and I hope I can convey their importance here even if you read this without having had yet the opportunity of experiencing a design sprint yourself yet:
We chose each role very carefully. We considered them keeping in mind the fuzzy problem at hand and what we expected to do after the sprint if we succeeded in identifying the right goal and questions to answer. We were a total of 6: a facilitator, a decider, one designer, one developer, one product manager and one subject matter expert. We were a group of people that new each other a bit, but not too much, so we respected each others area, yet were free of biases that can build from knowing someone too well. What I mean is, we never knew exactly how someone would act or answer to something, and that kept us interested and open to what they were bringing to the table. Everyone was a true expert in their area, and had the right skills to perform each of the important tasks well: facilitating, designing, interviewing, etc.
We all were truly interested in solving the problem, and had our own ideas, but we were all open enough to be surprised by whatever would unfold during the 5 days.
The framework is full of techniques that we might have heard of before but tend to forget to apply in our day to day work. If we did, we would probably be more productive and more successful than we usually are. One very clear example of this: mapping the problem and talking to experts. A diagram says more than a thousand words. Having a visual representation of how we understood the problem helped us see were we saw things differently in a non-abstract way. Relying on the experts observations to modify the picture until we were all satisfied, rather than turning to ourselves in the group also helped us avoid endless and frustrating discussions.
Doing real tangible work, and doing it all each individually, but then putting it all in a common bunch. The fact that we all, regardless of our role or skills, got to sketch and contribute directly to the solution was both refreshing and motivating. For those who don’t get to do it in their day-to-day work, it was exciting. For those who do, it was challenging and positively surprising to see how people in other roles also had ideas that made sense and contributed to the solution.
Talking to real users while things were fresh: this was very reassuring. After four days of such intense work, being able to see in the same week the reactions and feedback of real users made the investment of the previous four days pay off. Even if we got things wrong, we could learn quickly. If we got it right, we felt hope.
There are another bunch of things that make this really useful. One thing to clarify: we followed almost all the book step by step, with some few small exceptions. Details matter (materials, location, considerations to choose the right people, planning ahead what would happen after).
It paid off, but as I said above, we still have work ahead of us to see the real results. But I would recommend to try it: if you have a complex, fuzzy problem, and you have the people to spend 5 days working together, fully focused on it, give it a go!
My company (Lucidsoftware) was actually able to get the book early (being backed by Google Ventures). We had the chance to read it, and my team actually put the process to the test. It really helped us get a better sense of direction and focus for the future, while saving us so much time. I think we would all recommend it. If you'd like a deeper review of what happened, check out our post about it: What we learned running our own google ventures sprint - https://www.lucidpress.com/blog/2016/...
Tohle se četlo samo. Krok za krokem velmi poutavě vysvětleno jak přivést nápady ke zdárnému prototypu. Přijít s nápadem není zas tak těžké. Obtížná je jeho realizace. A právě tato kniha je dobrým začátkem. Postupy zde popsané pomohou včas odchytit slepé uličky. Pokud stojíte před výzvou realizovat zcela nový jakýkoliv produkt nebo službu doporučuji začít Sprintem popsaným v této knize.
Kniha mimo jiné obsahuje příběhy firem jako jsou Slack a Medium.
Being a bit of a process geek, I was excited to read Jake Knapp's new book, Sprint, which covers the refined innovation approach that is used at Google Ventures. I feel that this book is a must read for executives, digital product owners, as well as designers/developers (and I would rarely categorize one book as good for all of those demographics).
One of the great things about this book is that it takes some of the core aspects of agile/lean methodology but boils them into a pragmatic and useful framework. Focusing on a smaller autonomous team with clear objectives and small batch sizes sounds like a framework for an agile development team, but in this case those concepts are utilized for rapid focused innovation.
The examples covered in this book are also excellent. In so many books, the examples are somewhat bland and not directly applicable to the reader. However, that was not the case here. Jake did an amazing job helping you understand the challenges that these organizations were facing. Many of these organizations were ones that I heard of or dealt with directly. Applicable examples are essential in a book like this.
If there is one thing lacking, I would say that is a bit unfortunate that this book doesn't go more into how to take some of the concepts and bake them into a sustainable culture. The one week Sprint approach is an amazing framework, but many of these concepts don't have to die when that week is over. It would have been ideal to hear more about mixing the rapid one week iteration sprint with a sustainable approach for ongoing lean development. However, even with that, I still give this book five stars.
1. The book gives great advice on structuring the team when executing these rapid innovation sprints. Jake lays out a lot of good techniques here including always having the decider in the room as well as the troublemaker.
"And if your Decider doesn't believe the sprint will be worthwhile? If she won't even stop for a cameo? Hold up! That's a giant red flag. You might have the wrong project. Take your time, talk with the Decider, and figure out which big challenge would be better." (p. 32)
2. Another benefit was seeing the activities that are undertaken during this sprint. For example, the process of creating a customer-centric map (in Chapter 5) to illustrate the key actors and story lines is particularly useful in helping teams break down the overall complexity. In addition, simple exercises like the How Might We exercise (Chapter 6) are common tools that can be used outside of the bounds of the innovation sprint.
3. Allowing participants in the sprint to maximize both group brainstorming as well as individual time for coming up with a solution was great. Some exercises like the Crazy 8's (in Chapter 9) are helpful at providing rapid iterations in a short period of time. The techniques presented that maintained the momentum of the sprint and minimized unnecessary discussion were also solid gold.
"Each person believed his or her own idea could work. And each person could have spent an hour explaining why. But if we had to spend an hour discussing each idea, the whole day could have gone by without any clear conclusion."
4. One aspect that I loved was the focus on testing with real target users at the end of the week. There is a good amount of knowledge on how to best perform user interviews (Chapter 15) that will be immensely helpful if the concept is new to you. The only site that goes with the book also provides a video of one of the interviews taking place.
"In Friday's test, customer reactions are solid gold, but their feedback is worth pennies on the dollar." (p. 169-170)
Even if you never implement this rigid one week innovation sprint, the techniques included in the book can be applied across a wide variety of scenarios. However, I think many organizations will be spurred to try the one week framework to solve a complex issue after reading through this book. This book does an absolutely amazing job of spurring action quickly and providing insightful case studies. I think you will love it.
Creating and evaluating new product features is my world.
This book has a double grade:
If you know nothing about how to limit the scope of your product and validate it, this book is for you. It is a decent all-in-one plan to test a big idea in a week. The methodology is sound and fits in with decades of research regard product development and design, as well as more recent work in usability and "lean" modes of development.
The book has judicious guidance on getting the right team together, getting focus, sketching, picking ideas to test, building a prototype, and, finally, testing with users and making decisions about the product idea. Yay! Awesome!
If you know anything about product development and idea testing/validation, this is an incredibly annoying book. For those of you who know the field, I'd give this two or even just one stars.
Why? Just about every idea in this book is well known in product land. But the authors cite no works (except Jakob Nielsen, 'cos they wanted to use a graph from one of his publications), and there's no bibliography (they direct the reader to their web site, which is nice, but, folks, this is a book. And in a book you provide more resources through citations and a bibliography).
If you read this book naively, you would think that the great gods of Google Ventures somehow thought this up themselves.
There is a very big reason to belabor the long history of work in this area: It's because it's hard. Very hard.
Another thing to keep in mind with a book like this is that it's a guide for validating an idea in a week -- but by yourselves. I think it can be done. I think this book provides the map. But, trust me, having been through this many times, it can pay to have a facilitator who can sit in with your group and make this happen. These are people who are deep in this, have done it before, and know exactly where to bend the process to suit your group.
I have seen "regular people" try to test an idea, and it can go sideways very easily. To be sure, the authors know this. They know, for example, that CEOs can swamp an idea or justify the wrong one. Even with their smart words about keeping people in the room as much as possible, and giving the boss more votes at certain critical moments, there's a lot more to say about how hard it is to keep everyone honest. That frequently takes a third party who is disinterested.
Another thing that bugs me quite a bit about this book is the invocation of companies Google Ventures has invested in. Ooooh, Slack. Golly. Slack is cool and rich, so if they did this methodology, it must be the thing! Please, tell me about some failures.
I am sure I sound petty here, but these folks are sitting on the shoulders of giants. Among those giants: Jakob Nielsen, Donald Norman, Robert Cooper, Eric Ries, Nir Eyal, Marty Cagan, Steve Krug, agile software development (XP and Scrum), etc. Toss 'em a bone.