Sprint: A Five-Day Roadmap for Solving Big Problems

This is a somewhat intuitive book review of Jake Knapp’s Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days, because I haven’t read the book (released date is tomorrow), just the Inc.com article, “How to Come Up With Your Next Product Hit in 5 Days“, in which “Jake Knapp, design partner at Google Ventures, explains the system he invented to create working prototypes in a hurry.” And in keeping with the notion of sprinting, the article and method is summarized by the five days/steps, which are:

  1. Agree on the Goal
  2. Come up with Multiple Solutions
  3. Choose the Best Option and Create a Plan of Attack
  4. Build a Prototype, and
  5. Test it

Of course, it’s the details here that form the impact — on the surface, the five steps (or days) sound like they may be too basic to be of help. Each one needs just a very little bit of unpacking to understand why this model works, and why I’m intuitively saying he’s nailed it. (Reminder: the following comments are based on the article and not directly on the book.)

The beginning is important.

Before beginning, Knapp recommends putting together a team of seven people–more can slow things down, and fewer puts you at risk of not getting enough diverse opinions. The founder, CEO, or whoever else has final say should be present, as well as at least one expert from finance, marketing, customer support, tech, and design.

The sprint should take place in a room with plenty of whiteboard space. And save the texting for breaks–no devices allowed.

I’m not sure how the number 7 is derived exactly, or whether it’s just experience. In any event, it sounds about right and I’ve got nothing to refute it. I can, however, attest to the wisdom and utility of having plenty of whiteboard space available.

Agree on the Goal

The first day’s focus isn’t on solving the problem, but defining it. …the group should decide on a long-term goal for the company: What do we want to be doing six months from now, or a year from now? Then turn the focus to this sprint: What problem do you want to solve this week–and how will solving this problem help you accomplish the larger goal?

This one is easily overlooked. If your short-term goal for this effort isn’t in line with the long-term goals of the company, it’s going to be wrong for the company, no matter how great the solution may be in another context. Beware of thinking that a full day is too much time for this — not only is it critical to keep the solution in line, it also needs deep enough discussion to produce concretely-defined long-term goals.

Come up with Multiple Solutions

Knapp doesn’t like brainstorming. People tend to favor the craziest ideas, he says, without thinking about how they’ll actually be accomplished. Or, even worse, the winner is simply the loudest voice in the room.

Instead, Knapp prefers what he refers to as parallel individual work. Each person in the sprint sits down with a pencil and paper and sketches out their idea.

This one zeros in on the best aspect of crowdsourcing, or collaborative work. People often misunderstand these concepts, thinking that collaboration requires continually working together, more like a committee. In fact, crowdsourcing is most effective when ideas are allowed to come into focus before they ever hit a committee. Committifying them too early stunts their development and is predisposed to send a great idea to the trash heap before it can grow up.

This is the weakness in brainstorming, where some voices dominate while others are silenced and where ideas that don’t have a well-explained foundation tend to be cast aside. (Like Knapp, I also don’t particularly care for brainstorming.) Knapp’s approach here helps put introverts on the same footing as extroverts and ensures adequate time and different methodologies for explaining an idea.

Choose the Best Option and Create a Plan of Attack

A traditional company hierarchy rarely allows founders and employees to offer their ideas with equal weight. The design sprint does just that. The sketches are taped to a wall or whiteboard, and they all remain anonymous. The ideas are then studied in silence.

…each participant gets a handful of stickers they can quietly place next to the individual aspects of each idea they especially like. …solutions are then discussed one at a time. Notes are written around them with a dry-erase marker or Post-its, and a timer ensures all the ideas get equal attention.

Knapp’s methodology features a review of aspects of an idea rather than the fully-baked idea itself. This is important, because it facilitates one of the ideas rising to the top based on various aspects rather than on its bottom line, or worse, having it discredited because of an apparent weakness that could be improved upon by the group. Here again, we see a strength of crowdsourcing over committee solutions. The crowdsourced solution is strongest when the idea is adopted in as fully-formed a manner as is practical. The committee version takes a young idea and adds everyone’s input to it, more often than not diluting the aspects that made it a good idea in the first place. A committee can bring different goals (covered in step one) or preferences, of which the most vocal ones get greater weight.

In any event, this is the step where input from the rest of the group can start to further shape the idea and begin to strengthen any weaknesses. The day ends with a storyboard of how the idea is experienced by the customer.

Build a Prototype

It’s only Thursday and you’re already prototyping — but you’ve only got one day to do it! Knapp suggests that most prototypes at this stage can be made by repurposing what you already have from existing products or earlier attempts. The prototype doesn’t need to be fully functional — it may only be an interface design or a set of marketing materials.

Test it

Research shows that five is the perfect number of customers on which to test your product–beyond that returns are low, since the same feedback will keep coming up. On the final day, pick five customers who will each spend an hour using the prototype and speaking with a member of your team, while the rest of the crew watches via live-streamed video in another room. The team takes notes and decides what should stay and what needs tweaking–or a complete revamping. There isn’t always a finished product by this stage, but your team will know what it needs to do to get there.

“By the end of the day on Friday,” Knapp says, “there’s clarity about what to do next. Some solutions will totally fail, some will succeed, and often you’re in the middle: You have something promising, but it needs work.

What I like here is the echo of a principle explained in Eric Raymond’s seminal essay, The Cathedral and the Bazaar: “Release early, release often.” This observation from software development illustrates the importance of getting the users’ hands on the product quickly in order to get feedback and to find any bugs. In this context, it’s the feedback that’s crucial to get back to the team before the development effort goes very far down a wrong path.

Five Days Later

Using Knapp’s method, five days is a whirlwind to go from problem to tested solution, but therein lies a great strength. If the idea isn’t going to work, you can go back to the drawing board without having lost too much time. When using older models in large enterprises, it can take 6-12 months to get to the same place, but by that time the idea is so heavily-invested-in, it becomes harder to write off, especially when an alternate solution looks to be just as far off. With Knapp’s method, it’s easier to cut one’s losses and replace them with another (hopefully better) idea, and do so while the lessons learned are still fresh.

From my perspective, the Sprint method has several attractive strengths.

  • The team size and timeline are focused on agility.
  • It solidifies the big picture at the outset.
  • It doesn’t rely on brainstorming, but makes use of the best principles from crowdsourcing.
  • It equalizes the ideas of introverts and extroverts, and of people with varying skill levels at expressing an idea.
  • It allows a deeper exploration of every idea than is available through brainstorming or committee exercises.
  • It quickly arrives at a potential solution and begins to act upon it.
  • It acquires early feedback and aligns with the “release early, release often” principle.

As Knapp says, “Instead of spending months or even years on a hunch that may turn out to be wrong, you’re able to answer your questions really quickly–to stop debating in the abstract, and start making progress.” In many ways, it aligns well with the RAIN methodology, which we wrote back in 2003.