Recently 6 members of our team were asked by our CEO to read a book called ‘Sprint — solve big problems and test new ideas in just five days’.
A book from three partners at Google Ventures describing a five-day process for solving tough problems, proven at more than one hundred companies.
As a User Experience specialist working in digital industry for over 12 years, a concept of rapid idea validation isn’t anything new. However, the book contains some valuable tricks, and interesting case studies that not only inspire, but also confirm that what we’ve been doing for years is a common practice across all industries and all varieties of problems.
All the good things
The book is thoughtfully designed and reads very well. Hare are few things I personally found particularly good about it.
- Facilitator Notes — summaries containing valuable hints and things to remember. Suggestions on how to communicate with the team are probably the best ones. Suggestion on using whiteboard markers instead of Sharpies for its versatility is also a great shout.
- Checklist at the end of the book — the essence of the book. If you’re not sure about reading the whole thing, just look at those few pages with references to page numbers where certain topics are covered in detail. Judging a book by it’s cover is something you should never do, but judging by the content index is a wise move.
- Real life examples — case studies revealing the ‘eureka’ moments. It’s worth saying that not all of presented case studies turned out to be a success. When dealing with innovative ideas, the failure is expected. Authors highlight this fact many times throughout the book. The growth mindset is an approach allowing to be imperfect. Making mistakes is good and welcomed.
- Drawings — funny and memorable. They present exactly what the sprint should be like. When a team is having fun when working hard, the passion shines through. When a team is not having fun when working hard, what you get in return is a stress.
The method
The method itself is an interesting concept. It’s as simple as the drawing below.
It’s brilliant in its simplicity. A team of around 7 people, gathered together over the course of five days, working out a prototype which eventually gets tested and validated.
But then, that’s exactly what makes me wonder — why do we need to spend what collectively sums up to 35 working days on this exercise? What if the budget isn’t sufficient enough to cover it?
And who can afford to go (what authors suggest) almost completely off the grid for 5 days?
Why is there just one day — or actually half a day planned for putting a prototype together? The sacrifice of quality of what will be tested compared to the time spent on the theoretical part of the sprint seem a bit unreasonable…
And — is it really going to work for ANY kind of project?
Learn from it, don’t copy it.
The Sprint is a guide. Just like any other guide (a travel guide, a cookbook) it’s designed to show you a direction and suggest ways of approaching certain problem. No two projects are the same and my advice to anyone thinking of adopting the Sprint in its whole glory is to use it with caution.
Still it’s definitely worth reading, especially if you haven’t had to validate innovative ideas in practice before.
Here’s where you can get the Sprint book: https://amzn.to/33PpSnN
I hope this short article helped you in any way. If so — please don’t hesitate to use that fancy 👏👏👏 button! Thank you.
