Sprint: Review of the book and first design sprint XP!

Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days

Before running a design sprint

(December 4, 2018)

Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days by Jake Knapp

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: The Prototype Mindset.

I will come back to this review after running the sprint and share here my perception of the book after putting into practice.

View all my reviews

Update: After my first design sprint!

(January 27, 2018)

Last week 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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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!