Continuous Discovery Habits by Teresa Torres- what this awesome book is all about

In theory, everybody working in product development knows that it’s imperative to talk to and understand your customers. What sounds so obvious in the abstract is – in my experience – a bit harder to implement in practice. Many companies and teams don’t walk the walk when it comes to customer centricity. Instead, they rely on leadership or their own best guesses to guide their product development efforts. Related, many teams every day ship features and products that no one ends up using. Teresa Torres in her great book Continuous Discovery Habits provides a remedy for exactly this deficit. 

She gives practical and tactical advice on continuously interacting with users and customers to discover what they truly need. Today, I want to dive into the book, first explaining its main concepts, then sharing my personal takeaways.

Buckle up, this is a long one 🙂

Email address:

Leave this field empty if you're human:

The main concepts of Continuous Discovery Habits

The book is built around continuously interviewing customers to uncover their unmet needs, then structuring the opportunities, coming up with solutions, and finally determining which to implement. Along the way, Teresa Torres shares actionable advice on how to conduct each step successfully. She shares specific habits that help establish continuous product discovery practice. 

Before getting into the details, I want to establish why it is so important to form these continuous discovery habits.

Continuous discovery leads to more effective development

Product development consists of product discovery and product delivery. In discovery the team researches what to build. In delivery it actually builds the determined solution. Many teams and companies focus on delivery work and use frameworks like Scrum, Lean, or Kanban to optimize the delivery process. 

This increase in efficiency is what many are good at. However, the most efficient development process doesn’t help you if you are building the wrong things. This is where product discovery – determining what to build – comes in. It ensures effective product development work. 

In practice, discovery and delivery are overlapping. The more mature a company or product is, the less discovery work is needed. However, even mature digital products are never done. They continuously evolve. 

For this to be done effectively, you need to continuously find opportunities, you need to establish continuous discovery habits.

What is continuous discovery?

Teresa Torres defines continuous discovery as follows:

“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.”

She introduces the product trio consisting of a designer, a developer, and a product person. This is the team who needs to continuously interview customers to excavate opportunities.

The different backgrounds of the people in the trio mean different points of emphasis when listening. For example, the designer may automatically focus on usability, the developer on feasibility, and the product person more on the dependencies to what other teams are working on. Having a cross functional product trio ensures capturing a complete picture of the user’s story.

The weekly cadence of interviews proposed by Teresa Torres allows for flexibility. If the interview doesn’t go as planned the product trio can adapt and apply the changes one week later. If the team decides to switch its focus from one user issue to another one, it can simply modify the questions. There is no need to spend several weeks (re-)planning a big, specific user testing session that happens once a quarter.

Of course, at the heart of the book are the continuous discovery habits themselves.

The continuous discovery habits 

The continuous discovery habits are a means to continually learn. Although the steps are not always sequential – product development is a messy business, after all – I like to view them as a process.

1. Define outcomes
2. Build the experience map
3. Interview weekly
4. Create the Opportunity Solution Tree
5. Focus on one opportunity
6. Define solutions
7. Identify hidden assumptions
8. Prioritize and test the assumptions
9. Measure the impact
10. Decide on a solution or focus on something else
11. Manage stakeholders

One step at a time.

1. Define outcomes

As a first step it is crucially important to define the outcome(s) for the team to achieve (e.g. with OKRs). This is not uniquely a part of Continuous Discovery Habits, but good product development practice in general. 

Having leadership define outcomes for a team to achieve (instead of features to build on a timeline) is likely the most impactful single action that can be taken to empower a team. Without this as a prerequisite, it’s hard for a team to actually discover solutions for user problems.

2. Build the experience map

As a way to capture current knowledge about the user, the product trio creates an experience map. This is a visual representation of the steps the user goes through when using the product. Torres advocates for making the map visual, i.e. actually drawing it, as an aid to better thinking through the problem. 

3. Interview weekly

Next, the actual interviewing starts. The frequency can be lower in the beginning, but the target state should be a weekly cadence of interviews. Ideally the participants are recruited automatically. The trio summarizes the interview using the interview snapshot. 

For each interview the product trio needs to define a research question. It is what they are trying to better understand. An example might be: What needs, pain points and desires matter most to this customer? Crucially, the research question is not a question actually posed to the participant.

In general, it is important to avoid asking customers directly what they want, as they often don’t know themselves. Instead, the trio must focus on relevant experiences to excavate the underlying needs. More on this in a bit.

4. Create the Opportunity Solution Tree

The team visualizes the needs, pain points, and desires in the opportunity solution tree (OST). It is a living document evolving with changing knowledge about the users. I won’t explain deeper here, since I already covered this method in detail. 

5. Focus on one opportunity

Using the tree, the team compares and contrasts the opportunities on one level at a time until it choses one from the lowest level to focus on. Comparing opportunities, the trio needs to take opportunity size, market factors, company goals, and customer value into account when making the decisions. 

6. Define solutions

Next, the product team brainstorms solutions for the chosen opportunity. To avoid group-think it is important to do this – in part – individually. The team should come up with as many as possible ideas before reducing the number to the three that seem most promising.

7. Identify hidden assumptions

Using e.g. a story map, the team now identifies the hidden assumptions behind each solution. These are all the premises that need to be true in order for the user to use the proposed solutions as intended. Step by step, the team makes the assumptions explicit.

8. Prioritize and test the assumptions

Next, the product trio choses the assumptions that are most critical but least certain. Those are the ones to test. 

They are not testing the solutions themselves, but the assumptions. 

This is so important as it allows for de-risking many solutions simultaneously and reduces experimentation effort. This whole concept of identifying and testing assumptions was not very intuitive for me at first. I explained in detail when sharing my best practices using the OST.

9. Measure the impact

Most business goals are lagging indicators that change only after significant delay. In order to immediately measure the impact, the trio needs to come up with leading indicators that measure the impact of experiments almost in real time.

 10. Decide on a solution or focus on something else

After running the experiments, the team is ideally able to choose a solution and build it. Alternatively, the trio might also realize that, for whatever reason, there is no solution for the chosen opportunity. In this case, it will go back to step 5) and choose a different opportunity to focus on. 

 11.Manage stakeholders

In order to have a successful product the product trio needs the help of other stakeholders. For this to work, the trio needs to continuously share what they are working on. In order to minimize the effort, it can do this using the visual artifacts it created along the way (experience map, opportunity solution tree). It is important to not overwhelm the stakeholders, e.g. by only showing parts of the tree.

My three takeaways from Continuous Discovery Habits

Having (semi-)briefly introduced the main concepts in Continous Discovery Habits, I want to now share the three takeaways that were most impactful for me in reading the book. 

I have already covered the OST, testing assumptions instead of solutions, and leading indicators elsewhere. Thus, I won’t include them here, although these three were tremendously impactful. Instead, I will focus on the following:

• Not relying on direct customer feedback
• Automatic recruitment of interview participants
• Embracing the messiness and subjectivity

Not relying on direct customer feedback

The way the human brain works is sometimes strange. It unconsciously provides rational explanations to our – sometimes irrational – behavior. It is for this reason that you cannot rely solely on explicitly stated wishes of the customers. You need to excavate the underlying needs by focusing on relevant experiences.

The book includes the following great example:

Interviewer: What is important to you when buying new pants?
Participant: They have to fit well.
Interviewer: Where did you buy your last pair of pants?
Participant: Amazon.

The stated preference of the person is not the same as the revealed preference. There are countless examples of this. A long time ago, when Facebook first introduced the feed, people said they hated it. Yet their interaction with the platform significantly increased.

People often don’t know what they want.

Instead of asking users directly, it is better to invite them to share specific, relevant stories of when they used your product, when they used the competition, or when they were in a situation where your product could have helped. Going jointly through these stories, you need to closely listen for any unmet needs, desires, and pain points related to the research question. 

(As a side note: the entire section of the book on interviews is incredibly helpful. It explains how to interview in a hands-on way. I regularly read through it to prepare interviews.) 

Automatic recruitment of interview participants

Recruiting participants and scheduling interviews can be a hassle. It causes excess effort and might be the hardest part of setting up continuous discovery habits. In order to simplify this, the team should rely on automatic recruitment as much as possible. 

The goal is to have an interview automatically scheduled without having to worry about it. The easiest way to recruit participants is while or after they are using their product. Simply showing a pop-up that leads to an automatic scheduling tool (e.g. Calendly) is a very effective way to do so.

There are other ways to schedule interviews (e.g. asking sales). Automating the recruitment is always preferable and not as difficult to implement as it may sound in the beginning.

Embracing the messiness and subjectivity

Although we try to squeeze product development into the corsets of nice looking processes and clean frameworks, it remains messy. Instead of fighting this reality, it’s best to embrace it. Otherwise, you run the risk of not getting anything done.

One example presented in Continuous Discovery Habits really spoke to me, since I have lived similar situations over and over again. When deciding which opportunity to focus on (step five from above), the trio needs to take different factors into account: opportunity size, market, company goals, and customer value.

Teresa Torres advises against scoring the opportunities along those dimensions, as many would automatically jump to. This would mean making an inherently subjective decision seem like it is objective. Now, this doesn’t mean that you should randomly make a decision. You should take facts and data into account. 

Nevertheless, the fact remains that the decision will always remain a) subjective and b) easily reversible. Worst case, you picked the wrong one and a few days later have to change the focus. This is the beauty of weekly interviewing and running light weight experiments. Not a lot is lost when making wrong decisions.

The same principle applies to measuring the impact of experiments. Teams tend to try and set up the perfect measurement system to collect perfect data before making decisions. They try to measure too much and end up wasting time. It’s much better to start simple.

Embracing the messiness and subjectivity of product discovery by making swift decisions means getting things done fast.

A personal anecdote

To finish up this article on Continuous Discovery Habits, I want to share a personal story that exemplifies why the practice is so important.

We were not so long ago building a B2B API based on vehicle data serving many industries all over Europe. Amongst other things, our service was integrated in the purchase flow of many European car insurance companies.

We were – and the team still is – very successful. We worked closely with our great sales team to provide the features they needed to unlock specific market segments. I had regular touchpoints with customers (not as often as I should have) and the main feedback we got directly or through the sales team was the need to increase service quality. So, we did that and everything was fine. 

Only after moving to Spain and attempting to buy insurance online for my car did I realize what a big opportunity we had missed because we didn’t talk to the end users, because we didn’t implement continuous discovery habits. The buying experience was horrible. I had to enter all my personal data online and the vehicle data came from our service. In the end I had to call the insurance and over the phone give all my data again, verbally. 

This happened for EVERY SINGLE insurance I tested to compare the rates. The quality of the data coming from our API was the least of my problems. There were so many other opportunities to improve the experience.

If we would have interviewed a Spanish end user of our service just once, we would have realized this immediately.