Sprint: Solve problems and test ideas in five days

January 3, 2017

6225

Sprints enable you to get answers to key product and service questions in just five days. The process moves through identifying questions, creating solutions, storyboarding, prototyping, and testing with customers.

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

The sprint is Google Ventures’ unique five-day process for answering crucial questions through prototyping and testing ideas with customers.

A sprint is a five-day structured process used to resolve a big open question facing a product or service team. Sprints are used by product teams to test and get decisive feedback on any new offering or approach for new or improved products or services. The compressed set of steps is designed to answer fundamental decisions and unknowns for teams launching or improving new products or services. Sprint gives examples of robotics, healthcare service, cancer research study matching, coffee, and a sports fitness mobile app. Each case study is illustrated in detail through the five days of the sprint.

Knapp says “the bigger the problem, the better the sprint.” You’re investing in a team of about 7 people for an entire week so it should be worth their while. A sprint culminates in creating a prototype and observing your customers using it. Knapp argues that a good enough prototype will get you the answers you need because if you “get that surface right…you can work backward to figure out the underlying systems or technology.” Prototypes can be paper, brochures, videos, environments, or play-acting by the team.

The book has a lot of detailed information about setting up the sprint, scheduling, the environment, facilitation, what to have in the room, and what to do when to keep everyone fresh and involved. Examples include specifics such as craigslist copy writing tips.

The outcome of a sprint is a prototype shown to customers which answers key questions posed by the team. The entire cycle is performed in five days during business hours. A team of seven starts by identifying what they want to learn and then goes through a discovery and design process to build a prototype that is used to facilitate customer conversations and learning.

A key role in the sprint is the Decider. This is the person who frames the objectives and makes the critical decisions throughout the week with input from the team. This role is consistent with the sprint principles of focus and speed.

Sprint guidelines include no devices during work sessions and a full week commitment from all participants. It’s designed to keep the team focused and engaged in the outcomes.

Although many product teams begin with the best intentions of carrying out the build-measure-test-learn cycle, they tend to start with a bad idea, they waste time building it, they launch it because “there’s no going back” and end up with inconclusive results rather than the clean data they were hoping to find. Sprint tries to shortcut the process. Over the course of a week: ideate and flesh out, prototype, and test it.

Monday – identifying the questions

To begin, establish a sense of urgency and get the right people in the room. You’ll need a Decider, the person who can make decisions about which customer problem to solve, which customers to target, which solutions to pursue, and how to move forward with next steps.

Monday sets the stage for the rest of the week. The team will identify their objectives and pick the most important problems to solve. Later in the week the prototype will be designed to answer the questions identified on Monday. Monday’s activities include mapping the challenge and listening to presentations by experts on various aspects of the problems at hand. Knapp suggests asking the team: “Why are we doing this project? Where do we want to be in six months, a year, or even five years?” He calls this “starting at the end.” This gets the conversation moving in the right direction—what is the ultimate objective and what’s standing in the way?

An important outcome of Monday is to listing the questions to be answered in the sprint, identifying what has to be true to meet our long-term goal, and thinking about what might result in project failure. With the long term goal and sprint questions identified, the team will move on to map their customer’s journey. Next, experts bring their perspective to the questions and map: strategy, voice of customer, the solution (how things work), and history (previous attempts to solve this problem).

From these raw materials, the team will pick the target for the sprint. The target consists of the target customer and the target moment. Although the team has input and votes, it’s the Decider’s job to select the target customer and target event.

Tuesday – creating solutions

On Tuesday, the team moves on to solutions. You’ll take the outputs of Monday (definition of the challenge and the target) and create various combinations of solution components.

You’ll begin Tuesday morning by searching for existing ideas you can use in the afternoon to inform your solutions. It’s like playing with Lego bricks: first gather useful components, then convert them into something original and new.

To create these idea mashups each team member will take turns presenting 3 minute lightning demos of their favorite solutions which shed light on the target identified on Monday.

Wednesday – storyboarding

On Wednesday the team takes the solutions which were developed on Tuesday and decides which of them should be prototyped. Today’s activities lead to a storyboard which illustrates the steps you will go through in your prototype.

There are five steps to go through on Wednesday: the art museum, heat map, speed critique, and straw poll. The solutions from Tuesday are hung on a wall to encourage thoughtful contemplation (art museum). Sticky dots are added by team members to various elements of the solutions to create a heat map. The speed critique consists of a rapid conversation by the team about each solution. During the straw poll team members vote to give everyone a temperature check on where the group’s interest lies. The Decider gets three votes with which to affirm or contradict the team’s straw poll.

With the solution selected, the group will create the storyboard that will be converted into a prototype on Thursday. Knapp provides detailed instructions on how to create the storyboard and its format.

Thursday – prototyping

Thursday’s outcome is the prototype that will be tested with customers on Friday. The mindset required to achieve this goal is “faking it”. The team will build just enough to test the key question(s) that were identified earlier in the week. The prototype is intended to be a facade which supports answering the questions rather than a fully working model. The goal is to not fully commit to a solution until the feedback has been gathered.

Prototyping principles to keep in mind are: you can prototype anything you need, prototypes should be disposable, build just enough to learn, and the prototype must appear real. Knapp gives several detailed prototype descriptions to illustrate exactly how much is required to be built to acquire the knowledge to resolve the sprint questions. Prototypes can be physical, virtual, on paper, or a build environment.

the biggest problem is that the longer you spend working on something…the more attached you’ll become, and the less likely you’ll be to take negative test results to heart.

Friday – testing

On Friday, the team interviews customers and learns by watching them use and interact with the prototype that was built on Thursday. Jakob Nielsen says that five is the magic number of users you need to identify the most important learnings from a prototype. Knapp also provides a five step interview framework which starts with a welcome to the interviewee, open-ended contextual questions, overview of the prototype, a set of tasks for the interviewee to perform, and a debrief to capture overall impressions and feedback. The book contains lists of questions and interviewer tips.

During the interviews, the entire team watches and takes notes. The interactions and feedback from real users will help answer the questions identified on Monday and guide the team to the next step. Sometimes the prototype will be successful, other times it will not. In any case, the learning is invaluable as the team will be experiencing direct input on big problems they are facing.