What do you think?
Rate this book
Sprint: Comment résoudre les problèmes et trouver de nouvelles idées en cinq jours (EYROLLES)
Chaque jour, les entrepreneurs et les responsables de projets doivent répondre à des questions cruciales : sur quoi concentrer vos efforts, et par où commencer ? Que donnera votre idée dans la vraie vie ? Est-ce que le projet répond aux attentes des clients ?
Il existe à présent une méthode éprouvée pour trouver des réponses. Développée par trois cadres de Google, la méthode Sprint a été mise en oeuvre avec succès lors des développements de plus d'une centaine de projets, dont Gmail, Google X ou Chrome.
L'idée est simple : une petite équipe, un problème à résoudre, et un processus serré qui permet d'aboutir à un test consommateur en cinq jours. Pas de théorie, les acteurs du projet sont tout de suite dans l'action, et mis dans les meilleurs conditions pour donner le meilleur d'eux-mêmes.
Cette méthode s'adresse aux équipes de toutes tailles, de la start-up naissante aux groupes internationaux. Elle est utile pour toute personne qui souhaite lancer une affaire ou tester une évolution de son business, et qui a besoin de réponses rapides.
302 pages, Kindle Edition
First published March 8, 2016
5107 people are currently reading
51322 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 1,496 reviews
December 18, 2015
Well, I'm biased, but I thought it was pretty great. Definitely better than the rough drafts! :)
October 24, 2019
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 regarding 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!
But.
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.
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 regarding 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!
But.
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.
March 17, 2016
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/...
September 27, 2016
The book was about organising a session to quickly come up with and test a product idea. This can be summarised in max 1 chapter and a whole books seems like a huge waste of time.
September 2, 2017
Interesting and informative business book. It details the "sprint" process used at Google Ventures (the venture capital arm of Alphabet / Google). The sprint is a way of approaching business problems, typically but not exclusively related to product design and marketing, through an intensive five-days of analysis, prototyping and feedback gathering.
As someone who works with large corporations where decision-making is often painfully slow, and meetings can be unproductive, it's nice to see a better way of getting meaningful work done relatively quickly in a team setting. The book is clear and highly prescriptive in detailing exactly what should be done on each of the five days, who should be in the room, what materials should be used, etc. It also gives several real life examples of how the sprint was used successfully to solve a number of business problem.
One criticism I saw in another review that I agree with is the book's lack of notes and bibliography. Obviously, many of the ideas here came from other places, but the authors don't give much credit.
I was especially pleased that many of the prescriptions of the book validated my own ideas about what makes for productive meetings and working sessions. Below are some of the ideas that made a lot of sense to me:
-- The importance of having a "decider" in the room, with the power and knowledge to make a decision and move the session along when things get bogged down. Others can and should offer their knowledge and feedback, but at the end of the day, the "decider" must take responsibility and decide.
--The importance of putting ideas in writing, using "sketches" and "storyboards", so that people have to carefully think through what they are proposing, and other people can have a clear understanding.
--The non-advisability of "brain-storming" as a way of generating good ideas. According to the book, too many social factors come into play in a brainstorming session. It's better to let each person work on their own for a period of time ("working alone together"), then post all ideas in writing on a wall so that each can be reviewed, critiqued and combined for the best solution.
--The importance of time-boxing, so that people who like the sound of their own voice don't take over the session.
--The importance of having large blocks of time without outside distractions (ie, no devices) to concentrate deeply on the important issues. The flip-side of this is the need to have regular breaks, and for the sessions to not run too long (10 am - 5pm, with 1 long break and 2 short breaks is the book's recommendation) to ensure people don't burn out.
--The optimum number of people in the sessions is seven, with a diversity of expertise. The book also says other "experts" can be called in for 10-30 minute interviews on the first day.
As someone who works with large corporations where decision-making is often painfully slow, and meetings can be unproductive, it's nice to see a better way of getting meaningful work done relatively quickly in a team setting. The book is clear and highly prescriptive in detailing exactly what should be done on each of the five days, who should be in the room, what materials should be used, etc. It also gives several real life examples of how the sprint was used successfully to solve a number of business problem.
One criticism I saw in another review that I agree with is the book's lack of notes and bibliography. Obviously, many of the ideas here came from other places, but the authors don't give much credit.
I was especially pleased that many of the prescriptions of the book validated my own ideas about what makes for productive meetings and working sessions. Below are some of the ideas that made a lot of sense to me:
-- The importance of having a "decider" in the room, with the power and knowledge to make a decision and move the session along when things get bogged down. Others can and should offer their knowledge and feedback, but at the end of the day, the "decider" must take responsibility and decide.
--The importance of putting ideas in writing, using "sketches" and "storyboards", so that people have to carefully think through what they are proposing, and other people can have a clear understanding.
--The non-advisability of "brain-storming" as a way of generating good ideas. According to the book, too many social factors come into play in a brainstorming session. It's better to let each person work on their own for a period of time ("working alone together"), then post all ideas in writing on a wall so that each can be reviewed, critiqued and combined for the best solution.
--The importance of time-boxing, so that people who like the sound of their own voice don't take over the session.
--The importance of having large blocks of time without outside distractions (ie, no devices) to concentrate deeply on the important issues. The flip-side of this is the need to have regular breaks, and for the sessions to not run too long (10 am - 5pm, with 1 long break and 2 short breaks is the book's recommendation) to ensure people don't burn out.
--The optimum number of people in the sessions is seven, with a diversity of expertise. The book also says other "experts" can be called in for 10-30 minute interviews on the first day.
April 12, 2016
Overview
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).
Detailed Review
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.
Highlights:
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.
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.
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.
Closing Thoughts
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.
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).
Detailed Review
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.
Highlights:
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)
Closing Thoughts
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.
July 1, 2016
I kept waiting for the "wow" moment but there really wasn't one. It's full of good info if you are new to software development or agile. Create prototypes, work with your team, get feedback quickly...
September 30, 2016
** NOTE: I did not read beyond p133 **
I feel like this could have been a blog post rather than a 264-pages book : I learnt more things in the inside cover picture and the checklist at the end than in the 133 pages I read.
The framework makes sense and the checklist at the end is pretty handy - hence I give 2 stars (I usually give 1 star to the books that do not keep me passionate until the end)
I feel like this could have been a blog post rather than a 264-pages book : I learnt more things in the inside cover picture and the checklist at the end than in the 133 pages I read.
The framework makes sense and the checklist at the end is pretty handy - hence I give 2 stars (I usually give 1 star to the books that do not keep me passionate until the end)
April 20, 2019
The general concept seems OK. I will try the Time Timer and see how helpful that is.
Update April 2019: I tried the Time Timer and it is actually quite useful so I bumped up the score to 3*.
Nerd addendum:
There was a lot of bashing of brainstorming that seemed inappropriate because a lot of the Sprint approach is taken from IDEO, who are evangelists for brainstorming.The authors' critiques were straw man arguments redefining the term. Overall, it seemed like the authors are forcing things to make their approach seem original. For example, including key stakeholders in strategic decision-making is pretty basic, not a revolutionary discovery.
Update April 2019: I tried the Time Timer and it is actually quite useful so I bumped up the score to 3*.
Nerd addendum:
There was a lot of bashing of brainstorming that seemed inappropriate because a lot of the Sprint approach is taken from IDEO, who are evangelists for brainstorming.The authors' critiques were straw man arguments redefining the term. Overall, it seemed like the authors are forcing things to make their approach seem original. For example, including key stakeholders in strategic decision-making is pretty basic, not a revolutionary discovery.
September 26, 2016
Practical guide in how to proper host a Sprint. I think it can be a bit more concise, although the checklist at the end is very helpful. Following the format saves you a lot of time. You still need to keep practising and finetuning your skills by running a lot of Sprints.
May 3, 2016
I classify this one as a "hammer-book". Why a hammer? Because it's about extremely crude & simple idea that won't cause a "wow" (or "oh snap!") exclamation, but still, even if the prescription is that simple, people just don't follow ...
"Sprint" is all about validated experiments, short, with fully dedicated (& decisive!) people on board. It's about proper decision making - not based on "expert's opinion", but on collaborative work of actual hands-on experts. Doesn't seem very revealing? Well, it isn't. The value of this book is based on credibility of Google Ventures (or GV) - Alphabet's company that does venture capital investment using this method (among many). In other words - the described cases & other shared war-stories are what's supposed to convince people that if they don't neglect any key points (like decision maker's full participation), they can expect a meaningful result.
But, back to the book - is it worthy? Depends. If you feel lost & you truly look for an solving approach for the problems you find unsolvable - I'm not sure. But if you just need a "testimonial" for PoC / MVP / prototype approach (to convince your boss or someone else in charge), this one can get truly useful.
"Sprint" is all about validated experiments, short, with fully dedicated (& decisive!) people on board. It's about proper decision making - not based on "expert's opinion", but on collaborative work of actual hands-on experts. Doesn't seem very revealing? Well, it isn't. The value of this book is based on credibility of Google Ventures (or GV) - Alphabet's company that does venture capital investment using this method (among many). In other words - the described cases & other shared war-stories are what's supposed to convince people that if they don't neglect any key points (like decision maker's full participation), they can expect a meaningful result.
But, back to the book - is it worthy? Depends. If you feel lost & you truly look for an solving approach for the problems you find unsolvable - I'm not sure. But if you just need a "testimonial" for PoC / MVP / prototype approach (to convince your boss or someone else in charge), this one can get truly useful.
March 11, 2016
I went into Sprint thinking it was going to be a good book for startups and small businesses. I quickly realized many of the tools and actionable insights outlined in the book can apply to organizations of any size and across pretty much any industry. I’d highly recommend it. – The book’s website has a lot of great resources worth checking out too.
February 15, 2019
Excellent book on how to get extremely valuable results and feedback for a product in just one week.
Very resourceful and easy to read and digest.
Another thing which I liked was that at the end, the authors provide checklists about all the processes they describe throughout the book which makes it easier for someone who plans on doing a Sprint.
Very resourceful and easy to read and digest.
Another thing which I liked was that at the end, the authors provide checklists about all the processes they describe throughout the book which makes it easier for someone who plans on doing a Sprint.
June 15, 2021
Nieko bendro su scrum’u, o puikus metodų rinkinys idėjų validacijai. Gal iškart į penkių dienų kalendoriaus blokus kolegoms ir nešoksiu, bet tikrai knygą laikysiu ofise ant stalo ir semsiu dalimis.
Labai paprasta, labai aišku, įdomu ir su aiškiais next steps.
Ir tinka ne tik tech produktams!
Labai paprasta, labai aišku, įdomu ir su aiškiais next steps.
Ir tinka ne tik tech produktams!
January 27, 2018
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!
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!
March 5, 2024
Update: since 2016 I read this book 5 times while running and participating in 10+ design sprints. Every time I see something useful and inspiring for the next sprint or workshop.
Review from 2016:
This book describes how to run 5 days sprints for rapid prototyping and user testing of the new and existent ideas. If you are following scrum and user-centred design methodologies the contents will not be completely new. However, this is a really good, humorous, not repetitive and to the point guide to the product vision development.
The book also features checklists (can be found on the book's website) for every day of the sprint, so you don't need to take too many notes about the process.
After finishing this book I'm really eager to try it together with my design and scrum team.
Review from 2016:
This book describes how to run 5 days sprints for rapid prototyping and user testing of the new and existent ideas. If you are following scrum and user-centred design methodologies the contents will not be completely new. However, this is a really good, humorous, not repetitive and to the point guide to the product vision development.
The book also features checklists (can be found on the book's website) for every day of the sprint, so you don't need to take too many notes about the process.
After finishing this book I'm really eager to try it together with my design and scrum team.
April 29, 2019
I should mention that I had high expectations from this book.
Unfortunately, it doesn't worth your time and effort, I will explain why:
1. The book is based on too many assumptions.
2. The authors highlight the happy case scenario to prove the effectiveness of this technique.
3. This book is missing the most important question "Is there a problem"?
4. There are too many contradictions.
5 The authors cant make the difference between user testing and usability testing.
Generally speaking, this book reflects "Design Thinking" & "Double Diamond" models in a very amateurish way.
Unfortunately, it doesn't worth your time and effort, I will explain why:
1. The book is based on too many assumptions.
2. The authors highlight the happy case scenario to prove the effectiveness of this technique.
3. This book is missing the most important question "Is there a problem"?
4. There are too many contradictions.
5 The authors cant make the difference between user testing and usability testing.
Generally speaking, this book reflects "Design Thinking" & "Double Diamond" models in a very amateurish way.
March 21, 2016
Good approach, good outline to follow. I can see how it would be helpful for a lot of companies.
But what marketing genius came up with that name? Not only is it already widely used within the Agile community (Scrum sprints), but it also has a different meaning (here: dash as in track and field; Scrum: huddle or get-together as in Rugby). If this method takes off, this name will be cause for lot of confusion :(
But what marketing genius came up with that name? Not only is it already widely used within the Agile community (Scrum sprints), but it also has a different meaning (here: dash as in track and field; Scrum: huddle or get-together as in Rugby). If this method takes off, this name will be cause for lot of confusion :(
July 13, 2017
An excellent and practical guidebook to solving creative problems in today's workplace. No fluff, all clear and concise tactical executions written day by day, and even provides checklists at the end to wrap everything up. Shows tremendous value in giving a structural method to the madness of brainstorming and ideation.
April 2, 2019
Books that could have been a blog post presents: Sprint.
No, really, this book is full of “noise” interfering with the actual valuable information to understand the methodology. It’s a mess, introductory stories which are not related at all with the chapter or the part of the methodology they’re about to talk about. Messy edition, censored names and cases. Don’t waste your time and find a blog post that you’ll be able to read in 10 minutes to understand the steps and save yourself a full evening reading this “book”
No, really, this book is full of “noise” interfering with the actual valuable information to understand the methodology. It’s a mess, introductory stories which are not related at all with the chapter or the part of the methodology they’re about to talk about. Messy edition, censored names and cases. Don’t waste your time and find a blog post that you’ll be able to read in 10 minutes to understand the steps and save yourself a full evening reading this “book”
December 24, 2015
Learn how Jake and his buddies at Google Ventures have helped startups solve big problems with the Sprint. The book is packed with interesting anecdotes, lessons learnt, and lots of other tips that will help you run your own Sprints. I want to run a Sprint now!
November 14, 2016
Abandoning at 70%. Not enough ideas worth writing a whole book.
Read
April 15, 2025After being really eager to read this book after absolutely loving Make Time, it was a bit unfortunate to find that I really am not the target audience for this book 😝 Might revisit it if and or when I work more in a team-based space with other people compared to the one-man-band I've currently got going on.
That being said, I loved the little graphics and pictures we got throughout, and appreciate the casual but informative tone of the book 👌
(Also, good job me for posting my first book review, haha 🥳)
That being said, I loved the little graphics and pictures we got throughout, and appreciate the casual but informative tone of the book 👌
(Also, good job me for posting my first book review, haha 🥳)
January 30, 2021
Veryuseful. Short and concrete described what to do, when and all necessarythings.
April 21, 2021
Very practical guide with real world examples
June 23, 2020
A very practical book with a set of actionable ideas, exercises, and general directions for finding solutions quicker. It's like a manual for innovation that you could put in practice right away. However, there were some sections with repetition but it wasn't so overwhelming. It's really easy to read and I highly recommend going throughout the book.
June 6, 2019
Það sem höfundur ætlar sér með bókinni er að koma á framfæri þessum ferli til að prófa hugmyndir hratt og fá niðurstöður um afstöðu viðskiptavina á innan við viku. Þetta tekst honum mjög vel og bókin er sæmilega skemmtileg aflestrar í leiðinni. Ég hlakka til að beita hönnunarsprett sjálfur í framtíðinni, en hugmyndirnar eru líka til í bloggi fyrir þá sem vilja taka styttri tíma í að kynna sér þær.
July 4, 2021
This book works on two levels:
1. The first level is the instructions on how to run a "design sprint," which is a processed originally developed at Google / Google Ventures, but now used by designers all over the world, which has step-by-step instructions on how to go from identifying a problem, to coming up with a design, to building a prototype, and even testing the prototype with users, all in 1 week. It's a cool idea that we'll be trying out at my company shortly.
2. The second level is that the design sprint itself uses several dozen tools and techniques that are useful in a variety of contexts. It's like a grab-bag of team-work and collaboration best practices, and I see us using many of these tools and techniques outside of design sprints too. Some of these include user journey mapping, explicitly asking "how can we fail," the "how might we" exercise, lightning demos, the four-step sketch, crazy 8s, art museum, dot voting, heat maps, speed critique, note and vote, storyboards (including opening scenes), and more.
Unlike many other business books, this one has no fluff or filler. It explains what design sprints are, where they have been used, why you may want to try them yourself, and then dives right into the process you use, going through each day of the design sprint in detail. Along the way, you get lots of examples from real world design sprints (e.g., at Slack, Blue Bottle Coffee, Medium, etc), plus checklists at the end that help you run your own. You can read the book in one afternoon and start trying out design sprints, and the other tools in this book, are your company the very next day. Highly recommended!
1. The first level is the instructions on how to run a "design sprint," which is a processed originally developed at Google / Google Ventures, but now used by designers all over the world, which has step-by-step instructions on how to go from identifying a problem, to coming up with a design, to building a prototype, and even testing the prototype with users, all in 1 week. It's a cool idea that we'll be trying out at my company shortly.
2. The second level is that the design sprint itself uses several dozen tools and techniques that are useful in a variety of contexts. It's like a grab-bag of team-work and collaboration best practices, and I see us using many of these tools and techniques outside of design sprints too. Some of these include user journey mapping, explicitly asking "how can we fail," the "how might we" exercise, lightning demos, the four-step sketch, crazy 8s, art museum, dot voting, heat maps, speed critique, note and vote, storyboards (including opening scenes), and more.
Unlike many other business books, this one has no fluff or filler. It explains what design sprints are, where they have been used, why you may want to try them yourself, and then dives right into the process you use, going through each day of the design sprint in detail. Along the way, you get lots of examples from real world design sprints (e.g., at Slack, Blue Bottle Coffee, Medium, etc), plus checklists at the end that help you run your own. You can read the book in one afternoon and start trying out design sprints, and the other tools in this book, are your company the very next day. Highly recommended!
April 13, 2016
This is a must read book for anyone planning to do a 5-day Design Sprint in Google style. The authors work at Google Ventures and use the same format for all startups invested by GV. I work for Google as Developer and Startup Relations Manager and we also use the format to help early-stage and mature-stage startups inside our programs. The book contains every detail and step by step processes to run the 5 day design sprint. The main sections of the book are organized by day (From Monday to Friday). In summary buy this book if you want to solve problems in a team setting and by using techniques from Design Thinking and Lean in a fast paced workshop format!
May 28, 2016
The overall description of the design sprint process is good, the case studies are interesting. I felt that this book could be more useful for product people at the beginning of their carrier, than more experienced professionals. The books explains the process, but doesn't highlight the reasons behind it.
Displaying 1 - 30 of 1,496 reviews