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

Metadata
- Title: Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days
- Author: Jake Knapp, John Zeratsky, and Braden Kowitz
- Book URL: https://amazon.com/dp/B010MH1DAQ?tag=malvaonlin-20
- Open in Kindle: kindle://book/?action=open&asin=B010MH1DAQ
- Last Updated on: Friday, April 7, 2017
Highlights & Notes
My best work happened when I had a big challenge and not quite enough time.
The other key ingredients were the people. The engineers, the product manager, and the designer were all in the room together, each solving his or her own part of the problem, each ready to answer the others’ questions.
Good ideas are hard to find. And even the best ideas face an uncertain path to real-world success.
Identifying critical flaws after just five days of work is the height of efficiency. It’s learning the hard way, without the “hard way.”
First, the sprint forces your team to focus on the most pressing questions. Second, the sprint allows you to learn from just the surface of a finished product.
When our new ideas fail, it’s usually because we were overconfident about how well customers would understand and how much they would care.
Get that surface right, and you can work backward to figure out the underlying systems or technology. Focusing on the surface allows you to move fast and answer big questions before you commit to execution, which is why any challenge, no matter how large, can benefit from a sprint.
The Decider is the official decision-maker for the project. At many startups we work with, it’s a founder or CEO. At bigger companies, it might be a VP, a product manager, or another team leader. These Deciders generally understand the problem in depth, and they often have strong opinions and criteria to help find the right solution.
Sprints are most successful with a mix of people: the core people who work on execution along with a few extra experts with specialized knowledge.
This person is the Facilitator, and she’s responsible for managing time, conversations, and the overall process. She needs to be confident leading a meeting, including summarizing discussions and telling people it’s time to stop talking and move on.
We’ve found that magic happens when we use big whiteboards to solve problems. As humans, our short-term memory is not all that good, but our spatial memory is awesome. A sprint room, plastered with notes, diagrams, printouts, and more, takes advantage of that spatial memory.
Get two big whiteboards At minimum, you’ll need two big whiteboards. That will provide enough space to do most of the sprint activities (you’ll still have to take photos and do some erasing and reorganizing as you go) and enough to keep the most important notes visible for the entire week.
Starting at the end is like being handed the keys to a time machine. If you could jump ahead to the end of your sprint, what questions would be answered? If you went six months or a year further into the future, what would have improved about your business as a result of this project?
Set a long-term goal To start the conversation, ask your team this question: “Why are we doing this project? Where do we want to be six months, a year, or even five years from now?”
Your goal should reflect your team’s principles and aspirations. Don’t worry about overreaching.
Once you’ve settled on a long-term goal, write it at the top of the whiteboard. It’ll stay there throughout the sprint as a beacon to keep everyone moving in the same direction.
You imagined a perfect future. Now it’s time to get pessimistic. Imagine you’ve gone forward in time one year, and your project was a disaster. What caused it to fail? How did your goal go wrong?
Lurking beneath every goal are dangerous assumptions. The longer those assumptions remain unexamined, the greater the risk.
What questions do we want to answer in this sprint? • To meet our long-term goal, what has to be true? • Imagine we travel into the future and our project failed. What might have caused that?
An important part of this exercise is rephrasing assumptions and obstacles into questions.
Your map should be simple, too. You won’t have to capture every detail and nuance. Instead, you’ll just include the major steps required for customers to move from beginning to completion, in this case from cancer diagnosis to trial enrollment.
Each map is customer-centric, with a list of key actors on the left. Each map is a story, with a beginning, a middle, and an end. And, no matter the business, each map is simple. The diagrams are composed of nothing more than words, arrows, and a few boxes.
You should be able to make the first quick draft of your map in thirty to sixty minutes. Don’t be surprised if you continue to update and correct it throughout the day as you discuss the problem.
Your job on Monday afternoon will be to assemble one cohesive picture from everyone’s pooled knowledge and expertise.
Your team knows a lot about your challenge. But that knowledge is distributed. Somebody knows the most about your customers; somebody knows the most about the technology, the marketing, the business, and so on. In the normal course of business, teams don’t get the chance to join forces and use all of that knowledge.
Nobody knows everything, not even the CEO. Instead, the information is distributed asymmetrically across the team and across the company.
To take notes, follow these steps: 1. Put the letters “HMW” in the top left corner of your sticky note. 2. Wait. 3. When you hear something interesting, convert it into a question (quietly). 4. Write the question on your sticky note. 5. Peel off the note and set it aside.
After interviewing the experts and organizing your notes, the most important part of your project should jump right out of your map, almost like a crack in the earth.
Your final task on Monday is to choose a target for your sprint. Who is the most important customer, and what’s the critical moment of that customer’s experience? The rest of the sprint will flow from this decision.
Once you’ve clustered your team’s How Might We notes, the decision about where to focus your sprint will likely be easy. It’s the place on your map where you have the biggest opportunity to do something great (and also, perhaps, the greatest risk of failure).
Pick a target The Decider needs to choose one target customer and one target event on the map. Whatever she chooses will become the focus of the rest of the sprint—the sketches, prototype, and test all flow from this decision.
By Monday afternoon, you’ve identified a long-term goal and the questions to answer along the way. You’ve made a map and circled the target for your sprint. Everyone on the team will have the same information, and everyone will understand the week’s objective. Next, on Tuesday, it’ll be time to come up with solutions.
Remember, the whiteboard is the shared brain of the team. Keep it organized and you’ll help everyone be smarter, remember more, and make better decisions, faster.
On Monday, you and your team defined the challenge and chose a target. On Tuesday, you’ll come up with solutions. The day starts with inspiration: a review of existing ideas to remix and improve. Then, in the afternoon, each person will sketch, following a four-step process that emphasizes critical thinking over artistry. Later in the week, the best of these sketches will form the plan for your prototype and test.
great innovation is built on existing ideas, repurposed with vision.
You’ll begin Tuesday morning by searching for existing ideas you can use in the afternoon to inform your solution. It’s like playing with Lego bricks: first gather useful components, then convert them into something original and new.
Our method for collecting and synthesizing these existing ideas is an exercise we call Lightning Demos. Your team will take turns giving three-minute tours of their favorite solutions: from other products, from different domains, and from within your own company.
On Tuesday, we’re not asking you to sketch because we think it’s fun. We’re asking you to sketch because we’re convinced it’s the fastest and easiest way to transform abstract ideas into concrete solutions. Once your ideas become concrete, they can be critically and fairly evaluated by the rest of the team—without any sales pitch. And, perhaps most important of all, sketching allows every person to develop those concrete ideas while working alone.
We know that individuals working alone generate better solutions than groups brainstorming out loud.I Working alone offers time to do research, find inspiration, and think about the problem. And the pressure of responsibility that comes with working alone often spurs us to our best work.
Strong writing is especially necessary for software and marketing, where words often make up most of the screen.
Each additional sketch means more work reviewing and narrowing down on Wednesday.
Thirty minutes should be enough time for everyone to finish one sketch.
There are two ways to find the right customers for your test. If you have fairly easy-to-find customers, you’ll use Craigslist. If you have hard-to-find customers, you’ll use your network.
100 Amazon gift cards. Please complete this short questionnaire. Click here.
After you’ve turned your criteria into questions, create your survey. We always use Google Forms—it’s easy to set up, and the responses go right into a Google spreadsheet that you can sort and filter.
Make sure potential interview candidates match your screening criteria. With only five interviews, it’s important to talk to the right people.
By Wednesday morning, you and your team will have a stack of solutions. That’s great, but it’s also a problem. You can’t prototype and test them all—you need one solid plan. In the morning, you’ll critique each solution, and decide which ones have the best chance of achieving your long-term goal. Then, in the afternoon, you’ll take the winning scenes from your sketches and weave them into a storyboard: a step-by-step plan for your prototype.
We’ve structured Wednesday to do one thing at a time—and do it well. We’ll evaluate solutions all at once, critique all at once, and then make a decision all at once. Kind of like this:
Your goal for Wednesday morning is to decide which solutions to prototype.
1. Art museum: Put the solution sketches on the wall with masking tape. 2. Heat map: Look at all the solutions in silence, and use dot stickers to mark interesting parts. 3. Speed critique: Quickly discuss the highlights of each solution, and use sticky notes to capture big ideas. 4. Straw poll: Each person chooses one solution, and votes for it with a dot sticker. 5. Supervote: The Decider makes the final decision, with—you guessed it—more stickers.
It’s not hard for creators to make great arguments for their mediocre ideas, or give great explanations for their indecipherable ideas. But in the real world, the creators won’t be there to give sales pitches and clues. In the real world, the ideas will have to stand on their own. If they’re confusing to the experts in a sprint, chances are good they’ll be confusing to customers.
Then each person follows these steps: 1. Don’t talk. 2. Look at a solution sketch. 3. Put dot stickers beside the parts you like (if any). 4. Put two or three dots on the most exciting ideas. 5. If you have a concern or question, write it on a sticky note and place it below the sketch. 6. Move on to the next sketch, and repeat.
During the speed critique, the Facilitator is going to be very busy, so someone needs to volunteer to help by being the Scribe.
Try to keep each review to three minutes, but be a little flexible. If a sketch has a lot of good ideas, take a couple of extra minutes to capture them all. On the other hand, if a sketch has very few dots, and the creator doesn’t have a compelling explanation, do everyone a favor and move on quickly. Nothing is gained by tearing apart a sketch nobody likes.
Remember that all you’re trying to accomplish in the speed critique is to create a record of promising ideas. You don’t need to debate whether something should be included in the prototype; that will come later. You shouldn’t try to come up with new ideas on the spot. Just write down what stands out about each solution.
1. Give everyone one vote (represented by a big dot sticker—we like pink). 2. Remind everyone of the long-term goal and sprint questions. 3. Remind everyone to err on the side of risky ideas with big potential. 4. Set a timer for ten minutes. 5. Each person privately writes down his or her choice. It could be a whole sketch, or just one idea in a sketch. 6. When time is up, or when everyone is finished, place the votes on the sketches. 7. Each person briefly explains his or her vote (only spend about one minute per person).
Sometimes when people work together in groups, they start to worry about consensus and try to make decisions that everybody will approve—mostly out of good nature and a desire for group cohesion, and perhaps in part because democracy feels good. Well, democracy is a fine system for governing nations, but it has no place in your sprint.
Deciders can choose ideas that were popular in the straw poll. Or they can choose to ignore the straw poll. They can spread out their votes, or put them all in one place. Basically, the Deciders can do whatever the heck they want.
The sketches with supervotes on them (even just one!) are the winners. You’ll plan your prototype around those ideas and put them to the test on Friday. We like to rearrange the sketches on the wall, so that the supervote winners are all together,
Sometimes, good ideas don’t get selected (at least, not in the first sprint). But the “sticky decision”—if not perfect—is pretty good and very speedy. That speed helps with the sprint’s larger goal: getting real world data from Friday’s test. Ultimately, it will be that data that leads to the best decisions of all.
If you think you can combine your winning sketches into one product, don’t bother with a Rumble. Instead, put them together into your best shot at solving the problem. This all-in-one approach has advantages, too. Your prototype will be longer and more detailed.
If you have more than one winning solution, involve the whole team in a short discussion about whether to do a Rumble or combine the winners into a single prototype. Typically, this decision about format is easy. If it’s not, you can always ask the Decider to make the call.
By lunchtime on Wednesday, you will have decided which sketches have the best chance of answering your sprint questions and helping you reach your long-term goal. You’ll also decide whether to combine those winning ideas into one prototype or build two or three and test them in a Rumble. Next, it’s time to turn all these decisions into a plan of action so you can finish your prototype in time for Friday’s test.
Because of the short timeline, it’s tempting to jump into prototyping as soon as you’ve selected your winning ideas. But if you start prototyping without a plan, you’ll get bogged down by small, unanswered questions. Pieces won’t fit together, and your prototype could fall apart.
On Wednesday afternoon, you’ll answer those small questions and make a plan. Specifically, you’ll take the winning sketches and string them together into a storyboard. This will be similar to the three-panel storyboards you sketched on Tuesday, but it will be longer: about ten to fifteen panels, all tightly connected into one cohesive story.
You’ll start drawing your storyboard in the top left box of the grid. This frame will be the first moment that customers experience on Friday. So … what should it be? What’s the best opening scene for your prototype?
But there are lots of ways to open your storyboard. Flatiron Health wondered if existing users of their software would change their workflow for a new clinical-trial tool. A news article wouldn’t have made much sense. Instead, Flatiron’s opening scene was an email inbox—the place research coordinators would receive notifications from the new system. For Savioke, the opening scene was checking in to a hotel and forgetting a toothbrush. The trick is to take one or two steps upstream from the beginning of the actual solution you want to test.
Web search with your website nestled among the results • Magazine with an advertisement for your service • Store shelf with your product sitting beside its competitors • App Store with your app in it • News article that mentions your service, and possibly some competitors • Facebook or Twitter feed with your product shared among the other posts
It’s almost always a good idea to present your solution alongside the competition. As a matter of fact, you can ask customers to test out your competitors’ products on Friday right alongside your own prototype.
Storyboarding is a simple process, with a ton of tiny decisions along the way. Those tiny decisions can be tiring, but remember—you’re doing your future self a favor. Every decision you make now is something you won’t have to think about when you build your prototypes.
When in doubt, take risks. Sometimes you can’t fit everything in. Remember that the sprint is great for testing risky solutions that might have a huge payoff. So you’ll have to reverse the way you would normally prioritize. If a small fix is so good and low-risk that you’re already planning to build it next week, then seeing it in a prototype won’t teach you much. Skip those easy wins in favor of big, bold bets.
Make sure the whole prototype can be tested in about fifteen minutes.
Sticking to fifteen minutes will ensure that you focus on the most important solutions—and don’t bite off more than you can prototype. (A rule of thumb: Each storyboard frame equals about one minute in your test.)
On Wednesday, you and your team created a storyboard. On Thursday, you’ll adopt a “fake it” philosophy to turn that storyboard into a realistic prototype.
It makes no difference to the audience. For the few minutes we see the town, we get lost in the story. It all appears real. Whether it’s a façade or a ghost town, the illusion works.
But perhaps the biggest problem is that the longer you spend working on something—whether it’s a prototype or a real product—the more attached you’ll become, and the less likely you’ll be to take negative test results to heart. After one day, you’re receptive to feedback. After three months, you’re committed.
To prototype your solution, you’ll need a temporary change of philosophy: from perfect to just enough, from long-term quality to temporary simulation
Once the illusion is broken, customers switch into feedback mode. They’ll try to be helpful and think up suggestions. In Friday’s test, customer reactions are solid gold, but their feedback is worth pennies on the dollar.
This distinction between feedback and reaction is crucial. You want to create a prototype that evokes honest reactions from your customers. You want it to be as real as possible, while sticking to your one-day timeline. As our partner Daniel Burka says, the ideal prototype should be “Goldilocks quality.” If the quality is too low, people won’t believe the prototype is a real product. If the quality is too high, you’ll be working all night and you won’t finish. You need Goldilocks quality. Not too high, not too low, but just right.
When a team has an extraordinary prototyping challenge, they often have the extraordinary skills and tools to make it happen.
1. Pick the right tools 2. Divide and conquer 3. Stitch it together 4. Do a trial run
The trouble with your team’s regular tools is that they’re too perfect—and too slow. Remember: Your prototype isn’t a real product, it just needs to appear real. You don’t need to worry about supply chains, brand guidelines, or sales training. You don’t need to make every pixel perfect.
One of our favorite shortcuts is the Brochure Façade: Instead of prototyping the device, prototype the website, video, brochure, or slide deck that will be used to sell the device. After all, many purchase decisions are made (or at least heavily informed) online or in a sales call. This marketing material will give you a great start on understanding how customers will react to the promise of your product—which features are important, whether the price is right, and so on.
Pick the right tools If you’re not sure how to build your prototype, start here: • If it’s on a screen (website, app, software, etc.)—use Keynote, PowerPoint, or a website-building tool like Squarespace. • If it’s on paper (report, brochure, flyer, etc.)—use Keynote, PowerPoint, or word processing software like Microsoft Word. • If it’s a service (customer support, client service, medical care, etc.)—write a script and use your sprint team as actors. • If it’s a physical space (store, office lobby, etc.)—modify an existing space. • If it’s an object (physical product, machinery, etc.)—modify an existing object, 3D print a prototype, or prototype the marketing using Keynote or PowerPoint and photos or renderings of the object.
Divide and conquer The Facilitator should help the sprint team divvy up these jobs: • Makers (2 or more) • Stitcher (1) • Writer (1) • Asset Collector (1 or more) • Interviewer (1)
Makers create the individual components (screens, pages, pieces, and so on) of your prototype. These are typically designers or engineers, but they could include anyone on your sprint team who likes to feel the force of creation flow through his or her fingers. You’ll want at least two Makers on Thursday.
The Stitcher is responsible for collecting components from the Makers and combining them in a seamless fashion. This person is usually a designer or engineer, but can be almost anyone, depending on the format of your prototype. The best Stitcher is detail-oriented. He or she will probably give everyone some style guides to follow in the morning, then start stitching after lunch as the Makers complete their components.
Every sprint team needs a Writer, and it’s one of the most important roles.
It’s impossible to make a realistic prototype with unrealistic text.
You’ll want at least one Asset Collector on Thursday. It’s not a glamorous role (although “asset collector” does sound glamorous), but it’s one of the keys to rapid prototyping. Your prototype will likely include photos, icons, or sample content that you don’t need to make from scratch. Your Asset Collectors will scour the web, image libraries, your own products, and any other conceivable place to find these elements. This speeds up the work of your Makers, who don’t have to pause and go collect every bit and piece they need for the prototype.
It’s best if the Interviewer doesn’t work on the prototype. This way, he won’t be emotionally invested in Friday’s test, and won’t betray any hurt feelings or glee to the customer.
It’s important to give your opening scene enough time to be credible and set the stage. Don’t spend half your day working on it, but do make it believable.
As individual sections of the prototype near completion, the Stitcher moves in. It’s the Stitcher’s job to make the prototype consistent from beginning to end—and ensure that every step is as realistic as possible.
Don’t mention Jane Smith in one place and Jane Smoot in the other. Look for typos and fix any obvious errors. Small mistakes can remind customers that they are looking at a fake product.
The Stitcher’s job can take many forms, but no matter what you’re prototyping, it’s a critical role. When you divide work, it’s easy to lose track of the whole. The Stitcher will be on the hook to keep everything tight. He may want to check on progress throughout the day, to see if the various parts of the prototype look coherent. And at the end, the Stitcher shouldn’t hesitate to ask the rest of the team to help out if more work is needed.
We like to do our trial run around 3 p.m., so that we still have enough time to fix mistakes and patch any holes we find in the prototype. Have everyone pause work and gather around, and then ask the Stitcher to walk through the entire prototype, narrating as he goes.
As you go, you should double-check against the storyboard to make sure everything made it into the prototype. The trial run is also a great time to revisit your sprint questions. It’s one last check to make sure your prototype will help you get answers.
The primary audience for the trial run is the Interviewer, who will be talking with customers on Friday. The Interviewer needs to be familiar with the prototype and the sprint questions so he can get the most out of the interviews.
If the Decider isn’t a full-time participant in the sprint, now is another good time for a cameo appearance. The Decider can make sure everything matches what she was expecting.
Sprints begin with a big challenge, an excellent team—and not much else. By Friday of your sprint week, you’ve created promising solutions, chosen the best, and built a realistic prototype. That alone would make for an impressively productive week. But Friday, you’ll take it one step further as you interview customers and learn by watching them react to your prototype. This test makes the entire sprint worthwhile: At the end of the day, you’ll know how far you have to go, and you’ll know just what to do next.
You’ll watch target customers react to your new ideas—before you’ve made the expensive commitment to launch them.
Here’s how Friday works: One person from your team acts as Interviewer. He’ll interview five of your target customers, one at a time. He’ll let each of them try to complete a task with the prototype and ask a few questions to understand what they’re thinking as they interact with it. Meanwhile, in another room, the rest of the team will watch a video stream of the interview and make note of the customers’ reactions.
Earlier in the week, you recruited and carefully selected participants for your test who match the profile of your target customer. Because you’ll be talking to the right people, we’re convinced you can trust what they say. And we’re also convinced that you can learn plenty from just five of them.
When all you have is statistics, you have to guess what your customers are thinking. When you’re doing an interview, you can just … ask.
1. A friendly welcome to start the interview 2. A series of general, open-ended context questions about the customer 3. Introduction to the prototype(s) 4. Detailed tasks to get the customer reacting to the prototype 5. A quick debrief to capture the customer’s overarching thoughts and impressions
Asking target customers to do realistic tasks during an interview is the best way to simulate that real-world experience.
Good task instructions are like clues for a treasure hunt—it’s no fun (and not useful) if you’re told where to go and what to do. You want to watch customers figure out the prototype on their own.
Open-ended tasks lead to interesting interviews. Overly specific tasks are boring for both the customer and the sprint team.
As the customer goes through the task, the Interviewer should ask questions to help her think aloud: “What is this? What is it for?” “What do you think of that?” “What do you expect that will do?” “So, what goes through your mind as you look at this?” “What are you looking for?” “What would you do next? Why?”
Here are some of Michael’s debrief questions: “How does this product compare to what you do now?” “What did you like about this product? What did you dislike?” “How would you describe this product to a friend?” “If you had three magic wishes to improve this product, what would they be?”
“How would you compare those different products? What are the pros and cons?” “Which parts of each would you combine to create a new, better version?” “Which one worked better for you? Why?”
Listening to customers didn’t mean abandoning their vision. Instead, it gave them the knowledge they needed to combine with that vision, so they could close the gap and make a product that worked for real people.
Being in a curiosity mindset means being fascinated by your customers and their reactions.
Before the first interview begins, draw a grid on a large whiteboard in the sprint room. Create five columns—one for each customer you’ll be interviewing—and a few rows—one for each prototype, or section of the prototype, or sprint question you’re trying to answer.
During the interviews, the room should be quiet. The interview itself is a time for careful listening and detailed note-taking, not boisterous reactions or problem solving on the spot. It’s also important to be respectful of the customer being interviewed. Even though the customer can’t hear you (the video should stream “one way”) keep in mind that if she struggles with your prototype, it’s your problem, not the customer’s.
You can run a sprint anytime you’re not sure what to do, or struggling to get started, or dealing with a high-stakes decision. The best sprints are used to solve important problems, so we encourage you to pick a big fight.
“It wasn’t luck that made them fly; it was hard work and common sense,” said Daniels. He went on: “Good Lord, I’m a-wondering what all of us could do if we had faith in our ideas and put all our heart and mind and energy into them like those Wright boys did!”
Prototype mindset. You can prototype anything. Prototypes are disposable. Build just enough to learn, but not more. The prototype must appear real.
Goldilocks quality. Create a prototype with just enough quality to evoke honest reactions from customers.
Q: If we’ve just finished a sprint, can our follow-up sprint be shorter? A: Yes. Follow-up sprints are exceptions to the five-day rule. Since you’ll already have a map and a prototype, as well as results from your first test to help you create new solutions and make decisions, you can often accelerate a follow-up sprint. Two things don’t change: You’ll still need a realistic prototype, and you’ll still need to test with five customers.
Q: Can we test with friends and family? A: No. You can only trust the results when you interview customers who match your target profile. Even if your friends and family happen to fit the profile, there’s another big problem: They’re biased, or at the very least they know too much. In your test, you’re looking for honest reactions from real-world customers—something you can never get from someone who knows you.