I just finished the book Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days by Jake Knapp and I am struggling to clearly define my feelings on the Design Sprint process. First and foremost, I cannot disagree that wonderful ideas and products have come out of teams using the Sprint process. The idea that I am struggling with is if it is truly a design process or, rather, a reactive process to better focus/refine work that is already being done. Early on in the book, it is noted that the author draws from both Lean and Agile practices, which it clearly does, but I feel both of these practices are about starting from the beginning. The examples used in the book felt like they were all ideas or products already in the works, like the hotel robot and fitness app, but had not found the right next step – like specific functionality or a target market. I also felt like there were some contradictions, like stating a prototype is better than an MVP, but then they gave examples of building a website using simple presentation software – essentially an MVP.

Again, I love the idea of a Design Sprint. I am a process guy and really like how it is clearly laid out with well-defined objectives for each day. To me, it is the clearly defined process that is the Design Sprint’s greatest strength. To help me lay out my thoughts and maybe figure out how I would use a sprint, I have written out the pros and cons – as I see them – below:

Pros – Things that I really liked about the process:

• As I said above, I think the level of detail provided for the five-day process is a massive benefit to help drive success. This helps make it easier for non-process people to simply follow the instructions. It also acts as an accountability measure as facilitators can easily point back to the process to stave off folks who are pushing against the process and/or an idea.
• Making sure that all the key stakeholders are in the room is fantastic. Functional managers, decision-makers, etc. By having all of the relevant voices in the room, especially decision-makers, it helps to reduce the chances of hitting a roadblock down the line.
• Sprints allow for quick repetitions to continue the learnings from the previous week. If the prototype completely fails with the five interviewees, the team will have at least learned why, and then be able to adapt and refine those items for the following week. Spending a week, two weeks, or even a month is likely far less time than some organizations are currently burning up on developing/refining new ideas.
• The Design Sprint process pulls some of the best elements from the Lean and Agile processes to quickly find solutions that will lead to a satisfied customer and are therefore more likely to find scalable success.
• An element that was addressed really well was dealing with potential conflict areas, possible groupthink, and avoiding bias. It really came through that these best practices were learned through trial and error – with the process continuously being improved with each iteration.

Cons – Things that stood out as not ideal:

• The first thing that really stood out to me is that the book clearly draws from Lean principles, but does not address the most important idea of starting with customer discovery – identifying a customer’s hair on fire problem before developing a solution. Sprints seem like a reactive process to not finding initial success, and needing to find a small pivot, rather than a proactive approach.
• Key assumptions are made from Monday to Thursday. That time is wasted if you only learn that on Friday – even if the interviews yield information for a small pivot.
• Only five interviews make me feel nervous if there is not a clear next step to verify the information with additional potential customers.
• Finally, I believe each example given in the book depended on a large amount of work having already been done before the Sprint came into the picture. None of the examples seemed to really be pure design. It seems more fine-tuning to get the right fit before launching.

As I look back at my notes, I feel the main issue I keep coming back to is the idea that a Sprint is meant for an idea that has already been started. It is not a design process that starts with a truly blank slate. There are a number of assumptions made on Monday, Tuesday, Wednesday, and Thursday, and this would be the case whether it was the very start of an idea or with a team that has already started building.

So, I started thinking about what I would do to address my concerns before conducting my own Sprint. Right now, the process is laid out like this:

As a firm believer in Lean principles, I think more preliminary analysis, understanding, and customer discovery in needed to increase the chances for success – faster. Below is the addition of an initial week to add in more customer discovery, but following the same timeline and processes set in place for the standard Sprint: (click to enlarge)

As I write this, I fully understand no one can control certain factors about getting interviews and even the interviews a team would get on those two days would not be able to fully validate anything. However, it would at least present a firmer foundation to launch the Sprint and could potentially involve fewer resources (people) throughout the week to reduce the impact. It should also be noted that if the first five interviews on the standard Sprint fail an extra week is going to be added anyway.

At the end of the day, I do really like the Design Sprint idea and approach. It has clearly been very successful for many different companies. I just look at it and think there are ways to make it an even more powerful tool for an organization to use.

What do you think? Are there other ideas for improving the Sprint approach?

Image Credit