Continuous Discovery Habits: Discover Products that Create Customer Value and Business Value

by Teresa Torres

Designers bring visual, interactive, and systems-design chops that help to ensure that customers will understand how to best use a product and delight in that use. Software engineers bring the technical chops to ensure that the product is reliable, stable, and delivers on its promise. All three roles are critical to the success of any digital product. They are collectively responsible for ensuring that their products create value for the customer in a way that creates value for the business.

That means rather than defining your success by the code that you ship (your output), you define success as the value that code creates for your customers and for your business (the outcomes). Rather than measuring value in features and bells and whistles, we measure success in impact—the impact we have had on our customers’ lives and the impact we have had on the sustainability and growth of our business.

the purpose of business is to create and serve a customer. We elevate customer needs to be on par with business needs and focus on creating customer value as well as business value.

At a minimum, weekly touchpoints with customers By the team building the product Where they conduct small research activities In pursuit of a desired outcome

Product teams make decisions every day. Our goal with continuous discovery is to infuse those daily decisions with as much customer input as possible. If teams are only engaging with customers on a monthly basis, they are making a month’s worth of decisions without customer input.

At many companies, there is a tension between business needs and customer needs. When you get bombarded with a handful of ads before you can start reading a newspaper article, it’s because the newspaper prioritized their need for ad revenue over the reader’s need for a pleasant reading experience. When you can’t watch your favorite sporting event because the broadcast rights didn’t allow it to be streamed in your region, the sports team prioritized their television revenue over their fans’ desire to watch the game.

the goal of a business is to “convert society’s needs into opportunities for a profitable business.”

At a minimum, weekly touchpoints with customers By the team building the product Where they conduct small research activities In pursuit of a desired outcome

Finding the best path to your desired outcome is what researchers call an “ill-structured problem”—also commonly called a “wicked problem.” Ill-structured problems are defined by having many solutions. There are no right or wrong answers, only better or worse ones.

In this book, I’ll refer to customer needs, pain points, and desires collectively as “opportunities”—they represent opportunities to intervene in our customers’ lives in a positive way.

I’ll use opportunities to represent customer needs, pain points, and desires collectively and the opportunity space to represent the problem space as well as the desire space.

How the team defines and structures the opportunity space is exactly how they give structure to the ill-structured problem of reaching their desired outcome.

The implication for product trios is that two of the most important steps for reaching our desired outcome are first, how we map out and structure the opportunity space, and second, how we select which opportunities to pursue.

A “whether or not” decision is when we frame a problem as “Should we do this or not?” Product trios get caught up in “whether or not” decisions when we react to one customer need or pain point at a time, asking, “Should we stop everything and fix this problem?”

Instead of framing our decisions as “whether or not” decisions, this book will teach you to develop a “compare and contrast” mindset. Instead of asking, “Should we solve this customer need?” we’ll ask, “Which of these customer needs is most important for us to address right now?”

Many organizations try to define clear boundaries between the roles in a product trio. As a result, some have come to believe that product managers own defining the problem and that designers and software engineers own defining the solution. This sounds nice in theory, but it quickly falls apart in practice.

When we learn through testing that an idea won’t work, it’s not enough to move on to the next idea. We need to take time to reflect. We want to ask: “Based on my current understanding of my customer, I thought this solution would work. It didn’t. What did I misunderstand about my customer?” We then need to revise our understanding of the opportunity space before moving on to new solutions.10 When we do this, our next set of solutions get better. When we skip this step, we are simply guessing again, hoping that we’ll strike gold.

When considering outcomes for specific teams, it helps to distinguish between business outcomes, product outcomes, and traction metrics. A business outcome measures how well the business is progressing. A product outcome measures how well the product is moving the business forward. A traction metric measures usage of a specific feature or workflow in the product.

The key is to use traction metrics only when you are optimizing a solution and not when the intent is to discover new solutions. In those instances, a product outcome is a better fit.

In addition to your primary outcome, a team needs to monitor health metrics to ensure they aren’t causing detrimental effects elsewhere. For example, customer-acquisition goals are often paired with customer-satisfaction metrics to ensure that we aren’t acquiring unhappy customers. To be clear, this doesn’t mean one team is focused on both acquisition and satisfaction at the same time. It means their goal is to increase acquisition without negatively impacting satisfaction.

Groupthink occurs when a group of individuals underperform due to the dynamics of the group. There are a number of reasons for this. When working in a group, it’s common for some members to put in more effort than others; some group members may hesitate or even refrain from speaking up, and groups tend to perform at the level of the least-capable member.

Each person will take away different points from the same customer interview or the same assumption test. You’ll want to continuously synthesize what you collectively know so that you maintain a shared understanding of your customer context.

Gazzaniga’s study means you can’t simply ask your customers about their behavior and expect to get an accurate answer. Most will obligingly give you what sounds like a reasonable answer. But you won’t know if they are telling you about their ideal behavior or their actual behavior. Nor will you know if they are simply telling you a coherent story that sounds true but isn’t true in practice.

Our primary research question in any interview should be: What needs, pain points, and desires matter most to this customer?

You’ll want to tailor the scope of the question based on what you need to learn at that moment in time. A narrow scope will help you optimize your existing product. Broader questions will help you uncover new opportunities. The broadest questions might help you uncover new markets. The appropriate scope will depend on the scope you set when creating your experience map

When creating an interview snapshot, our goal is to process and understand what we heard and to capture it in a way that will make our research referenceable and actionable in the future. These stories give us the knowledge we need to design for the right person, in the right context, at the right time. But it can only do that if we capture enough of the story to remember it when we need it.

the more diverse your interviewing team, the more value you will get from each interview. What we hear in an interview will be influenced by our prior knowledge and experience.26 A product manager will hear things that an engineer might not pick up on, and vice versa.

Sibling relationships help us make sense of similar opportunities like “I want to watch my shows on my flight” and “I want to watch my shows on my train commute.” We can easily depict both on our tree under the parent opportunity “I want to watch my shows on the go.” This allows us to treat each context (e.g., plane, train) as a specific need to address, while also visualizing the similarities. They are both sub-opportunities of the same parent.

The easiest way to distinguish between an opportunity and a solution is to ask, “Is there more than one way to address this opportunity?” In this example, the only way to allow people to fast-forward through commercials is to offer a fast-forward solution. This isn’t an opportunity at all. Instead, we want to uncover the implied opportunity. Maybe it’s as simple as, “I don’t like commercials.” Why does this reframing help? If we then ask, “How might we address ‘I don’t like commercials’?” we can generate several options. We can create more entertaining commercials—like those we see during the Super Bowl. We can allow you to fast-forward through commercials like the customer suggested. Or we can offer a commercial-free subscription. An opportunity should have more than one potential solution. Otherwise, it’s simply a solution in disguise.

“The build trap is when organizations become stuck measuring their success by outputs rather than outcomes. It’s when they focus more on shipping and developing features rather than on the actual value those things produce.” — Melissa Perri

It’s the last talk of the day at Mind the Product. All we have left is the after-party, and I want to leave the crowd with an important takeaway. “You are never one feature away from success…” The crowd erupts with cheers. But I’m not done. I wait patiently for the crowd to quiet down. I continue, “…and you never will be.” The energy in the room is electric. I know people need to hear it, but I also know that saying it isn’t enough.

You don’t want to ask, “Should we pursue this opportunity?” That’s a “whether or not” question that leads to poor decisions. It makes us susceptible to confirmation bias, and we forget to consider opportunity cost. Instead, you’ll compare and contrast the set of parent opportunities against each other.

Opportunity sizing helps us answer the questions: How many customers are affected and how often? However, we don’t need to size each opportunity precisely. This can quickly turn into a never-ending data-gathering mission. Instead, we want to size a set of siblings against each other. For each set that we are considering, we want to ask, “Which of these opportunities affects the most customers?” and “the most often?” We can and should make rough estimates here.

Market factors help us evaluate how addressing each opportunity might affect our position in the market. Depending on the competitive landscape, some opportunities might be table stakes, while others might be strategic differentiators.

Company factors help us evaluate the strategic impact of each opportunity for our company, business group, or team. Each organizational context is unique. Google might choose to address an opportunity that Apple would never touch. We need to consider our organizational context when assessing and prioritizing opportunities.

Customer factors help us evaluate how important each opportunity is to our customers. If we interviewed and opportunity mapped well, every opportunity on our tree will represent a real customer need, pain point, or desire. However, not all opportunities are equally important to customers. We’ll want to assess how important each opportunity is to our customers and how satisfied they are with existing solutions.

When we turn a subjective, messy decision into a quantitative math formula, we are treating an ill-structured problem as if it were a well-structured problem. The problem with this strategy is that it will lead us to believe that there is one true, right answer. And there isn’t. Once we mathematize this process, we’ll stop thinking and go strictly by the numbers. We don’t want to do this.

It’s easy to fall into the trap of wanting more data, spending just a little bit more time, trying to get to a more perfect decision. However, we’ll learn more by making a decision and then seeing the consequences of having made that decision than we will from trying to think our way to the perfect decision.

Jeff Bezos, founder and CEO of Amazon, made this exact argument in his 2015 letter to shareholders,33 where he introduced the idea of Level 1 and Level 2 decisions. He describes a Level 1 decision as one that is hard to reverse, whereas a Level 2 decision is one that is easy to reverse. Bezos argues that we should be slow and cautious when making Level 1 decisions, but that we should move fast and not wait for perfect data when making Level 2 decisions.

Lottie Bullens and colleagues, social psychologists at the University of Amsterdam, found in a series of studies that, when people viewed a decision as reversible, they continued to critically evaluate their decision after making it. In fact, they were more likely to see the negative attributes of their choice and the positive attributes of the alternatives after making the decision if they viewed it as a reversible decision. If they framed it as an irreversible decision, the opposite happened. People noticed only the positive attributes of their own choice and the negative attributes of the alternatives.

However, creativity research tells us that our first idea is rarely our best idea. Researchers measure creativity using three primary criteria: fluency (the number of ideas we generate), flexibility (how diverse the ideas are), and originality (how novel an idea is).35

Now, not all opportunities need an innovative solution. You don’t need to reinvent the “forgot password” workflow (but you should still test it—more on that in Chapter 11). But for the strategic opportunities where you want to differentiate from your competitors, you’ll want to take the time to generate several ideas to ensure that you uncover the best ones.

One, focus on quantity. In other words, generate as many ideas as you can. Two, defer judgment, and separate idea generation from idea evaluation. Three, welcome unusual ideas. And four, combine and improve ideas.

As researchers dug into why individuals outperformed groups, they identified four mitigating factors. First, research has found that people tend to work harder when working individually than when working in groups. This is called social loafing. When we are on our own, we have no choice but to put in the work, whereas when we are in a group, we can rely on the efforts of others.

Second, brainstorming groups exhibited many of the common challenges associated with group conformity. The early ideas set the tone for later ideas. Ideas were often too conservative or similar to each other. Members censored their ideas due to concerns about how others would judge their ideas.

brainstorming groups ran into challenges with production blocking—that’s a fancy term for a simple idea. Have you ever been about to say something when someone else jumped in, prompting you to forget what you were going to say? That’s production blocking. In group brainstorming sessions, pe...

This raises the question: Why are brainstorming advocates so adamant that brainstorming works? It turns out researchers have an answer to this question as well. Bernard Nijstad and colleagues at the University of Groningen in the Netherlands found that brainstorming groups are subject to what they call “the illusion of group productivity.”40 This is a phenomenon in which groups overestimate their performance. They also report high levels of satisfaction with their work despite their lesser performance.

Runa Korde and Paul Paulus, researchers at the University of Texas-Arlington, ran a series of studies that showed alternating between individual ideation and group sharing of ideas can improve the quality of ideas generated in subsequent individual ideation sessions.41 Exposure to other people’s ideas did inspire new ideas.

Incubation occurs when your brain continues to consider a problem even after you’ve stopped consciously thinking about it.

You should draw inspiration from your competitors, but look broader than that. Many innovative ideas come from unrelated domains. For example, Velcro was invented after the inventor found a cocklebur in his sock. He was intrigued by how the latching mechanism worked, and it inspired the design of Velcro.