How to Solve Big Problems and Test New Ideas in Just Five Days
Ratings64
Average rating4.1
I will preface this review by saying I rarely enjoy or learn something new and perspective-changing from business books, and often won't recommend them even to colleagues, so my 5-star rating system as I've defined it is not kind to the genre. Generally speaking, this was a fine book. I think the concept is interesting, and it's been recommended at every product management workshop I've attended. It's broken up into a logical, day-by-day structure that explains exactly how to attack a 5-day sprint to test a prototype and “fail fast” with little consequence. It's illustrated and peppered with helpful real-life examples. But to actually get the time and resource to do this for a prototype is something I can't champion (at least, not at my huge company, and not at my level/experience), and given the book is more or less a step-by-step how-to... it's not especially helpful for me. Who knows, though. Maybe down the line — and then I'll be appreciative I have a copy of this book.
If you're considering a sprint for a business product or venture, just buy this book already. It's a fun read, practical, actionable, with lots of examples. Highly recommended.
Hands-on, useful mix of various approaches to prototype and gather feedback over the course of a week. Team-based, structured and with checklists, it's great for those who have the ability to follow steps exactly — I understand why they didn't want to build “spin off” options, which I'm sure their website might capture, but would have liked to see some nonetheless.
Contrary to widespread praise, Knapp et al. offer yet another turnkey solution that is going work if you just do it right. In case you don't, we offer workshops. Sorry, no money-back guarantee.
Dave Snowden of the Cynefin framework calls such tactics “faux industrialisation”; an apt label for this process.
Some methods and tools might be worth your while. If you have a hipster product friend, borrow their copy and steal what you find useful.
Sprint je skvělá metoda, kterou vlastně dělám celou dobu, jen v trošku poupraveném podání. Takže tato kniha mi krásně ukázala, jak bych se sám mohl zlepšit a hlavně pracovat efektivněji. Jednotlivé kapitoly jsou rozděleny po dnech a já doporučuji je číst taky tak. Od pondělí do pátku. Každý den tak můžete vstřebat to, co jste se nového dozvěděli a rozmýšlet, jak by vypadal sprint vašeho projektu.
Doporučuji všem markeťákům, startupistům a jiným game changerům.
I'm going to be bold here. This is one of those books, like the “7 Habits of Highly Effective People” and “Getting Things Done” that lays out what you think might be obvious in a way that makes it actionable and concrete. It belongs on the same shelf, to serve as a reminder of the tools available to us.
Basically, Jake Knapp clearly (with examples from Google Ventures) lays out how you can save time by focusing attention on ideation, elimination, and testing to get from “My Big Idea” to “My Actual Thing” in a reasonable amount of time. Pitfalls, roles, and materials are all identified. The decision structures and limits laid out in each step may be the most valuable part of this book. I like that you can read it straight through and see how this worked for the example ventures (only one of them is software) and still reference the the tools and checklists included in the book from the website later.
While I have not tested the Sprint idea, I feel confident (since it was tested by Google Ventures more than 100 times) that following the plan will work for many different kinds of ideas. This book is an incredibly fast read with well-organized reference material. I'd recommend this to anyone who wants to do/create/make/sell/etc. something and isn't exactly sure how to get there.
Woaw, finally finished this wonderful book, now I want to implement it everywhere, and can't wait to do it. While I've never been at all a meeting guy, this methodology proposes finally a reason to make some giant ones with a deep purpose and clear objectives, while encompassing everything we learned about human psychology (avoiding brainstorming traps where the quiet one don't say anything, avoiding decisions traps, ...). The whole process looks really smooth and interesting and could suit almost any project. It also integrate real user testings, something I think is deeply necessary for every project, to avoid one's blindness. Really can't wait to put it into action :)
It's pretty good, but like many ‘business books', could be half as long and retain all the meaning.
This is an excellent book, and so much better than the ‘Design Sprint' book I reviewed recently, which suffered from being full of pictures, but none of them relating to the content of the book...
This volume, conversely, is sparsely illustrated but each one is directly relevant.
I teach design, and I use methods like this in curriculum development. I'm actually doing my PhD on the use of methods like this as a way of promoting creative approaches to teaching and learning in Higher Education. So it's quite timely. All the methods are familiar to me from design research, service design etc. What makes a sprint interesting is that it makes clear what a lot of us have known for a long time: you don't need months and endless committees to make decisions. In fact that's a great way not to make decisions. What you need is a short burst of focused time, and a plan.
Although the book says otherwise, you can use these techniques in much shorter timeframes, depending on what you need. I used a two-hour sprint to get from nothing to a coherent School strategy that everyone has signed up to - I spent three years trying to do the same thing at my last university!
The Design Sprint book is focused on interaction design. This book looks mainly at services and products. That's better. But... I'm using it to design a course and as the week progresses the process requires more and more customisation until the Friday just doesn't work for our purposes. The principle does and this is the book's weakest point that just at the point where the readership is likely to diverge, the content becomes the most prescriptive and most likely to lose people. Next iteration, I'd suggest the authors look at this section so it covers a larger range of problems being tackled. But that's really a minor criticism - if you're reading this book you're hopefully quite a creative type anyway, able to adapt to suit.
Another point might be that the examples cited in the book tend to be ones where participants were ‘on board' with the whole idea. In my experience there is usually at least one recalcitrant. Some tips on dealing with negativity would be useful.
My other recommendation would be that the supporting website collect readers' case studies - it would be a fascinating resource and help people find examples similar to their own needs. I can't be the only person using sprints to design degree programmes, can I?
But all that aside, this is a really good book, easy and quick to read and one that will make you keen to give it a go. Start with something simple, if you can. But given the situation in my own country at the moment, I wish some of our politicians would read it and realise that maybe they don't need six years to figure out what the UK will look like post-Brexit. Maybe they just need a week.
Having recently moved from a developer position to a product manager position this book gave some immediate suggestions on how to lead a team to create a new product or feature from scratch. Having been used on a number of products at Google including Gmail, it's great to know that it's working already.
What was most useful for me was seeing the breakdown of what was done each day of the 5 day product sprint – as well as what each person in the sprint would do. Some of the recommendations were key - like the need for a decision maker to be a part of the process to ensure that takeaways from the sprint are actionable. I look forward to trying out some of these concepts eventually!
Having recently moved from a developer position to a product manager position this book gave some immediate suggestions on how to lead a team to create a new product or feature from scratch. Having been used on a number of products at Google including Gmail, it's great to know that it's working already.
What was most useful for me was seeing the breakdown of what was done each day of the 5 day product sprint – as well as what each person in the sprint would do. Some of the recommendations were key - like the need for a decision maker to be a part of the process to ensure that takeaways from the sprint are actionable. I look forward to trying out some of these concepts eventually!