Sprint — A Book Review
In the Agile-Product-sphere, there are some books which are almost biblical in the frequency with which they’re referenced. One such book, which I just finished reading, is Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days by Jake Knapp. That is, of course, the book that spawned the now famous idea of the Design Sprint. Briefly, if you haven’t heard of the concept before, the book lays out a step-by-step guide for identifying a specific problem, solutionising, and validating a solution to that specific problem in five days. As an Agile geek and a budding product person, this seemed like a great book for me.
A quick note — the Design Sprint presented in the book is a five-day affair. More recent work has come up with a four day version that achieves more or less the same outcomes.
Bottom line up front — this book is good. I gave it four stars on Goodreads (read as: I’d recommend it to a friend, but probably wouldn’t read it again in full).
One slightly confusing note is on terminology. In Agile, sprint means something very specific and well defined, but in Sprint they use sprint to refer to what I’d usually call a design sprint. I’ve tried to keep to design sprint in this post, for consistency.
Sprint lays out a process for helping you solve a problem; to validate a solution to a (relatively narrow) problem. If you want to create an entirely new product from scratch, it’s probably not a good option, if you don’t have the understanding of who your customer is and what their problems are, this doing a design sprint is going to be an expensive waste of time. Conversely, if you have one facet of an existing process you want to significantly improve, this should be one of your go-to options. One of the examples from the book is Slack; Slack’s problem was explaining to potential new customers what problem their software was solving. That’s kind of narrowness that’s recommended. Clearly it worked in that case, because if you’re reading this, you’ve almost certainly got a Slack window open somewhere right now.
This is the ultimate extension of the Agile mindset — decide on a problem to solve. Suggest a solution. Do as little work on that solution as you can to validate it. Keep what was good, throw away the rest, and repeat (and repeat, and repeat, and repeat…)
Like many outstanding books (see Meditations for another example), there’s nothing groundbreaking in Sprint. If you’ve been in and around Agile thinking and Agile processes for any amount of time, you’ll read sprint with your face in your hands, wondering why you hadn’t been able to articulate the same ideas as clearly and concisely as they have been in the book. Sprint doesn’t present new principles. It’s a practical applications of the same principles you’ve seen everywhere. If you’ve read a lot of Agile literature, many of the ideas will be familiar to you already. If that’s the sort of thing that might annoy you, you’d probably be better to skip straight to the no-nonsense checklists at the back.
Jim Mattis, former US Secretary of Defence, has a saying, decisions are made at the speed of trust. As I read, I found myself being brought back to Call Sign Chaos. Despite the vastly different contexts, the idea that the decider must be in the room is the exact idea Mattis tries to convey. In either case, the person with ultimate decision making power needs to be in the loop. In Mattis’ version, that means delegating decision making power to the people with boots on the ground; in Knapp’s version, it means either delegating that power to someone in the room, or getting the ultimate decision maker in the room. You can’t afford to have decisions undermined by someone outside of the room if you want decisions to stick.
Most of the examples in the book have some front facing element. That definitely makes it easy to conceptualise, and definitely makes the prototyping easier, but not all teams work on products with a user interface. I think the design sprint methodology, as laid out, can be adapted for any sufficiently well defined problem space, it will definitely take some finangling to make it work for non-front-facing problems.
I don’t believe a design sprint (or any tool, more generally) is a silver bullet, a magic tool to solve any problem. Design sprints are logistically challenging, have a very narrow focus, and don’t scale particularly well. It’s a tool with a very specific use (validate a solution to a single, specific problem.) It takes 7-ish people a full week of effectively being locked in a room with a singular focus. I think the cases when you’d run a design sprint are relatively rare, but when its the right tool, you’d be happy to have it in your toolbox.
I was excited reading Sprint. I can think of a lot of problems I’ve worked on in the past, or problems I’d like to work on the future where this would be just the right thing to do.
Overall, I’d give Sprint a 4/5. It’s slightly more useful if you have a particular problem at hand, and possibly slightly less useful if you’re already comfortable with techniques for rapidly validating solutions. If you do have a problem you’re grappling with, I recommend you at least check the book out. It’s an easy read, and you can validate if it’s right for you very quickly.
Have you tried a design sprint, or another tool for quickly validating an idea? What did you think? What would you do differently next time?
