What drives customers to choose your product over others? How can you create something they truly want instead of just guessing what they might like?
Product development isn’t just about delivering features—it’s about understanding what customers actually need. Continuous Discovery Habits by Teresa Torres presents a practical framework for product teams to connect with customers weekly and transform their approach to creating valuable solutions.
Read more to explore a proven method that has helped companies such as Spotify and Tesco build products their customers love.
Overview of Continuous Discovery Habits by Teresa Torres
Has your company been struggling to meet the needs of consumers despite extensive work on product development? Your problem may lie in how well you understand your customers. The 2021 book Continuous Discovery Habits by Teresa Torres presents a transformative approach to product management, arguing that successful product teams must engage in continuous discovery alongside their delivery efforts. Rather than treating customer research as a sporadic activity, Torres advocates making it an integral weekly practice.
Torres is a product discovery coach who has worked with teams at organizations like Spotify, Tesco, and CarMax to help them adopt continuous discovery practices. Through her consulting company Product Talk, she has developed and refined these methods over years of experience with product teams across various industries. Prior to becoming a coach, she served as Vice President of Products at AfterCollege and held product leadership roles at several startups. She has a bachelor’s degree in Symbolic Systems from Stanford University and a master’s degree in Learning and Organizational Change from Northwestern University.
In our overview, we’ll first explain what discovery is. Then, we’ll break Torres’s ideas down into five steps you can incorporate into your current product management process.
What Are Continuous Discovery Habits?
According to Torres, conventional product development focuses on delivery, which is the process of creating your product and getting it into the hands of consumers. Discovery, on the other hand, is the process of conceptualizing and selecting the product you’ll make. Torres suggests that many companies overemphasize delivery metrics (like on-time shipping and budget adherence) while underinvesting in discovery, leading to products that may be well-executed but don’t meet customer needs.
For example, a company that sells digital courses might invest a great deal of time and energy into developing and launching a course on a niche topic like extreme mountain biking only for the product to flop because customers aren’t interested in it. Even though the company did everything right with delivery—they got it out on time and under budget—they failed to do sufficient discovery work to make sure the product was something customers would want.
To remedy this, Torres recommends that companies engage in habits that promote continuous discovery—ongoing efforts to align your product with what customers want and need. The most basic requirement of this practice is to have the product development team collect feedback from customers on no less than a weekly basis to inform decisions about the product and the company’s activities.
Torres’s specific intended audience is the team responsible for product development, consisting of product managers, designers, and software engineers. She emphasizes that these three roles are critical for success, as they bring business acumen, design expertise, and technical knowledge, respectively, to the team. Though teams can often expand beyond this trio, they must remain lean enough to be able to balance inclusiveness—getting input from other relevant experts—with decision-making speed.
Torres outlines a process of discovery that involves the following steps: 1) Learn about your customers, 2) brainstorm solutions, 3) identify your assumptions, 4) test your assumptions, and 5) implement your solutions and assess their effectiveness.
Work With Your End Goal in Mind
Before you go through the steps of discovery, it’s important to plan out what you want to achieve in the process. Torres explains that you need to go about discovery with your end goal in mind—that is, what it is you hope to accomplish to better serve your customers. To do this, she recommends using a visual tool called the opportunity solution tree (OST). The OST serves as a roadmap for discovery work, helping teams navigate the complex process of creating both customer and business value.
To use this tree, you’ll need to define your desired outcome, which is the value you want to create for your customers. This is different from outputs, which are the features of your product. Outputs help get you to your outcome, but they’re not the end goal. Torres argues that focusing on outputs as your goal instead of outcomes is a shortcut that creates a disconnect between your product team’s activities and the value (outcome) they’re providing to customers.
For example, an online coaching service might seek to improve customer satisfaction with their coaching work. This is an outcome, as it refers to a value being provided to the consumer. The company might work toward this outcome by implementing certain outputs, like more specialized coaching or group sessions.
The OST starts with your outcome at the top. Then it branches into opportunities (what your customers want or need), then into potential solutions, and finally into assumption tests. You can fill in these various pieces as you go through the steps we describe below, but you should start with the top bubble filled out so you know what you’re working toward.
Torres writes that this tree will serve as a living document throughout your discovery process: As your customers’ needs shift, so will your potential solutions and the assumptions that go into them. When solutions fail, teams must reflect on what they misunderstood about their customers and revise the opportunities they’ve identified before moving forward. The OST helps make this learning process explicit and visible.
According to Torres, this map will also be useful when your team needs to show other members of the company what they’re working on and how. Rather than overwhelming stakeholders with raw data or only sharing conclusions, the tree structure allows teams to show their work in a digestible way. This enables stakeholders to truly evaluate the team’s thinking and contribute meaningful feedback.
Step 1: Learn About Your Customers
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
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 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 the 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 Step 5, 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.
