PDF Summary:Sprint, by Jake Knapp, John Zeratsky, and Braden Kowitz

Do you have a product idea you want to test, but you’re not sure if it’s worth the time and the effort? Are you stuck in the middle of a project that seems to be going nowhere? If so, Jake Knapp’s Design Sprint process can help. Knapp developed the Design Sprint while working at Google Ventures, the investment arm of Google’s parent company. His process allows you and your team to build and test a prototype in just a five-day work week. With the help of John Zeratsky and Brian Kowitz, Knapp ran hundreds of successful sprints at Google and other companies like Lego, Airbnb, and Slack.

In this guide, we’ll break down Knapp’s step-by-step process for completing your own sprint. In our commentary, we’ll teach you about the business principles behind the Design Sprint and give you tips on how to make every step of your sprint as successful as it can be.

(continued)...

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.)

Step 4: Take Notes and Organize Them Into Themes

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:

• Observation: It’s hard to make a web-based recommendation tool feel personalized because there’s no real human interaction involved.
• Question: How might we introduce a personalized human element into an online recommendation tool?

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.

Step 5: Narrow Your Sprint’s Focus

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.)

Day 2: Creating a Design

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.

Step 1: Gather Inspiration

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.)

Step 2: Draw Your Ideas

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.

Part 1: Review Information and Take Notes

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.)

Part 2: Put Your Thoughts on Paper

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.)

Part 3: Create 60-Second Design Drawings

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.)

Part 4: Finalize Your Best Design Idea

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.)

Step 3: Start Recruiting Interviewees

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.

Day 3: Making Decisions

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.

Step 1: Select a Design

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.

Step 2: Storyboard the Prototype

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.

Day 4: Creating the Prototype

Wednesday was decision day—now, it’s time to use the storyboard you created to build your prototype.

Step 1: Understand the Prototype’s Purpose

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.

Step 2: Choose Your Roles and Start Building

Before you begin building, divide responsibilities for the creation of the prototype. Knapp, Zeratsky, and Kowitz recommend filling the following roles.

• One or two people make the individual components of the prototype. The authors suggest designers and engineers for this role.

(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.)

• One person links the component parts into one cohesive product.

(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.)

• One person writes any text necessary for the 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.)

• One person gathers any media (sounds, images, sample content, and so on) that can be borrowed for your prototype.

(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.)

• One person writes the customer interview script on Thursday and conducts the interviews on Friday. In order to be as unbiased as possible during the interview process, Friday’s interviewer shouldn’t work on the prototype itself.

(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.)

Day 5: Testing the Prototype

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.

Step 1: Set the Stage

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.

Step 2: Put Your Product to the Test

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.)

Step 3: Review Your Results

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.