The book is one of the best I read in a while and that’s even though I won’t be able to make use of its main content anytime soon. Check out the gory details below.
You can find more information about the book on its dedicated webpage https://www.thesprintbook.com/
The book is about running design sprints for getting answers to the biggest questions of large and risky projects. The overall idea is explained quickly: take about 5-7 of the most important stakeholders, including a decider (CEO or similar level) and have them work together for a full week without distractions. While this starts off as unrealistic, the authors do a good job in justifying why such a time investment of particularly these busy, highly paid but important people, makes a lot of sense in today’s markets. Instead of only making small advances and having lots and lots of minor meetings over a large time, the design sprint is a hyper-focused way to achieve breakthrough results that allow a project or idea to be continued afterwards with the biggest risk obstacles out of the way.
The five days are split up like this:
- Monday: Start at the end – agreeing on the goal, creating a map towards it and interviewing domain experts
- Tuesday: Remix and improve – with a final sketch of an idea to prototype.
- Wednesday: Deciding on a prototype and storyboarding it
- Thursday: Fake a full prototype within a day
- Friday: Test the prototype on real customers to get the answers you were looking for
The reader profits from the massive amount of experience the authors accumulated with executing such sprints. The book is littered with loads of examples of companies of various sizes and in diverse industries – except for the type of company I’m currently working for: a service company. When you develop your own product, you always run the risk of making the wrong decision and invest a lot of money into something customers don’t want to buy. The book convinced me that design sprints are an amazing process to dramatically reduce that risk. If, however, you provide software development as a service, the situation appears to be different. I can see how I could serve as a facilitator of such sprints to our clients (just like the authors, except that I don’t know much about it), but I cannot see a good application for a company with a service-based business model. It’s an issue I see with a lot of topics these days, but that’s for another post.
Nevertheless, the book is an amazing read. Just the anecdotal stories on their own are worth the read when the authors let you in on the gory details of how the various exemplary companies managed to pull off amazing feats within a week. The book is structured just like the proposed design sprints: each day of the week has a clear agenda such that each day forms a chapter. Add another chapter for a general introduction and one for final remarks and you got the table of contents. It’s clear, it’s focused, it’s perfectly matching the content.
Between the explanations and anecdotes, the book is full of little tips and tricks here and there. It’s a wealthy source of ingenious small ideas, like the time timer, gathered from the authors’ experience of facilitating over 100 of these sprints. The practicality of the book is topped off with several reference checklists for running your own design sprints – from a list of things to shop for in preparation to detailed breakdowns for each day.
This is really hard to tell. It’s tempting to declare CEOs, product owners and other such roles as the target audience, but the book makes a really good point in that it’s sufficient for the sprint facilitator to know the contents of the book. Due to the many helpful tips generally applicable to meeting facilitators, I’d say that they can get the most out of the book. Personally, I probably won’t be in any design sprint anytime soon, but will certainly apply lots of ideas from the book in numerous other meetings.
Lovely. The book is such a fascinating and peasant read. It’s so well-written and engaging that I couldn’t quite put it down and raced through it in just two evenings. As I’m a slow reader you may well manage to read it in a single sitting – it’s just short of 300 pages which seems a perfect size. The authors managed to navigate the fine line between being either too concise or too excessive. It’s the best book I read this year.. uh well.. that may not be the best thing to say in January, so let’s place it among the best compared to everything I read throughout the last year.
If design sprints, developing prototypes in a single day, and getting better in facilitating sound intriguing to you, this book is a must read. If you are developing a product and can somehow influence decisions, you may still want to read it. It’s not really a book about the technicalities of how to develop software, but definitely focuses on the business side of software projects – so if that doesn’t appeal to you, you may want to skip it.
Just to bring that point home: even when you don’t plan to invest in a full 5-day sprint, you may very well profit tremendously from any of the interesting techniques the authors propose for each of these days.