Embracing Continuous Discovery

Alexis:

Welcome to Le Podcast on Emerging Leadership. I'm your host, Alexis Monville. Today I'm excited to speak with Teresa Torres, author of the influential book Continuous Discovery Habits. Teresa helps product teams adopt habits that enable them to uncover customer insights continuously, ultimately building better products.

Through her blog producttalk.org and extensive coaching, Teresa has reshaped how companies think about product management and customer discovery. In today's conversation, we'll explore how teams can integrate discovery into their daily routines, make more informed decisions, and consistently create valuable outcomes for their customers.

Welcome Teresa! How do you typically introduce yourself to someone you just met?

Teresa:

Ah, that's a great question. From a work standpoint, it's always a little bit of a challenge. There's a lot of jargon in our industry. So for the folks that are familiar with discovery, I introduce myself as a product discovery coach. For folks that are not familiar with those terms, which is quite a few of us, I say that I help teams that are building digital products make better decisions about what to build.

Alexis:

I really like that. So how did your journey lead you to write the book?

Teresa:

This is a big one. It took a long time for me to write the book. People ask me, how did your book do so well? And I say, well, I let demand build up for a really long time. And it wasn't intentional.

It really goes back to 2016. I was several years into working as a discovery coach. I'd been working with dozens of teams, just looking at how they build fast feedback loops as they make decisions about what to build. Are they interviewing customers? Are they testing their ideas?

In 2016, I was working with a team and they came to their coaching session and said, “Teresa, we really love our sessions, but we're afraid we won't know what to do when you're not here.” That really landed with me, because I decided to work as a coach and not a consultant because I want to leave people better off. I want to empower people to do this on their own. I didn't want to build a dependency. So this feedback was a little bit gut-wrenching for me.

I sat down and started to think: how am I making decisions about what to do next in discovery? Around that same time I was reading Anders Ericsson's book Peak, which is all about expertise and deliberate practice and what distinguishes experts from novices. One of the ideas in the book is that experts have mental representations that are different from what novices have. That was exactly the insight I needed. I asked: what mental representation do I have in my head about discovery that the teams I'm coaching don't?

That's what led to the Opportunity Solution Tree. For listeners who aren't familiar, an Opportunity Solution Tree is a really simple visual decision tree where the team's outcome is at the top. As they talk to customers, they learn about customer needs, pain points, and desires — those are opportunities. They literally map them on the tree, and then they're looking for what solutions match one-to-one to those opportunities.

It's really simple, but what it does is give you a visual cue: do I know enough about my customer? Does my opportunity space look rich and detailed? Am I actually working on a solution that solves someone's problem in a way that drives their outcome?

In August 2016, I introduced this visual to that team for the first time and it had a huge impact right away. I'm a product person — I know that things don't have a huge impact right away. So when it did, I was like, there's something here. I have to write a book about this.

I started trying to write the book in 2016, but I struggled because books are waterfall. You write the whole book and you release it in hopes people like it. I refused to operate that way. So it took me several years to figure out how to test the content. I codified all my discovery knowledge into online courses, watched students engage with it in both my coaching practice and online courses, and once I felt like it was clear enough and good enough, I wrote the book.

Alexis:

This is very interesting because I've heard a lot of people say, “oh yeah, we built up a training course because the book was successful, so people wanted to buy training from us.”

Teresa:

I went the other way around because I needed a feedback loop. I needed to know what was clear, what was confusing, where people got stuck. Every chapter ends with anti-patterns — those came from real coaching sessions and real course students. All the activities in the book are things we do in our courses, vetted and tested with hundreds of teams.

Maybe the real answer to how the book did so well is that I tested all of the content like crazy. But I will say in 2016 I said I was going to write a book, and so for five years people kept asking, “where's your book?” I've learned to not put timelines on things, so they had to keep waiting.

Alexis:

That's good. That would have been terrible to have a deadline that forces you to publish something that's not good. Early on you introduced the idea of the product trio. Could you share why and how those roles effectively collaborate?

Teresa:

What's funny is that I didn't create this idea — it has been around for a long time. In the agile world they often talked about the three-legged stool or the three amigos. I think the reason people attribute this idea to me is that I included it in the book and I gave it simple language.

I heard a lot of people talking about “triads,” and I remember thinking: what's a triad? So I called it a product trio. Language matters. I've introduced my own terrible language too — Opportunity Solution Tree is a terrible name. But I tried hard with the product trio idea to simplify the language, and I think it has helped.

It's the idea of how do we cross-functionally collaborate from the very beginning? It sounds simple, but in business we're really bad at cross-functional collaboration. We see it up and down the organization. Business culture rewards us for staying in our silo and being territorial.

If we're going to build a good digital product that's always evolving, it really does take a cross-functional mindset. We need to keep the business perspective and viability in mind. We need to keep the customer in mind — how do we make it delightful, usable, satisfying a real need? It also has to be feasible.

For most companies, a typical product trio is a product manager, a designer, and a software engineer. But it's not that clean — and generative AI is making this even messier. We have designers with a strong human-centered research background who want to be involved in the decisions about what to build. We have product managers with MBAs who are strong on viability but weak on usability or desirability — and others who are the complete opposite. Engineers vary the same way.

The underlying principle is: we need a wide variety of skills to build a successful product. How do we get the right people in the room to make sure all those skills and perspectives are represented? What we used to do is silo it: the PM wrote requirements, handed them to the designer, who handed them to the engineer. The problem is the ton of rework. When these roles work together from the beginning, we get much better solutions and we get them faster. It's counterintuitive.

Alexis:

What are the common challenges teams face when adopting the continuous discovery habit?

Teresa:

How long do we have? Since we were just talking about team collaboration, that's a big one. We've been trained to be territorial, and generative AI is going to make this worse.

I've been building my first generative AI product, and I'm starting to learn what it takes to make these products good — getting into the world of evals and guardrails, how to evaluate the success of a non-deterministic product. The methods that are starting to arise to evaluate these tools require domain expertise that your product manager or designer or business stakeholders might have, and engineering expertise to know what's possible with code. There are a lot of conversations about who does what, and it's messy. The answer is going to be: the person closest to the customer does one part, the person with the necessary engineering skills does another — but who that is from a role standpoint might change from team to team.

For myself, I've actually spanned all three roles. I started as an interaction designer and front-end web developer, then moved into product management. In the last three years I've moved back into coding. In the last month, building this AI product, I took a course on AI evals and I'm doing the work of an AI engineer. I implemented my first set of automated evals, in a language I had never programmed in, in a tool I had never used before, all in one week. The reason that was possible is because ChatGPT guided me through all of it.

These boundaries are blurring. Designers can now code, product managers can design, and engineers will have to learn some design and product management skills. The product trio concept — cross-functional collaboration — stays. But the really clean boundaries between our roles are getting obliterated. That's hard for people. We identify with our jobs. Those identities are going to get stretched and blurred, and it's going to cause some discomfort.

A second challenge: leaders have grown up in a world where they get to tell us what to do, and when we're empowering our teams they have to learn different ways to have oversight without dictating outputs. Product teams have to learn to show their work so leaders trust they're making progress.

A third: companies think there's a significant barrier to accessing customers. In my experience, this is more mental roadblocks than tangible barriers — even in regulated industries. There are people in every industry doing this.

Alexis:

It's very interesting because while you were talking I was thinking of a team I'm working with in a regulated industry — healthcare. They have a lot of good reasons for not being able to do things, but when you look in detail, you realize maybe you can do a little bit more.

Teresa:

Healthcare's a great example. Here in the US we have HIPAA, our healthcare privacy law. The basis of the law is: if I tell my doctor something, you can't go share that with other people. I have a right to privacy.

That law doesn't say I can't willingly share my healthcare experience with you. But teams interpret it as: we have to be HIPAA-compliant, we're not allowed to talk to our customers. A lot of HIPAA-compliant companies have policies that say you can't talk to customers because they don't want to train them on the HIPAA requirements. Those are constraints we have to work within, but it doesn't mean somebody who's willing to share their experience with you can't share it. I've never seen a law that restricted that yet.

Alexis:

I have a question about product managers who struggle to really understand the value of UX work, especially in the context of the discovery process. What are the misconceptions you see there?

Teresa:

When it comes to UX, I actually see two extremes and I think both are wrong. One extreme: our engineers can just build it, we have a design library, they can throw together some components, we don't need a designer. The other extreme: we need a designer on everything; everything needs to be delightful and perfect.

Most things probably need a designer to at least glance at them. But we don't need every single part of our product to be delightful. If that were our requirement, we'd never ship a product. Look at Apple — clearly a company committed to design — and there are still lots of parts of their website that are horrendous to use. It is impossible to create a perfectly designed product.

What it means is that we have to make prioritization decisions: what parts of the customer journey are most important to get right? Where does delight matter most? Where can we just use a common pattern?

UXers in particular go to design school, learn about delightfulness, admire beautiful products, and try to apply that to everything. Digital products have big footprints, they're constantly changing — it's just not realistic. People who haven't been exposed to design take it the other way. I still meet companies with 20 product managers and zero designers — “oh, it's just colors on a website.” You're overlooking information architecture, interaction design, all these elements of design practice.

It's easy to think the world is these extremes. The right response is almost always somewhere in the middle. It's much more nuanced. But nuance doesn't win on social media.

Alexis:

You emphasize weekly customer interviews. The first time I discussed that with a product team, they were puzzled. They had a process in mind that seemed radically different from that — too far away to even think about. The “who would do it” was also a concern. You have a strong opinion on this. I'd love to hear what you have to say.

Teresa:

Let's talk about why I recommend this, and then how teams can get there. For me, discovery is about: if we want to make good decisions about what to build, we have to get feedback on those decisions. We have so many examples of products where the people who designed or built them did not get feedback along the way and they flopped. Or maybe they had the right idea for the right moment and took off but didn't sustain. Clubhouse comes to mind — wildly popular for three months and then it just petered out.

We need to be careful about who we're designing for, who we're building for, what their needs are, and how many people out there are like those people. That's starting with the ideal customer profile, understanding the market size, digging in and understanding what needs they care about and whether we're adequately solving them. That's the strategic stuff.

But as we build, we have daily decisions. People are stuck at home and want to connect — great, that's a real need. Now we need to decide how it should work: how do we promote what's happening in a room? Who's allowed in? How many people are allowed to talk at the same time? What happens when people say offensive things? Everybody on your product team is making decisions all day long. Where's the feedback loop for all those decisions?

When I say feedback loop, I don't mean I can't change one line of code until I get feedback from a customer. I mean we need constant exposure to who we're building for to make sure all these tiny decisions work for them. Without that exposure, we're in a dark room looking for a tiny thing on the floor — we're lucky if we find it.

The more we talk to our customers, the more likely those tiny decisions are going to work for them. Once a month is better than never. But I'm making decisions all day, every day, so the more exposure I have, the more likely those decisions are going to fit.

Too many teams use customer interviews to walk in and say, “here's my shiny solution, what do you think?” That's not the purpose. When I say talk to your customers every week, it's not “go sell to your customer every week.” It's “go talk to your customer and learn about their world.” Who are they? What are they doing? What are their goals? Collect their stories. Your goal is to understand your customer's mental model of how they approach whatever they're trying to accomplish.

If I work at Spotify, I'm going to interview people about the role music plays in their life — when they listen, where, how, where they learn about new music. I'm going to collect lots of stories about how they engage with music. It's not going to tell me what product to build. It's going to tell me how my customer's mental model of music works. My job is to make sure my product matches that mental model. So it's not that I have to get feedback on every decision — it's that I have to build a mental model that matches my customer's.

Alexis:

That leads us to the how and the who.

Teresa:

What I tell people is to take a continuous improvement mindset to your own discovery habits. If you've never talked to a customer, forget that I told you once a week — just go talk to one customer. And I don't mean go join a sales call. Talk to a customer about their world, their goals, their context, their stories — not your product, their stories. Once you've done that, think about how you talk to your second customer. By the time you've talked to two or three, I don't need to convince you to do it more. So much magic happens in those first couple of conversations.

Then we need to operationalize it. Create a continuous pipeline of people to talk to. I recommend automating the recruiting process — I share tips in the book, and we have a course on customer recruiting with five strategies and lots of examples. Then learn to ask the right questions. We teach a very simple interviewing format focused on collecting customer stories. Any human on the planet can learn how to do it. It's evidence-based, grounded in good qualitative research practices, and it solves the problem of building a mental model that matches your customer's.

It doesn't answer every research question — we still want researchers involved in other types of research — but it allows a product team to close the gap. Once you've worked on your pipeline and you're practicing better interview questions, look at your cadence. If you're talking to someone once a month, try to get to every three weeks, then every two weeks. I use the guideline of once a week as our minimum. Plenty of teams do multiple a week. Plenty of teams do every day.

Alexis:

I assume product managers and UX people would be comfortable discussing with users, but engineers on the team would benefit from doing it too?

Teresa:

I want every single person involved in building the product to at least be listening to the conversations. The more people on your team listen, the more they're going to want to get involved. You can start with the person most comfortable conducting interviews and have everybody else observe — or watch the video afterwards. Not clips, not just transcripts, not just notes — see the participant share their story.

With time, it makes sense to have multiple people on the team comfortable conducting interviews. It helps with the resiliency of the habit. If your one PM does all the interviews and they leave, go on vacation, or get sick — what happens? The more people comfortable with it, the more resilient the habit. But really, I want everybody watching, including engineers.

Alexis:

You mentioned the Opportunity Solution Tree before — really beautiful name. Do you have a concrete example to walk us through what it really is?

Teresa:

In the book I use streaming entertainment as my example because it's available worldwide.

The purpose of an Opportunity Solution Tree is to help a cross-functional team drive an outcome and stay aligned in their discovery work. When we shift from focusing on outputs to impacting a metric — driving an outcome — it's messy. We have false starts. It can feel really overwhelming: what do we pay attention to? It's easy to fall prey to shiny object syndrome and end up working on solutions that don't match anything we heard in our interviews.

The goal is to keep everybody aligned and help them know what to do when. When a team is new to driving outcomes, the whole nature of their job changes. When we're told to build a thing, it's deterministic and narrowly defined. When you start with an outcome, it feels like a blank-page problem — we could do a hundred thousand things. How are we going to decide?

Teams start by interviewing customers and collecting stories. They hear pain points, friction, unmet needs, unsatisfied desires — those are opportunities. They map the opportunities on the tree.

Let's use Netflix. An outcome represents a business need, typically derived from your revenue model. Netflix is a subscription business: acquire more customers, increase average monthly spend, increase retention, lifetime value. Say I have a team focused on retention. What drives retention? It's almost always tied to the value the product delivers — Netflix entertains me. How do I know you're being entertained? Maybe you watch Netflix more often. So my outcome is to increase the average viewing minutes per week.

I'm new to this outcome. I don't know why you watch Netflix or what prevents you from watching more. I have to interview customers — “tell me about the last time you watched Netflix” — and collect stories. I'll hear things like: it took 45 minutes to find a show I might like; my friend recommended this show but I can't tell if I'll like it; I'm in the middle of a series but can't figure out how to get back to it; I was on terrible hotel wifi and it took seven minutes to load and paused 14 times.

I collect those as opportunities and organize them based on steps in the journey. The top level might be: I need to find something to watch. I want a good viewing experience. I don't want to stay up too late. Under “I need to find something,” we uncover pain points: I can't find the show I was watching, I can't tell if a show is good, I want a similar show, I want to know who's in this show. Around viewing experience: I don't want to wait for buffering, I want to rewind quickly, I need to be able to pause.

We organize them on this visual. Then we make a strategic decision: where do we want to play? Which of these opportunities are most important to solve? This sounds obvious, but most teams react to the most recent conversation they heard — a stakeholder pulls them into a customer conversation, somebody has a pain point, “oh, all hands on deck, let's solve that right now.” We're missing the strategic decision of where to play.

The opportunity space is infinite. We need to make a strategic decision: what differentiates us in the market? What supports our company's strategic initiatives? We can't do all of it. The Opportunity Solution Tree gives us a place to collect what we're hearing, helps with overwhelm, lets us filter based on our outcome, and bounds the types of solutions we consider. Then we test: is our proposed solution going to address that opportunity in a way that drives the outcome?

Alexis:

And then we're able to experiment and test our hypotheses. I love it. You mentioned the importance of outcomes versus outputs and the role of leaders in changing their language. Do you see other things about the role of leaders — different ways of working?

Teresa:

We've seen two — maybe three, depending on where you live — major world events that I think are finally teaching organizations we need to be outcome-focused. First was COVID. The entire world shut down very quickly. The way we work changed suddenly. You probably had to throw away a lot of your roadmap. If you were Zoom, you had to react to a huge new market opportunity. If you built software for restaurants, you lost a lot of customers very quickly.

Second major world event: the rise of generative AI. It's disrupting everybody's roadmaps. Third: the geopolitical climate — Russia–Ukraine, Israel–Iran, the craziness with tariffs affecting the global economic environment. Companies are really struggling with how to predict the year.

For decades the business literature has used acronyms about ambiguity and uncertainty, but companies still come up with five-year strategic plans and 12-month roadmaps. We still operate as if the future is predictable. We're starting to see cracks. Companies are saying: we can no longer plan five years in advance because we can barely plan next month. This is a good thing — the silver lining of all the nonsense we've been through.

But it's a whole new skillset. How does my CFO plan if we didn't fund projects for the year? How does marketing run campaigns if they don't know launch dates? How does sales close deals if they can't say when features are coming? Literally everybody in the organization has to change the way they work. That's why we now have books on transformations, billion-dollar consultancies on transformations, hundreds of solo consultants supporting them. We don't know how to do it yet.

From an organizational change standpoint: nothing changes until the mindset changes, until people believe there's a need for change. I think in the last five years we're starting to believe there's a need. I'm excited that companies are taking this seriously.

Alexis:

That's a strong belief that could help us get to that desire to be more adaptable. I was discussing beyond budgeting and being absolutely convinced we needed it — that was not so easy to convince people of.

Teresa:

One of my mantras this year is that organizational change doesn't happen as a big change. It happens through a series of teeny, tiny changes. So I tell people: don't try to change your organization. Just change your own habits. Don't try to change all your habits at once — pick one habit, adopt it, internalize it, make it the way you work. Then move on to the next.

When we focus on our own behavior, when we change our own habits, people around us get curious: “Hey, you're doing this thing that's interesting — what is it?” Now we have an invitation to share. When we come in and say, “Hey, I learned this new thing, we're doing everything wrong,” people dig their heels in. They say: no way, I'm stubborn, I hate frameworks, influencers don't know anything, you can't learn anything from books, product management's different everywhere.

You almost have to be sneaky about organizational change. The hard truth is it starts with yourself. Nobody wants to hear they're the problem. The only way to drive change is to start with your own behavior and model what you want to see across the rest of the organization.

Alexis:

I love it. I believe we should end on that. Do you want to share anything about what you're currently working on?

Teresa:

If listeners are new to my work, I blog at producttalk.org. The book is called Continuous Discovery Habits.

I've done a ton of work over the last almost 15 years on how to do discovery well, how to build fast feedback loops with customers. I'm not done — there are still plenty of teams not doing discovery. But for the last four months I've been diving deep on how to use generative AI to support teaching. I've been building my first LLM-based apps, which has been really fun, and we're already using some of them in our courses.

It also introduced me to this whole new world of how product management is changing when the product we're building is non-deterministic — how do we measure quality when the product is non-deterministic? I'll be blogging way more about this. In July I have a blog post coming out about what role AI prototyping can play in discovery. I'll do a post about how cross-functional teams should be doing evals and guardrails for LLM-based apps and how to navigate that — it's really not clear who does what. And I'll probably do a post about how our roles are blending even more, and how to mentally prepare for that. If you really identify as one role, maybe start to adopt an identity of other roles and build out your skill set.

I've been reluctant to write about this stuff because it changes so fast, but after four months of building with it I'm starting to develop a point of view, and I'll be sharing much more at producttalk.org.

Alexis:

Excellent. I'm eager to read about that. Thank you very much for all the work you're doing. It's absolutely fantastic. And thank you for joining the podcast today.

Teresa:

Thanks for having me. This was a fun conversation.