How can you truly understand what your customers want? What’s the most effective way to gather and use customer feedback in product development?
Product development teams often miss crucial customer insights due to ineffective discovery practices. In Continuous Discovery Habits, Teresa Torres outlines a comprehensive product discovery process that helps teams better understand and serve their customers.
Keep reading to learn how to implement a product discovery process that transforms customer feedback into successful solutions.
Step 1: Learn About Your Customers
The first step in the product discovery process is to learn about your customers through interviews. Torres explains that, without discovery practices, companies will be unable to keep up with customer needs and desires. Therefore, to maintain a practice of ongoing discovery, companies should interview customers no less than once a week.
However, a challenge with customer interviews is that customers usually aren’t very good at describing their own behavior. Their thinking is constrained by cognitive biases and a lack of understanding of what could be different. For example, a customer might say they base their decisions about which laptop to buy based on how much memory it has, but in reality, the computer’s appearance may have a greater impact on their purchasing habits.
Story-Based Interviewing
Because of the difficulties customers have in describing their behavior, Torres advocates story-based interviewing rather than asking direct questions about behavior. This involves asking customers to share specific, recent experiences rather than general observations. For example, instead of asking them what features they look for in a new laptop, ask them to describe the last time they bought a new laptop. As they describe it, dig into their story further with timeline-based questions, such as prompting them to start at the beginning, then asking what happened next, and so on.
Once you’ve gathered all this information, have your three-person product development team reflect on it and draw conclusions about customer needs and wants. From there, determine what problems you want to address and what end goal you want to achieve. This will lead you to your next step: brainstorming solutions.
Step 2: Brainstorm Solutions
The second step in the product discovery process is to brainstorm solutions. Torres points out that product development teams often already have a few ideas compiled for solving issues they’ve noted. However, these tend to be the first or second solutions they’ve thought of, and research shows that our first ideas are rarely our best ones. Instead, it’s important to generate many ideas in order to stimulate the creative process and come up with the best solution.
Torres argues in favor of switching between brainstorming as individuals and brainstorming as a group. Research shows that individuals tend to come up with more ideas—and more creative ones—than people working in groups. However, individuals can sometimes get stuck, which slows progress. By brainstorming individually first, then coming together and sharing ideas as a group, product development teams can achieve optimal productivity and creativity in coming up with solutions.
To put this process into action, alternate between individual and group brainstorming until you have at least 15 ideas. Then, take multiple group votes, gradually eliminating the least popular solutions, until you’re down to three. You’ll examine these solutions more closely in the following steps, beginning with the assumptions that underpin them.
Step 3: Identify Your Assumptions
The next step in the product discovery process is to identify the underlying assumptions behind the decisions you’re making—assumptions you’re likely unaware of. Every assumption you make represents a risk that your solution won’t succeed. You may have come up with three solutions that seem promising. But, if they’re based on faulty assumptions, they’ll be doomed to failure.
Torres outlines five key categories of assumptions that product teams need to consider: Desirability assumptions relate to whether customers want and will value the solution. Viability assumptions concern whether the solution makes business sense and will provide adequate returns. Feasibility assumptions address whether the team can build the solution from both technical and organizational perspectives. Usability assumptions examine whether customers can use the solution. Ethical assumptions consider potential harms and negative impacts of the solution.
Story Mapping to Identify Assumptions
To uncover your underlying assumptions, Torres recommends using story mapping. Story mapping involves laying out each step users need to take to get value from a solution, which helps reveal underlying assumptions at each step. To do this, note which people or entities need to interact for the customer to access your solution and map these out chronologically. Then note any assumptions you’re making at each stage of these interactions.
For example, if you’re developing a video game, your important people and entities could include the customer, the games store, and the console the customer uses. The interactions could be as follows: 1) The customer goes to the online game store to look for something to buy. 2) The game store shows your game as purchasable. 3) The customer buys the game. 4) The customer plays the game on their console. At Stage 1—the customer visiting your online store—you might be assuming that customers want the type of game you’re offering—a desirability assumption. At Stage 2, you’re assuming the customer knows how to navigate the game store—a usability assumption. There’ll also be other assumptions for Stages 3 and 4.
You may not need to go through the whole story-mapping process every time. Torres explains that, as teams develop their skills at spotting assumptions, they may naturally move away from using formal methods. The key is to use whatever methods help address the team’s particular blind spots, as most teams tend to have biases toward certain categories of assumptions while overlooking others. For example, the product development team in our video game example might be adept at spotting desirability assumptions—knowing what will appeal to gamers—but struggle with viability assumptions, leading them to try to add features that can’t be supported with current technology.
Step 4: Test Your Assumptions
Once you’ve identified your assumptions, test them one at a time. Torres says your goal is to assess whether you have sufficient evidence to believe that an assumption is true. If you don’t, you’ll need to remove that assumption from your decision-making process and revise your product development pipeline accordingly. This helps you mitigate your risks and ensure you’re making the best, most well-thought-out product development decisions possible.
To test your assumptions, Torres recommends that you simulate a customer experience. Rather than asking customers what they would do hypothetically, recruit customers to participate in simulations where they can demonstrate actual behavior. These simulations should be kept minimal, focusing only on the specific moment needed to test the assumption. You also need to decide in advance what type of results will serve as the evidence you need so you know what to do with the data as you’re gathering it.
Torres advocates starting with small-scale tests before moving to larger experiments. While small tests may result in false positives or false negatives, these risks are generally acceptable because the cost of being wrong is relatively low. She explains that product teams aren’t conducting scientific research—they’re trying to mitigate risk and create value for customers. Therefore, while teams should adopt scientific thinking, they don’t need the same level of rigor as academic research.
Returning to our video game example, you might decide to test your first assumption (that customers want the type of game you’re offering). You decide that, to verify that this assumption is true, at least four out of 10 simulation participants need to choose your game type over other game types. You carry out your simulation by presenting participants with a list of games available to purchase. If your game is a first-person shooter, but the participants in your simulation only purchase platform games and puzzle games, you have evidence that your assumption may be wrong. This represents a risk in your solution idea, which you should take into account as you continue to make product development decisions.
Step 5: Evaluate Effectiveness of Discovery
Now that you’ve gathered all this discovery information, you can apply it to product development. At this stage, you’ll start doing your delivery work in tandem with your ongoing discovery work. While some view delivery and discovery as separate processes, Torres argues that discovery and delivery are deeply intertwined—discovery work often requires some delivery to test assumptions in a real environment, and delivery work generates new insights that can be fed back into discovery.
Torres says that, in this last step in the product discovery process, you’ll measure how effective your solutions are in meeting your customers’ needs and wants and use that information to refine your product. The key here is to evaluate how effective your assumption tests are using real-world—rather than experimental—data collection. You’re putting your solutions into action and assessing whether they’re bringing you closer to your end goal. Torres emphasizes that teams shouldn’t try to measure everything right away. Instead, they should begin by identifying what metrics are needed to evaluate their current assumption tests.
One important distinction she makes is between measuring the number of people who take an action versus the number of actions taken. She explains that the choice depends on whether value comes from many people taking an action once or fewer people taking an action multiple times. In our video game example, you might measure the views you get for your game in the online game store. Since most people won’t buy multiple copies of the same game, the number of people who view your game will likely be the most useful metric. On the other hand, if you’re trying to evaluate the usefulness of a new in-game mechanic to see how often players will use it, the total number of actions will probably give you the best insight.
Choose what metrics will help you measure the effectiveness of your tests, integrate your delivery and discovery work so you can apply what you learn in each process to the other, and repeat the cycle. This, in combination with the other steps listed above, is how you can embody the process of ongoing discovery.
