Do you have an idea for a product, but you’re not sure how to turn it into a testable prototype? Maybe you’re not even sure it’s worth pursuing at all. Well, using Jake Knapp’s Design Sprint process, you can build and test prototype products within a five-day work week, helping you determine your idea’s viability quickly and cheaply.
Jake Knapp invented the Design Sprint process while working for Google. After moving to Google Ventures (GV), he facilitated sprints with over a hundred companies, including Slack, Airbnb, and Spotify. Designers John Zeratsky and Braden Kowitz collaborated with Knapp at GV to refine the process, and Zeratsky and Knapp later co-authored a book on time management, Make Time. All three are experts in efficiency, productivity, and team improvement strategies.
(Shortform note: At its most basic level, a Design Sprint is a set amount of time in which a team works on a set of tasks to create a testable version of a product. Sprints gained their name due to their short duration and the high intensity of the work involved.)
In this guide, we’ll show you what to do on each day of your sprint in a step-by-step format. In our commentary, we’ll teach you about the underlying principles behind the Design Sprint and provide examples of a sprint in practice.
(Shortform note: The authors organize their information about sprints into a day-by-day guide. This is arguably the most effective structure because each day's tasks build on the day before, creating a smooth progression from planning your prototype, to building it, to testing it. Within each day, we’ve broken down the authors’ instructions into clearer steps and added new examples to more clearly illustrate the chronology of each day’s activities.)
The Evolution of the Design Sprint: Its Roots in Design Thinking
One source of inspiration Jake Knapp found for his Design Sprint process was IDEO’s design thinking workshops. The Design Sprint follows many of the same principles as design thinking: a process designers use to understand the needs of users, solve design problems, and develop products and services.
Like the Design Sprint, design thinking is an iterative process. This involves creating many versions of the same idea and improving your idea using the information you gain from each iteration. Ultimately, design thinking can be broken down into two parts: identifying a problem and developing a solution.
A design thinking process cycles through four phases, which repeat as many times as is necessary to create the best product.
First, there is the observation phase, when designers gather information about the customers who’ll use their product.
Second is the idea generation phase, when designers come up with as many solutions as they can to the problem they want to solve with their product.
Third is the prototype phase, when designers create sketches and models of the best ideas generated in the second phase.
Fourth is the testing phase, when designers have their target customers test the prototype product and give feedback.
A sprint goes through one cycle of these phases: A series of multiple sprints, each testing different iterations of the same product, would look more like a typical design thinking process. Another distinction between design sprints and design thinking is that sprints follow a strict schedule, which is not always required for a design thinking cycle.
According to Knapp, Zeratsky, and Kowitz, the success of your sprint will depend on your preparation of four elements: deciding which idea you want to test, getting the timing right, having the right people in the room, and creating an optimal space for your sprint.
To get started, the authors suggest figuring out which idea you want to develop and the problems you need to solve in your sprint. For clarity’s sake, when we refer to an “idea” in this guide, we mean the idea that will eventually become the prototype product you test at the end of the week. When we refer to “problems,” we mean the problems you need to solve to develop your idea into a workable design. The authors argue that you can test practically any idea or problem in a sprint.
For example, say you work for a restaurant that wants to test out a new order kiosk. Your ideas would be the elements of the kiosk itself, like the design of the menu or the shape and size of the screen. The problems you face might be how to make the kiosk user-friendly, or how to entice customers to use it in the first place. You’d need to figure out how to make your order kiosk accessible and desirable before the design can come together.
Does Your Idea Fit the Scope of a Sprint?
Knapp, Zeratsky, and Kowitz state that you can test almost any idea in a design sprint, but other designers disagree. In one designer’s experience, you need to answer several questions before you can determine whether running a sprint for a certain idea is worth your time:
Is the company as invested in the product idea as you are? If there is little interest from company leadership, they may not implement the results you get from your sprint. In this case, the time and energy spent on the sprint wouldn’t be worth it.
Has the company worked on the same idea before? If your company has already tried (and failed) to develop the idea you want to test, Jansen says it’s a good indicator that they’re willing to see the project through. They’ll be open to the alternative solutions you might find in your sprint. If they’ve never considered the idea before, it isn’t part of their larger plans, and they may be unwilling to commit to a sprint.
Is your company open to the process of discovery in a sprint? You learn new things about your product with every step of a design sprint. By the end, customer feedback may lead you to results you never expected. If your company already has a specific vision for a product that they’re unwilling to deviate from regardless of the feedback they receive, that product is probably not the best choice for a sprint.
Next, familiarize yourself with the sprint’s timeline. After a lot of testing, Knapp discovered that five days (Monday through Friday) works best for design sprints. It’s enough time to create a prototype but not long enough for people to lose momentum and focus.
(Shortform note: Jake Knapp may have invented the Design Sprint and settled on its specific five-day timeline, but he didn’t invent the idea of sprints altogether. Traditional sprints were developed as a tool for agile project management in the 1990s by the creators of Scrum, a framework that helps teams structure projects to encourage reflection, experiential learning, and constant improvement. Scrum sprints can be one to two weeks long, during which a team completes a set of previously specified tasks. They’re still widely used, especially by software developers.)
Each day of your sprint starts at 10:00 am and ends at 5:00 pm, broken up by an hour-long lunch. (The exception is Friday, which starts at 9:00 am to give enough time to complete five customer interviews.) The six working hours of a sprint are shorter than an average workday to compensate for the intense and focused nature of the tasks.
Product Development Processes: Sprints vs. Working Backward
Some critics argue that the constraints imposed by the shortened timelines of “agile” approaches like sprints suppress growth potential in new products, limit the designers’ ability to improve existing products, and make data from customer testing unreliable due to the use of underdeveloped prototypes.
One alternative to sprints is a “working backward” approach—coming up with a fully-realized product idea and sticking to that idea as you work to make it a reality. This method is less flexible than sprints, but it lacks the same time constraints and allows companies to plan longer-term projects with products they may not have the capability to make or prototype yet. Some companies combine the two approaches, deciding which one is best to use at different stages of product development.
According to Knapp, Zeratksy, and Kowitz, your sprint team should have no more than seven members. Having more than seven hinders the decision-making process and makes it difficult to maintain the group’s attention. Start by picking two essential roles, which they call the Decider and the Facilitator. For clarity, we’ll call them the team leader and the sprint coordinator.
When choosing the rest of your team, include designers and engineers who understand how your products are actually made. However, these shouldn’t be the only members of your team. People with other expertise—like a finance specialist who knows how a project is funded or a marketing associate who handles social media—can offer valuable context for the design process. The more diverse your team is, the more innovative solutions you’ll discover.
Creating a Healthy Team Environment
Here, the authors place great emphasis on finding specific members for your team and filling specific roles. However, in Smarter Faster Better, Charles Duhigg argues that selecting the individual members isn't the most important factor for building an effective team. Rather, teams produce the best results when there’s an environment of psychological safety, regardless of who’s in the group and what their specific role is. All members of your team need to feel like they can share their ideas and opinions without facing the possibility of reproof or humiliation.
Duhigg suggests you foster psychological safety in two ways. First, give all members of the team an equal amount of time to speak during group discussions to show that no single person’s input is more important than another’s.
Second, practice social sensitivity by noticing and acknowledging the emotional cues of your team members, like body language and tone of voice. If you notice that a team member seems frustrated or hesitant about something, for example, encourage them to voice their feelings. This will show each individual that the team respects their emotions and opinions, and it will help you address points of conflict as they arise.
The authors suggest that, prior to your sprint, you book a room you can use for the whole week. Don’t move spaces during the sprint. You’ll also need to reserve a second space to conduct customer interviews on Friday.
Devices such as laptops and cell phones should be off-limits during your sprint to ensure that your workspace is as distraction-free as possible. You can always check your phone during breaks or step out if you need to make a call.
(Shortform note: It may seem like a big ask to have people keep their phones off for an entire work week, but the possibility of distraction is real. A 2019 study found that, on average, Americans check their phones 96 times a day, or about once every 10 minutes. Every break in your attention takes you away from the task at hand, limiting your potential for productivity. To avoid temptation, ask yourself why you want to pick up your phone every time you feel the urge. Is it something that really needs your attention now, or are you trying to distract yourself from what’s happening in the present moment?)
How to Create a Productive Workspace
You have to get a lot done in a short amount of time during your sprint, so it’s important that you create a workspace that’s conducive to productivity. First, your room should be comfortable and spacious since you’ll be spending a lot of time there. With enough space, people will have opportunities to stand up, walk around, and stretch during the day. Even a small amount of movement during a workday has proven benefits for mental and physical health.
Additionally, choose a room that has plants in it, or bring some in to have in the room during your sprint. Studies show that having greenery in your workspace helps to reduce stress, promote creativity, and increase productivity.
Finally, keep your sprint room tidy and clean. The more organized your space is, the better you’ll be able to focus.
Now that you’ve prepared for your sprint, on Monday, Knapp, Zeratsky, and Kowitz suggest identifying a goal for your project and the questions you want your sprint to answer. You’ll also plan a customer’s experience with your product, from their first encounter with it through the full process of using it.
The authors say to start off Monday by deciding on a goal with your team. It can be as broad and lofty as you want. When choosing your goal, think about the purpose of your project and what you hope it will achieve in the near and distant future. The information you learn from your sprint will help you progress toward this long-term aspiration.
For example, say there’s a team from a bookstore who are using their sprint to develop a prototype for a personalized book recommendation feature on their website. Their broader, long-term goal is to create a personalized online retail experience for their customers. Creating a successful recommendation tool would be one step toward reaching that goal.
(Shortform note: Other authors also advise starting the development process with clear goals for your product’s future. Marty Cagan (Inspired) calls this your “vision” in his product discovery process. To create a strong vision for your product, he suggests defining a clear “why”: You need to articulate why you think your product will be successful. Additionally, don’t be afraid to dream big. If your vision isn’t ambitious, it probably isn’t worth pursuing. Your vision should excite and inspire every member of your team.)
After you’ve identified your goal, the authors note, you must consider the challenges that could prevent you from achieving it. Identifying these now will help ensure that you’re not surprised by a new obstacle later on in the design process. On a whiteboard, rework these challenges into a short list of questions you want to be answered by the end of the sprint.
For example, one challenge of the bookstore’s recommendation tool could be its algorithm not picking up on the subtler qualities of books that make spontaneous, creative recommendations from a bookstore employee so special. The question related to this problem would then be, “Can an automated recommendation service provide the same quality of recommendations as a bookstore employee?”
Acknowledging Biases Can Help You Avoid Failure
Other experts offer advice for companies who want to avoid project failures created by unexpected challenges. Like Knapp, Zeratsky, and Kowitz, one psychologist suggests that you think about the future of your project and identify the challenges most likely to lead to failure. After you do this, you should also analyze the cognitive biases that might be affecting your perception of these potential challenges.
One example of a common cognitive bias that might impact your perception of challenges is overconfidence. If you’re overconfident about the direction of your project, you might underplay challenges, thinking they’re less likely to occur than they truly are—or, you might believe that their impact will only be minor. When the challenges impact your project more severely than anticipated, you’ll be blindsided and find it harder to adapt.
Therefore, if you notice you’re overconfident, spend time looking at your project more realistically, identify all possible challenges that might occur, and estimate the true probability that they’ll occur.
After you identify your goal and questions, the authors instruct you to create a flowchart that leads you through each step of a customer’s ideal experience with your product. Start with the moment the customer first encounters it and conclude with the result you intend to achieve.
On a whiteboard, start by listing all the people who might use the product on the far left. This may just be one type of customer, or there may be several different types of people who’ll use the product. For example, the bookstore might include two types of people on its list: customers who frequent their physical bookstore and customers who don’t.
On the far right, write the end result you want to achieve, or where you want your customer to end up. The customer using the bookstore’s recommendation tool would ideally end up buying the books recommended to them, so that would be the last step in the flowchart.
In between, write the steps that your customer will have to go through to get to the end result. Connect them with arrows to show how each step leads to the next. For instance, the bookstore’s first arrows would lead from each customer. For the bookstore regulars, the first step might be talking to a store employee and learning about the online recommendation tool. A customer who rarely goes to the store might find their website directly through an internet search or through social media. Once both customers have arrived at the store’s website, the steps would be the same: Click on the recommendation tool, input book preferences, receive customized recommendations, and finally, buy some books.
Expanding Your Flowchart
In the planning stage of his product discovery process, Marty Cagan also suggests you map out the activities required to use your product in a flowchart from left to right. However, he includes the added step of listing the tasks needed to complete the activity under each point on your flowchart. The longer this list is, the more complex the step is.
The length of the list can indicate where the customer might have the most difficulty when using your product. For example, in the bookstore’s recommendation tool, the step where customers input multiple book preferences would have more tasks under it than the step where customers buy the books. Since inputting book preferences involves more tasks, there are more opportunities for a customer to encounter difficulties in this step, whether with the instructions or the technology involved in the tool.
Once you’ve created your flowchart, your next task is to organize short interviews with anyone who might have insights to offer on your project. Knapp, Zeratsky, and Kowitz argue that no one person understands everything it takes to create and sell your product, so this time gives the whole team a chance to hear from every knowledge specialty represented at your company. By the end, every member of the team should have a well-rounded understanding of what’s involved in the development of your product. Through your questioning, the interviewees should close any gaps of knowledge about the project and point out places where the materials you developed earlier in the day can be improved.
Advice on Seeking Advice
How can you ask your (likely already busy) colleagues for their advice while being respectful of their time—and, how can you ensure the interview is a positive experience for them? Here are some tips on making the experience more pleasant, respectful, and valuable to your interviewees.
First, when you approach a colleague you want to interview, ask them for their help using a positive, friendly tone to show you respect their expertise and their time. Be transparent about the amount of time your interview will take. Additionally, be clear about the kind of advice you’re seeking, and let the other person know what to expect during the interview. Tell them up-front that you’ll require their counsel on your team’s design problems.
After the interview is done, make sure to thank the interviewees for their help. Send a follow-up email thanking them again the next day and keep them apprised of how you use their advice to improve your product. This will both show your appreciation and show them that their advice was valuable.
The authors recommend interviewing at least one person from inside or outside your team in each of the following spheres of expertise.
Your sprint’s team leader. As a high-ranking member of your organization, they understand how the project fits into the context of your company’s larger plans. Their interview can help you refine your big-picture strategy as you move forward in the design process.
(Shortform note: If you’re the leader of your sprint team, help your team further understand the “why” of your project during your interview. Knowing the reasoning behind a project—what problem it will fix, who it will help, how it will benefit the company, and so on—can make the hard work of a sprint feel worth it because you’re working toward a bigger purpose. As the leader, you need to clearly demonstrate that you believe the project is worth pursuing. Your confidence will encourage enthusiasm in the other team members, helping your team to achieve success.)
Someone who has worked on the same project or a similar project before. They can offer information about past successes and failures, and they may already have solutions to some of the problems you’re trying to address.
(Shortform note: Use this interview to benefit from someone else’s failures in particular. Failure can be a great teacher. Past missteps give you important data not just about what didn’t work but also about why something didn’t work. This allows you to build off old ideas without making the same mistakes.)
People who understand how the different parts of the product work. This might include people who design the product’s components, people who market the product, or people who work on the technology involved—anyone who can help you understand how these different pieces make one cohesive whole.
(Shortform note: While Knapp, Zeratsky, and Kowitz stress the importance of gaining insight from all team members who understand the product, Cagan argues that designers and engineers have a unique understanding in this area: Product designers can answer questions about how your product will be unique to the user, what competing products exist, and how to ensure the product is enjoyable to use. Engineers create the coding and machinery of a product, so they can answer questions about its inner workings and the realistic scope of your project.)
Someone who frequently interacts with customers, like sales associates or customer service representatives. They can give insights into the real, everyday customer’s perspective and wants, not just those of an ideal customer.
(Shortform note: Salespeople have the best understanding of customers' wants and needs because their jobs depend on it. To be successful, they have to identify your product’s ideal customer and understand what problems your product solves for this customer. To do this, they have to constantly gather new information through outreach, surveys, interviews, and gatherings, so their knowledge of the customer is always evolving.)
As you’re listening to the interviewees, the authors advise that all members of the team should write compelling points they hear on sticky notes: primarily things the team needs to reconsider or add to the flowchart and list of questions.
Write each observation as a question on its own sticky note, starting with the phrase “How might we…?”. This phrasing places emphasis on the opportunity for growth and solutions, rather than the prevalence of problems and challenges. Here is an example of what this might look like for the bookstore team:
When the interviews are over, have all members of the team place their How Might We sticky notes on a wall in any order. Then, work together to reorganize the notes into themes. Let the themes appear naturally, rather than naming them before you start organizing the notes.
Give each team member two dot stickers (except for the team leader, who gets four). Place your dots next to the How Might We questions that seem most important to address. Take all of the sticky notes that have multiple dots on them and place them on your customer experience flowchart next to the step they best apply to.
The History and Importance of “How Might We…?”
The How Might We (HMW) method of questioning was invented by business consultant Min Basadur in the 1970s. Basadur created this method while consulting for Procter & Gamble (P&G). The company was trying to create a better version of rival Colgate-Palmolive’s Irish Spring soap, and Basadur had them ask the question, “How might we create a refreshing soap of our own?” After that, the P&G team started generating hundreds of ideas, and the How Might We method was formed. Since then, companies like IDEO, Facebook, and Google have employed How Might We questions to solve problems and spark innovation in their own projects.
The method is consistently successful and popular because of its intentional structure. The “how” acknowledges that it’s possible to answer whatever question you’re asking. The “might'' introduces flexibility—your solutions might succeed in answering the question, or they might fail. The phrasing is purposefully neutral to allow for any outcome. Finally, the “we” makes it a collective process, indicating that you and your team will work together to solve the problem—even if, as in the authors’ process here, one person makes the ultimate decision about how to proceed.
The last task Knapp, Zeratsky, and Kowitz outline for Monday is choosing a step on your flowchart and a type of customer to focus on during your sprint. The distribution of the How Might We notes on your flowchart should be a visual indicator of where you need to place your priorities. That said, your team leader will ultimately decide which moment and which customer to focus on.
For example, the bookstore team might choose the moment the customer receives their automated recommendations as the point of focus on their flowchart. This is the point where it’s most important to replicate the customer’s interaction with a bookstore employee, maintaining the quality of the recommendations and the reasoning behind them. Their target customer would be their regulars from the physical store. They need to be able to compare the customers’ experiences with associates in the store to their experience with the online tool.
(Shortform note: The authors assert that the placement of the How Might We notes on your flowchart can help you prioritize where to target your efforts during your sprint, but they don’t explain exactly how. Consider this: Do any steps on the diagram have multiple sticky notes attached? If they do, that means you have several questions to address for this step, so it’s an ideal area in which to collect data about the customer’s experience with your product.)
On Monday, you narrowed down your priorities. Now you know where you’ll focus your attention during your sprint. On Tuesday, Knapp, Zeratsky, and Kowitz suggest you gather inspiration for your idea, create a drawing of your best design idea, and begin recruiting customers for Friday’s interviews.
The authors argue that every good idea builds off of what came before, so you’ll start on Tuesday morning by gathering inspiration from other products and services. Every team member should make a list of products, either from your company or from another, that have features you can emulate in your own product. In short presentations, each person will explain the contents of their lists. As people present, record every product mentioned with a little sketch and blurb explaining what inspiration it has to offer.
(Shortform note: Drawing from other people’s products to create your design may feel strange. It may even feel like stealing. To get better as a designer, however, you have to study the products you admire to understand what makes them so successful. If you synthesize the successful elements you identify with your own ideas and experiences, you can create an original product with its own unique value. This doesn’t mean copying or even refashioning. It means adding your perspective to an existing conversation.)
Once you’ve reviewed your outside examples, it’s time to start drawing concrete designs for your product. Knapp, Zeratsky, and Kowitz outline a four-part process that each team member will complete individually on Tuesday afternoon. You will refine your ideas more with each part.
The Perils of Group Brainstorming
After holding many workshops experimenting with group brainstorming methods and getting unimpressive results, Knapp found that people generate their best ideas individually. Other research supports this conclusion: When brainstorming is done in a group setting with no structure, people come up with fewer, less unique, and less practical ideas than they do when working alone.
In order to collaborate effectively, you need to know when to generate ideas separately and when to come back together. You might choose to only work as a group when you’re ready to narrow down your individually-generated ideas into a list of the best options for the project’s purpose. Knapp, Zeratsky, and Kowitz demonstrate this by having you first work alone during the design drawing process and then instructing you to critique the designs as a team.
For 20 minutes, the authors suggest you silently review the information collected on the whiteboards. Write down any details from your flowchart, your goal, your questions, and the list of inspirational examples that may contribute to your product’s design. These notes will be a reference of what you’ve developed so far as a group, keeping you aligned with the team’s vision as you draw out ideas for the product.
(Shortform note: There are many different note-taking styles you can adapt to fit your needs during this step. For example, mind mapping can be a useful method for connecting ideas, helping you organize the pieces of information you’ve learned relationally. The Cornell method can help you summarize central ideas and organize them thematically. When you’re taking notes on the materials you’ve created for your sprint, organize the information in whatever way works best for you.)
Now, the authors say, it’s time to start generating ideas for your product design with some loose brainstorming. For another 20 minutes, write or draw any thoughts you have about the product in the form of diagrams, doodles, and text—as the thoughts come, put them on the page.
(Shortform note: In Getting Things Done, David Allen shares some useful tips for brainstorming. First, don’t criticize or limit the ideas you put on paper. This will only stifle your creativity. The quantity of your ideas matters more than the quality at this stage. Second, don’t worry about neatly organizing your ideas during this part of the process. The goal should be getting ideas out of your head and onto the page.)
Now, the authors state, fold a sheet of paper into eight sections. In each section, take 60 seconds to draw a rough design of your product or a component of the product. It’s helpful to do multiple variations of the same idea. These should be more specific than anything you generated in Part 2, but they still don’t have to be polished. This step is meant to challenge you to quickly think of multiple design approaches to the same product.
(Shortform note: The iterative process of this activity uses the same principles as design thinking on a much smaller scale. The more versions you create of an idea, the more you learn, and the better your final product will be.)
Create a final drawing of your idea on three sticky notes in the form of a storyboard. Each panel should show a step required to use the product or a different feature of your design. This should be the best product design you can come up with.
(Shortform note: Drawing your ideas can be helpful in a number of ways. For one, it’s easier to draw some ideas than it is to describe them. Also, drawings are also more ambiguous than written or verbal descriptions, so they introduce the possibility for multiple interpretations of a design. This can lead to new ideas and innovations as you consider your design from someone else’s perspective. Finally, drawing engages a different part of your brain than language-based communication, opening you up to new avenues of creativity.)
By Friday, you’ll need a set of five customers who’ll test your product and who you’ll then interview to gain feedback. Knapp, Zeratsky, and Kowitz recommend beginning the selection process for your interviewees early in the week.
Use a survey to narrow down to five customers. Create survey questions that help you identify the traits you’re looking for in your ideal customer. If you’re looking for people who are already familiar with your company or people who live in a certain geographic area, for example, write survey questions that collect that information. You can entice your customers with incentives, such as Amazon gift cards.
Creating Customer Profiles
The authors offer a lot of good advice on how to recruit customers for your interviews, but you may still be a little unsure how to narrow down the characteristics you want in your ideal customer. It takes some advance planning, but one way to do this is by creating customer profiles, or descriptions of archetypical customers. Geoffrey Moore discusses how to create these profiles in Crossing the Chasm.
First, Moore suggests talking to different people in your company who often work with customers to get a sense of the types of customers you already serve. Using the data you gather, create profiles that include information about the demographics of the customer, their interests and values, their history with your and similar products, and their geographic location. The more profiles you create, the more you will start to see patterns in the archetypes, and you can start to group them into broader archetypes.
Compare the characteristics of the archetypes you uncover to the event and customer you chose to target on Monday afternoon. Which archetype fits these the best? Which characteristics will be most relevant to you when you are gathering data on your prototype? Use this data to narrow down which customers to interview.
After spending Tuesday producing design ideas for your product, you’ll spend Wednesday deciding which one to pursue. In this section, we’ll discuss the authors’ methods for critiquing the final drawings. Once your team leader selects the one you’ll use to inform your next steps, you’ll create a storyboard to plan for Thursday’s prototype.
Knapp, Zeratsky, and Kowitz suggest you start by putting everyone’s final drawings from Tuesday in a row on the wall. These should be anonymous. Give everyone some dot stickers and review the drawings silently. When you see something you like in a design, place a dot next to it. Write any concerns you have on sticky notes and place them below the drawing.
After the review period, the authors recommend critiquing each design for three minutes. The sprint coordinator should speak first, describing the ideas that people have marked with dots. These “ideas” might be someone’s whole design, or they might be certain aspects of a design. If necessary, the team can point out any promising piece of a design that the coordinator didn’t mention.
A person who is not the coordinator will write the team’s observations on sticky notes to place above the drawing. Then, you’ll discuss the concerns and questions the team wrote about the design. Finally, the person who drew the sketch can explain anything the team missed in their drawing.
Each person gets a dot sticker to place next to the drawing they think represents the best design for your product. As with other major choices in the sprint, the team leader gets the final say in the design you choose. This might make the dot voting seem irrelevant, but the team’s votes do matter. If the team leader is struggling to choose between multiple design ideas, the team’s input may be the thing that sways their decision.
Advice for Effective Design Critiquing
During this step, you have to put your drawing up on the wall and stand by as your teammates analyze and critique your best design idea. Hopefully, by this point, Knapp, Zeratsky, and Kowitz’s structure has allowed you to build enough trust with your teammates to make this a less daunting task. However, even in the best of team environments, putting your work up for critique is a vulnerable act.
Adobe has some useful tips for what to do (and what not to do) during a design critique to make the experience as smooth and productive as possible:
Frame feedback in a positive-constructive-positive form, where any constructive critiques are bookended with things you like about the design. Knapp, Zeratsky, and Kowitz deviate from this structure with their critique script, which has you discuss concerns you have with a design after all the positive comments have been made.
Make your feedback as specific as you can. Don’t just say you like a feature of a design, say why you like it. The same applies to things you don’t like. Without your reasoning, your comments are just personal opinions, which aren’t as strong of a contribution to the group’s decision-making process.
If you have a problem with a design, offer a solution that might fix it. Designing your product is a collaborative effort, and you may have insight to offer that the creator of the drawing wouldn’t have thought of.
Keep feedback as objective as possible. Ego and personal relationships shouldn’t factor into your criticism. Luckily, by keeping the drawings anonymous until the creator has a chance to speak, Knapp, Zeratsky, and Kowitz have removed a lot of the potential for personal bias in your sprint’s critique step.
Once your team leader has selected a design, the authors instruct you to draw a more extensive storyboard of your prototype in use (10 to 15 panels on a whiteboard). Start by drawing the moment and the context in which the customer first engages with the product. For example, the first panel of the bookstore’s storyboard could show a web search for the bookstore’s website.
Fill in the other panels with steps that a customer will have to go through to use your product from start to finish. As the authors say, you’re telling the story of what you want to happen during Friday’s tests with customers. For example, the middle panels of the bookstore’s storyboard might include a drawing of each question prompt the customer will be asked before they receive their recommendations. They’d depict the layout of each screen, the important text involved, any images included, and so on. The last few panels might depict the various recommendations the customer received, showing what the profile for each recommended book would look like.
The Benefits of Storyboarding
Storyboards have a long history of use in visual storytelling, from comics and graphic novels to television and film. As Knapp, Zeratsky, and Kowitz attest, they can also be effective product design tools. Here are three benefits of using storyboards in the design process.
Because of its narrative nature, storyboarding connects your design to its real-world context, including the people who will use it and the setting where it’ll be used. This keeps the product connected to the customer’s needs and interests.
Storyboarding allows you to create a visual representation of your product, which is more effective than other forms of description. Images clearly communicate how the product works to people of different backgrounds and knowledge levels.
Storyboarding forces you to consider the sequence and flow of the customer’s experience using your product, keeping you aware of the bigger picture as you design each element.
Wednesday was decision day—now, it’s time to use the storyboard you created to build your prototype.
Use the storyboard as a reminder of the prototype’s components, a guide for its visual design, and a reference for how it’s supposed to function when you test it later in the day. According to Knapp, Zeratsky, and Kowitz, your prototype should be sophisticated enough to create the illusion of a complete product, but not so complicated that you can’t finish it. You can go back and add missing pieces later. For Friday’s testing, all you have to do is create the features that will give you the information you need from the customers.
For example, instead of trying to build a recommendation tool that features every book in their inventory, the bookstore could create a tool that pulls recommendations from a list that has one or two books per genre. The customer would still receive a recommendation based on their choices, but the team wouldn’t have to waste time inputting every title they have in stock.
Marty Cagan’s Four Kinds of Prototypes
Other creators of product development processes agree that you shouldn’t waste time trying to build a complete product in the prototyping phase. In his “product discovery process” for tech entrepreneurs, Marty Cagan discusses four types of prototypes you can create depending on the needs of your project.
1) A prototype that provides live user data. This is a functional prototype that customers can test, so you can collect data on their experience. It’s a less sophisticated version of your product, and it’s good for testing high-risk ideas. This type of prototype is great for a sprint.
2) A prototype that appears to function automatically, but actually requires manual operation. In this case, an engineer performs functions on the back-end that a product claims to do automatically, giving the customer the illusion of function without having to spend time building complicated automated features. You can also build this type of prototype in your sprint.
3) A prototype that shows whether your product idea is feasible. This is especially relevant to engineers working on tech products who aren’t sure whether they can write the code for their product idea. They can figure out whether it’s possible by writing just enough code to know they can finish it. This type of prototype is typically created for the benefit of the engineers, so it likely wouldn’t apply to a sprint.
4) A prototype that’s a non-functional version of your product. This type is for the product development team only, as it just offers a skeleton version of the product for the team’s visual reference. You need to test the functions of your product with customers during your sprint, so you wouldn’t use this type.
Before you begin building, divide responsibilities for the creation of the prototype. Knapp, Zeratsky, and Kowitz recommend filling the following roles.
(Shortform note: Designers and engineers already have the knowledge to build the pieces of your prototype, whether it involves constructing machinery, writing code, or designing processes. Assigning this role to them will eliminate the time required to get someone else up to speed.)
(Shortform note: This role is arguably the most important because it’s the person who allows you to work as a team. Without someone to make sure all the pieces fit together, you’d have to work together on every piece (which would take too long), or you’d have an incomplete, incoherent prototype.)
(Shortform note: Written cues often guide the customer through their experience with a product, so they need to be clear. If the text included is confusing or inaccurate, your prototype will look sloppy and incomplete. The more niche your product is, the more experience your writer should have writing within the conventions of your business or industry.)
(Shortform note: Your company might have a library of content for you to use, but if it doesn’t, there are many websites where you can find fair use materials. For example, you can use a Creative Commons search to find audio and images under fair use, or you can use a Google Advanced Image Search and choose Creative Commons licenses in the usage rights filter.)
(Shortform note: The authors suggest you write a script for your customer interviews. Four to five pages is a good target for a 60-minute interview. Organize your questions to follow the progression of the interview so you aren’t flipping around trying to find the right section when you’re with the customers. That being said, don’t be afraid to deviate from the script if the customers’ observations steer the interviews in a different direction.)
Around 3:00 pm on Thursday, have the person who linked all the pieces of the prototype together present a full run of its use to the team. If any components of the prototype don’t match up with the storyboard, you still have some time to fix them before you go home for the day.
(Shortform note: Make sure to set a hard stopping time for these final fixes to ensure you can get home and have plenty of rest. As we're about to discuss, the final day of a sprint is intense, with multiple customer interviews to conduct, and you'll need to be well-rested and energetic to make the best impression on the customer.)
By Friday, you’ve reached the last day of your sprint. This section will show you how to conduct one-on-one interviews with five customers, giving you enough feedback to understand where to take your product next.
According to the authors, you can identify the majority of problems with a product through just five customer interviews. This means they can all be done on the same day. You’ll start at 9:00 am on Friday, and each interview will be an hour long with a half-hour break in between. The person acting as the interviewer will be in one room with the customers and the prototype.
(Shortform note: It may be tempting to jump from one interview to another without taking the full half-hour break in between, but you should use that time to your advantage. Planning breaks in your schedule gives you some padding in case an interview goes over time or the next customer is late. It also gives you some much-needed time to rest and reflect on what you’ve just learned. You can write down a few takeaways if you have key points you want to remember later.)
You’ll need to set up a webcam with video and sound that captures the customers’ reactions, as the rest of the team will be watching the interviews live in the sprint room. (Confirm that the customer is comfortable being recorded and have them sign any necessary legal documents before you proceed.)
(Shortform note: The authors’ methods are designed for in-person customer interviews, but you could adapt their process to suit remote interviews as well, especially if your product is digital. If you’re unable to be in the same room as your customers, there are a number of video conferencing programs you can use to set up your product testing. You can use your chosen software’s features to record each interview live. However, be aware that you’ll have a few added steps during set-up—it’ll be especially important for you to make sure that all of your technology is working and that you understand how to use your software of choice before you begin.)
Engage the customer in small talk to build rapport before gradually beginning to ask questions that tell you how the customer might use your product in their everyday life. For example, the interviewer for the bookstore team might begin by asking a customer about their job or their hobbies and interests. Then, they could start to ask about the customer’s reading habits and experiences with book buying. How do they typically choose their next read? How often do they speak to bookstore employees? Have they ever used an online recommendation service to find books before?
Build Rapport With the Customer Using Active Listening
If customers are hesitant or uncomfortable during your interviews, the quality of the feedback you get from them will suffer. As the authors suggest, it’s therefore important to build rapport with the customer at the beginning of the interview process. One way to do this is to engage in active listening.
A common active listening technique you could use with your customers is to repeat their responses back to them. When you do this, you’re showing them that you care about, and have internalized, what they’re saying. This will help build trust and respect with the customer, increasing the likelihood that they’ll share honest feedback later on.
Repeating responses back to the customer can also help you to clarify their meaning. The method naturally prompts further discussion: If your repeated interpretation of what they said is correct, the customer may expand on their answer. At the very least, they will feel understood. If your interpretation is inaccurate, your response will prompt them to explain further.
Next, the interviewer should introduce the prototype and encourage the customer to begin using it. Knapp, Zeratsky, and Kowitz advise that you don’t tell the customer exactly how to use the prototype—leave them to figure it out for themselves. This will help you see if the product is naturally easy to use or if it has unexpected problems.
(Shortform note: Allowing your customer to explore the product for themselves can also lead to unexpected innovations. According to Marty Cagan, if they’re allowed to explore, customers might use your product in a way you didn’t plan for, revealing a new opportunity for you to expand your market. For example, eBay started as an online marketplace for collectibles and electronics, but soon, people frequently used it to sell larger items like cars. eBay was then able to adapt its service to fit customer demand. This advice may not work if you have a very targeted use for your product, but it’s something to consider as you test your product on Friday.)
As they use the prototype, you can also ask the customer questions about their opinion of different product features, what they think will happen next in the sequence, and what they imagine the purpose of different features will be. After the customer has tested the prototype, have a short discussion with them about what worked, what didn’t, and what they’d change. This is your chance to understand their overall impressions.
(Shortform note: This interview technique demonstrates to the customer that their point of view is important to you. Asking for a customer’s opinion about your product can also be a successful sales technique. Instead of telling your customer that your product is better than a competitor’s (which can put people in a position of defending their current choices), politely ask them to offer their feedback on whatever you’re selling. Play to their expertise—if you’re selling medical supplies to a doctor, emphasize that you’re seeking their opinion because of their experience in the medical field, for example. If your product is truly the superior option, your customer will be more willing to recognize that—and ultimately buy your product—when they’ve been treated with expert status.)
The rest of the team should watch the interviews together in the sprint room. To prepare, draw a grid on a whiteboard with a column for every interviewee and a row for each important component of the prototype. Silently write down quotes from the customers that seem like significant observations and interesting customer reactions on sticky notes. Label them positive, neutral, or negative. As you write your sticky notes, place them in the appropriate boxes on the grid based on the component they refer to.
(Shortform note: The authors advise you to write down important ideas the customers bring up while you’re watching the interviews, but they don’t expand on what “important” actually means. There are a few things you can look out for as you listen. Write down when a customer suggests a feature they think would make the product better—this could help spark ideas for future iterations. Likewise, make a note every time a customer gets confused, so you know which parts of the product require adjustment. Finally, write down any observation that makes you consider your product in a new way or gives you information that helps to answer the questions you wrote at the beginning of your sprint.)
The authors instruct you to silently review the notes on the whiteboard after the interviews, looking for patterns in the feedback. Did several customers comment positively on the same feature? Did several customers struggle during the same step? You can use these patterns to identify places that need improvement or features that worked particularly well.
Then, assess your findings by looking back at your sprint questions and your goal. Did you learn what you were hoping to? If not, what are your next steps? Even if your prototype was a success, the sprint probably still revealed flaws you need to address. Now you have the information you need to do that efficiently and effectively. If you still have questions you want to answer about your product after Friday, or you’re not sure where to take it next, you can always run another sprint. Whatever your results, no sprint is ever a waste of time.
Decide Where to Take Your Product Next
In The Lean Startup, Eric Ries discusses the outcomes that often arise after collecting customer data. Like Knapp, Zeratsky, and Kowitz, he offers two possibilities: You can carry out another iterative cycle to improve your product based on the weaknesses you identified, or you can decide to “pivot” away from your current direction entirely.
If your product turns out to be too problematic to fix, Ries offers a few ways to move forward. First, you can alter your product so it focuses entirely on one feature the customers liked. Alternatively, you can choose to focus on a different need that the customer has, which will likely require you to design a new product. Finally, you can stick with the same customer problem but try to solve it with a different type of product.
You now have all the tools you need to run sprints. Consider how you can use sprints to expedite your current projects.
Think about the projects you’re working on right now. Describe the most important or pressing one here. (An example of a project could be working on a new software update for a planner app, or designing an educational toy for young children.)
What is the long-term goal of this project? List your goal here. (For example, the long-term goal for the planning app project could be to become the number one productivity app in the App Store. The long-term goal of the toy design project could be to make learning fun for kids.)
How could you use a sprint to help move this project toward your goal? What shorter-term step could your sprint work toward, and how would that align with your goal? (For example, maybe the app’s long-awaited new update is supposed to roll out in a month, and a sprint will help the engineers fast-track their progress. Alternatively, maybe the toy designers know their fun new educational design will cost a lot of money to make, and they want to use a sprint to get quick feedback from customers to see if it’s popular enough to pursue.)
Before you start, you have to put together a team for your sprint. Who would you choose for your sprint team and why? What role would you play in your sprint? Remember: Every sprint team needs a leader and a coordinator, as well as members with expertise relevant to your project. (For example, the app’s team would need programmers to code the update’s new features and a marketing professional to advise on the update’s advertising plan. The toy’s team would need designers who’ve worked in the toy industry before and a finance professional to advise on the costs associated with the product.)