Category: Le Podcast – Season Five

Product teams make decisions every day.

Small ones. Big ones. Technical ones. Strategic ones.

And yet, in many organizations, those decisions are made with very limited exposure to real customers.

In this episode of Le Podcast on Emerging Leadership, I spoke with Teresa Torres, product discovery coach and author of Continuous Discovery Habits, about what it truly means to embed customer discovery into everyday product work.

This conversation goes far beyond techniques. It challenges how teams learn, how leaders lead, and how organizations adapt in an increasingly unpredictable world.

---

From expert intuition to shared mental models

Teresa’s journey toward Continuous Discovery Habits began with a simple but unsettling realization.

After years of coaching product teams, one team told her:

“We love working with you — but we’re afraid we won’t know what to do when you’re gone.”

That moment sparked a deep reflection:
What do experienced product leaders hold in their heads that others don’t?

The answer led to the creation of the Opportunity Solution Tree, a simple visual model that helps teams:

• Externalize what they’re learning about customers
• See whether their opportunity space is rich or shallow
• Stay anchored on outcomes while exploring solutions

Rather than relying on expert intuition, teams can now build and share a mental model of their customer.

---

Continuous discovery is a habit, not a phase

One of Teresa’s strongest messages is this:

Continuous discovery is not about doing more research.
It’s about changing the rhythm of learning.

Talking to customers once a quarter is better than never.
Talking to customers once a month is better than once a quarter.
But weekly conversations fundamentally change how teams think.

Why?

Because teams make decisions every day.

The goal isn’t to validate every decision with a customer.
The goal is to build a mental model that matches how customers think, so everyday decisions naturally align with real needs.

---

The Product Trio and the end of clean role boundaries

Teresa popularized the concept of the Product Trio: Product, Design, and Engineering working together from the very beginning.

What stood out in this conversation is how much this model is evolving.

With Generative AI:

• Engineers are shaping product decisions through feasibility constraints
• Designers are engaging deeply in discovery and sense-making
• Product managers are increasingly required to understand technical evaluation, quality, and trade-offs

The clean boundaries between roles are fading.

And that’s uncomfortable.

But Teresa sees this as an opportunity:
Teams that embrace cross-functional collaboration and shared ownership will move faster and learn better.

---

Opportunity Solution Trees in practice

The Opportunity Solution Tree helps teams navigate the messiness of outcome-driven work.

Instead of reacting to:

• the loudest stakeholder
• the most recent customer complaint
• the shiniest new technology

Teams:

1. Start with a clear outcome
2. Map customer opportunities based on real stories
3. Decide where to play strategically
4. Explore and test solutions intentionally

This structure reduces overwhelm and helps teams stay focused while still embracing uncertainty.

---

Leadership in an unpredictable world

Teresa connects continuous discovery to a broader leadership shift.

COVID.
Generative AI.
Geopolitical instability.

The illusion of predictability is gone.

Yet many organizations still operate with:

• fixed annual roadmaps
• long-term project commitments
• output-driven management

Teresa argues that leaders must:

• Accept ambiguity
• Shift from control to trust
• Enable learning rather than demand certainty

This doesn’t happen through big transformations.
It happens through small habit changes, starting with ourselves.

“Organizational change doesn’t start with convincing others.
It starts with changing how you work.”

---

What Teresa is exploring now

Today, Teresa is deeply engaged in exploring how Generative AI changes product discovery and product management:

• AI prototyping in discovery
• Evaluating non-deterministic products
• Evolving product roles and collaboration models

She is actively sharing these learnings on Product Talk, continuing her long-standing mission: helping teams make better decisions by learning faster.

---

A closing question

If your team had a clearer, shared mental model of its customers…

What decisions would you make differently tomorrow?

References:

• Teresa’s blog: Product Talk
• Her book: Continuous Discovery Habits: Discover Products that Create Customer Value and Business Value

Here is the transcript:

Alexis: [00:00:00] Welcome to Le Podcast on Emerging Leadership. I’m your host, Alexis Morville. 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 product.

Through our 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 [00:01:00] introduce yourself to someone you just met?

Teresa: Ah, that’s a great question. As far as 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, 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: Okay. I really like that. So how did your journey led you to write the book?

Teresa: Yeah, this is a big one. It took a long time for me to write the book.

People ask me like, 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. So. It really goes back to 2016. So in 2016, I was several years into working as a discovery coach. I’ve been working with [00:02:00] dozens of teams, really just looking at like, how do they build fast feedback loops as they make decisions about what to build.

So are they interviewing customers? They testing their ideas. And I mentioned 2016 because I was working with a team. And they said, they came to their coaching session and they said, Theresa, we really love our sessions, but we’re afraid we won’t know what to do when you’re not here. That like really landed with me because here’s the thing, I decided to work as a coach and not a consultant because I want to leave people better off.

I wanna empower people to do this on their own. I didn’t wanna build a dependency. So this feedback from this team was a little bit gut wrenching for me. And I sat down and I started to think about like how am I making decisions about what to do next in discovery? And this was not the first time I like had this thought for probably.

Five or six years prior to this, especially working with engineers and working with product teams. [00:03:00] Trying to think about like, what do I hold in my head that my peers don’t? That’s like keeping us from being aligned. And around this same time I was reading Andrew’s Erickson’s book Peak, which is all about expertise and deliberate practice and what distinguishes experts from novices.

And one of the ideas in the book is this idea of experts have. Mental representations that are different from what novices have. And this was exactly the insight I needed. I was like, okay, what is the mental representation I have in my head about discovery that the teams that I’m coaching don’t? And that’s what led to the Opportunity Solution Tree.

So for listeners who aren’t familiar with this, and Opportunity Solution Tree is just 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, paint points and desires. Those are opportunities. They literally map them on the tree and then they’re looking for what solutions match [00:04:00] one-to-one to those opportunities.

And so it’s really simple, but what it does is it gives you a visual cue for like, 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? Mm-hmm. So it was in, I think, August of 2016, I introduced this visual to this team for the first time.

And it had a huge impact right away, like right away. And I was like, oh, this is a thing. Like I’m a product person. I know that things don’t have a huge impact right away. And so when it did, I was like, there’s something here. This is my very long way of answering your question, which is I start, I was like, I have to write a book about this.

Alexis: Right?

Teresa: And I started trying to write that book in 2016. But I struggled because books are waterfall. You write the whole book and you release it in hopes people like it. And I refuse to operate that way. And so it took me several years to figure out like, how do I test the [00:05:00] content in the book? How do I know that it’s gonna be good?

How do I know that it’s gonna be actionable? And so I spent several years. Taking all my discovery knowledge, codifying it into online courses, watching students engage with it in both my coaching practice and in my online courses. And then once I felt like it was clear enough and good enough, I wrote the book.

Alexis: Ah, excellent, excellent. This is very interesting because I’ve heard a lot of people saying, oh yeah, we, we build up a training course because the book was successful, so people want, wanted to buy training from us. Yeah. Okay.

Teresa: I went the other way around because I needed a feedback loop. I needed to know what was clear, what was confusing, where did people get stuck, and then I think it really comes out in the book, like every chapter.

Ends with anti-patterns, like those came from real coaching sessions and real course students. All the activities in the book are things we do in our courses. So they’ve been vetted and tested with, I mean, at this point, hundreds of teams. So maybe the real [00:06:00] answer to how did the book do so well is that I tested all of the content like crazy, but I will say like in 2016, I said I was gonna write a book.

And so for. Five years, people said, where’s your book? Yeah. And I’ve learned to not put timelines on things, so they had to just keep waiting.

Alexis: Yeah. That’s, uh, that’s good. That would’ve been, uh, terrible to have a, a kind of a deadline that forces you to publish something that, uh, that’s not good. Early on, you introduced the idea of the, the product, and could you.

Why this T prioritization tool and how those roles effectively collaborate.

Teresa: You know what’s funny is that I didn’t create this idea, like this idea 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 why people attribute this idea to me, I did include it in the book, but I also just gave it simple language.

So I heard a lot of people talking about like triads, [00:07:00] and I remember the first time I heard that word. I was like, what’s a triad? And so I called it a product trio, and that’s because I just really think that language matters. I mean, I’ve introduced my own terrible language. The Opportunity Solution Tree is a terrible name.

So like, I’m not critical of this, but like I tried really hard with this idea of a product trio to just simplify the language. And I think it has helped because it’s now a much more popular and much more common idea. It’s this idea of how do we cross-functionally collaborate from the very beginning?

And it sounds so simple, but in business we’re really bad at cross-functional collaboration and we see it up and down the organization. It’s why like so many executive teams are dysfunctional. ’cause we don’t know how to cross-functionally collaborate in a lot of ways. Business culture rewards us for staying in our silo and like being territorial.

I think we have enough years of experience now, like across the industry to recognize that if we’re gonna build a good digital product that’s always [00:08:00] evolving and always improving and always getting better. It really does take a cross-functional mindset. So we need to keep. Business perspective and viability in mind.

We need to keep the customer of course, in mind. And how do we make it delightful for the customer? And how do we make it usable for the customer? And how do we make sure that we’re building something that satisfies a real need and not just like an aspirational need. It has to be feasible. And you know, for a long time on the internet, feasible was easy.

We were just building crud apps, people aren’t familiar with that term. It’s just like things where you create and update things and delete things like it’s not. Really simple like. Webpages are just front ends to databases. Like there wasn’t a lot of feasibility complexity. Well, today we’re seeing a lot of that change because generative AI is forcing a lot of teams to debate and discuss what’s feasible with this new technology.

And so we can define this as roles like for most companies, a typical product trio is a product manager, a [00:09:00] designer, and a software engineer. But it’s not that clean. And actually, I think generative AI is. Is making this even messier. We have a lot of designers that have a good human-centered like research background, and they want to be involved in the decisions about what to build.

We have a lot of product managers that have MBAs and maybe they’re weak on the usability or the desirability side, but they’re really strong on the viability side. We have a lot of product managers that are the complete opposite. Maybe they came from a UX background, maybe they’re just grew up in a consumer product world and they’ve never had to think about viability.

We see the same with engineers. Everybody has worked with that engineer that just had a really good intuitive product mindset where a lot of our front eng engineers have good design skills. So I think like it’s easy to think about this as fixed roles, but I think 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 [00:10:00] all those skills and perspectives are represented? And so what we used to do is we used to silo it, right? The product manager wrote requirements. It got handed to the designer who did the design work. It all got handed to the engineer.

And the problem with this is there was a ton of rework. By the time it gets to the engineer, they’re like, this isn’t feasible. And we have to start over and start. It’s like the assembly line gets reset. Whereas I think when we see these roles working together from the beginning, we get much better solutions and we get ’em faster.

It’s kind of counterintuitive.

Alexis: So what are the common challenges team face when adopting the continuous discovery habit?

Teresa: How long do we have? I mean, since we were just talking about team collaboration, I’m gonna say this is a big one. Like of course we all wanna be on a team and we’re gonna work together.

It’s really hard. We’ve been trained to be territorial. Generative AI is gonna make this worse. I’ve been building my first, I. Generative AI [00:11:00] product and it’s, I’m starting to learn myself about like, what does it take to make these products good? So I’m starting for people familiar with this process. I’m starting to get into the world of like evals and guardrails and like how do we evaluate.

The success of a non-deterministic product. And that’s a very, that’s a challenging question. And this is all like frontier. We’re all figuring it out together.

Alexis: Mm-hmm.

Teresa: Well, it turns out like the methods that are starting to arise to evaluate these tools are like required domain expertise that your product manager or your designer, or even your business stakeholders might have.

And it requires engineering expertise to like know what’s possible with code and how to code up these automated evaluations. And it requires like a continuous process of both. And there’s a lot of conversations in this space around who does what, does the engineer do this part? Does the product manager do this part?

And it’s messy. And I think the answer is gonna be the person closest to the customer is gonna do one part. The [00:12:00] person that has the necessary engineering skills might do another part, but who that is from a role standpoint might change from team to team. Right. So like for myself personally, I’ve actually spanned all three roles.

I started out as an interaction designer and a front end web developer. I moved into product management. I spent most of my career as a product manager and a product leader. But in the last three years, I’ve moved back into coding, and in the last month as I’ve been building this AI product, I took this course on AI evals and I am doing the work of an AI engineer.

I just learned, like, I literally implemented my first set of automated evals. And I did it in a language I had never programmed in and I did it in a tool I had never used before and I did it all in one week. And the reason why that was possible is because chat GPT guided me through all of it.

Alexis: Yeah.

Teresa: So like these boundaries are blurring, like designers can now code and product managers can design, and engineers are gonna have to learn some design skills and some product management skills.

The product trio [00:13:00] concept, like the underlying principle, cross-functional collaboration stays, I don’t think it’s going anywhere. But these like really clean boundaries we have between our roles, they’re getting obliterated.

Alexis: Yeah.

Teresa: And that it’s hard for people. We identify with our jobs, designers identify as designers, product people identify as product people.

Engineers definitely identify as engineers and those identities are gonna get. Stretched and blurred and it’s gonna cause some discomfort for people. So I think that’s the first thing. I think like we already see this just with the discovery habits. Forget AI already with the Discovery habits.

Collaboration is hard.

Alexis: Mm-hmm.

Teresa: I think it’s gonna get a lot harder. It’s gonna get a lot blurrier and messier, but I actually think that makes it more fun. I like spanning boundaries. I think most people like spanning boundaries. I think there’s real organizational challenges, like our 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 and management without.

[00:14:00] Dictating outputs. Um, I think that’s hard. Like leaders have to learn how to do that, and then product teams have to learn how to show their work so their leaders trust they’re making progress. That’s a huge barrier on both sides.

Alexis: Mm-hmm.

Teresa: Some companies think there’s a significant barrier in getting access to customers.

In my experience, this is more mental roadblocks. This is more like forms of resistance than it is tangible, real barriers to customers. And I’m gonna say that even in regulated industries. So all my folks working in regular, in, in regulated industries wanna say, we have all these rules. Those are just constraints.

It’s still possible. There are people in every industry doing this, but I would say those are the top three. Like how do we really work as a team? How does the leader team interaction change? And then how do we get over our mental resistance to actually talking to customers?

Alexis: It’s very interesting because while you were talking, I was thinking of a team I’m working with and, [00:15:00] uh.

They’re in a regulated industry in the healthcare industry, of course, and they have a a lot of good reasons for not being able to do things, which is very interesting because when you look really in details into it, you realize that maybe you can do a little bit more of that.

Teresa: You know, healthcare’s a great example.

So here in the US we have a law, hipaa. It’s our healthcare privacy law. Here’s the basis of the law. It says that if I tell you my doctor something. You can’t go share that with other people. Like it’s my privacy, like I have a right to privacy in the healthcare ecosystem.

Alexis: Mm-hmm.

Teresa: Okay. So now you’re a product manager working on a healthcare product.

That law doesn’t say, I can’t willingly share my healthcare experience with you. It doesn’t say that. That’s not what the law says. Right. But teams interpret it as we have to be HIPAA client, we’re not allowed to talk to our customers. And so a lot of this is like, yes, we have to understand our regional laws.

Yes, we have to understand our company policies. And especially [00:16:00] for a lot of HIPAA compliant companies, they have policies that say you can’t talk to customers ’cause they don’t wanna train them on the HIPAA requirements. So like 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 their experience with you.

I’ve never seen a law that restricted that yet.

Alexis: I have a questions about product managers who, who struggle to really understand the value of user experience of UX work, especially in that context of the discovery process. What are the misconceptions that you see there

Teresa: when it comes to ux? I actually see two extremes.

I think both are wrong. So one extreme is our engineers can just build it. We’re not reinventing the wheel. We have a design library. They can just throw together some components. We don’t need a designer on this. The other extreme is we need a designer on everything. Everything [00:17:00] needs to be delightful and perfect.

I actually think both are completely wrong. Like most things probably need a designer to at least glance at it. But we don’t need every single part of our product to be delightful. If that was our requirement, we probably would never ship a product. And we see this like look at the most design oriented company on the planet I’m gonna say is Apple.

Whether you like their design or not. Like they’re clearly a company committed to design.

Alexis: Mm-hmm.

Teresa: There are lots of parts of their website that are horrendous to use. This is true for any product. In fact, I get frustrated with my iPhone on a regular basis. This is true for any product. It is impossible to create a perfectly designed product.

Now, that doesn’t mean we shouldn’t aspire to that. What it means is that like we have to make prioritization decisions. What are the parts of the customer journey that are most important to get right? What are the moments in the journey where delight matters the most? Where can we just not reinvent the wheel and use a common pattern?

And [00:18:00] so I think. It’s, I see it with UXers in particular. We go to design school, we learn about the delightfulness of design and we admire these like beautiful products. And we take that and we try to apply it to everything. And like digital products have big footprints. They’re constantly changing. It’s just not realistic.

And then people that haven’t been exposed to this design world take it the other way around. Like I still meet companies that have 20 product managers and zero designers. And I’m like, how is this still happening? Right. And it’s ’cause they just have this belief of like, oh, it’s just colors on a website.

And I got a design palette. I paid a dis, a agency to gimme a design palette and my engineers can just apply it. Okay. Well you’re overlooking information architecture and interaction design and like all these other elements of design practice. And not to mention like your engineers probably don’t know how to design that.

Design palette, that color palette in a way that is good visual design. And so I think [00:19:00] it’s, especially if you read like the internet at all, social media in particular, like it’s really easy to think the world is these extremes. Whereas I think in almost everything, the right response is somewhere in the middle.

It’s much more nuanced.

Alexis: Yeah.

Teresa: But nuance doesn’t win on social media, so it’s not what we read about

Alexis: unfortunately. I would love that to be more nuanced. We would all learn in the process. You emphasize weekly customer interviews. Yeah. And uh, the first time I discussed that with, with the product team, they were puzzled.

They had in their mind really a process that seems radically different from that. Yeah. Too far away for them to even think about it. And, uh, the would do, it was also a concern, which. Kind of funny. So you have a, you have very strong opinion on that and I, I really love to hear what you have to say on that.

Teresa: Yeah. So first of all, let’s talk about why I recommend this, and we can get into how can teams [00:20:00] get there. So,

Alexis: yeah,

Teresa: the big thing here, for me, discovery is about if we wanna make good decisions about what to build, we have to get feedback on those decisions, right? Like. We have so many examples of products where the people that designed them or built them did not get feedback along the way, and they flopped.

Or maybe they didn’t flop, like maybe they had the right idea for a right moment and they took off, but they didn’t sustain. Clubhouse comes to mind, if you remember Clubhouse. Like the beginning of the pandemic, it was this like audio go in a room chat with people. It was wildly popular for like three months and then it just petered out.

Right? Yeah. We see a lot of products like this and I think some early success can sometimes be problematic, right? Like where we don’t get over the crossing the chasm hump, we don’t get past the early adopters, and so we gotta be really careful about who are we designing for? Who are we building for? What are their needs and how many [00:21:00] people out there are like those people, right?

So this is starting with the ideal customer profile, really understanding the market size, really digging in and understanding what are the needs that they care about, and are we adequately solving those needs? And that’s like the big picture. That’s like the strategic stuff. But then, okay, so we’ve identified there’s this need, I’m gonna stick with Clubhouse is my example.

Like people are all stuck at home and they wanna connect with other people. Okay, great. That is a real need. And in that moment it definitely was a real need. But now we need to get into like, okay, as we build this product, we have daily decisions about how it should work. How do we promote what’s happening in a room?

Who’s allowed to come in? How many people are allowed to talk at the same time? What happens when people say offensive things? How are we gonna handle that? All these things that arise, we make millions of decisions like constantly. All day long. Everybody on your product team is making decisions. Where’s the feedback loop for all those decisions?

And when I say feedback loop, I don’t mean like. [00:22:00] I can’t change this one line of code until I get feedback from a customer. I mean, we need to have constant exposure to who we’re building for to make sure all these teeny tiny decisions work for them. And if we don’t have that constant exposure, we’re just like in a dark room looking for a teeny, tiny thing on the floor.

Like we’re lucky if we find it. And so the why behind this is the more we talk to our customers, the more we engage with them, the more exposure we have to them, the more likely these teeny tiny decisions are gonna work for them. And so if I talk to a customer once a month, that’s better than never.

Alexis: Mm-hmm.

Teresa: But I’m making decisions all day, every day. So the more exposure I have, the more likely. Those all day everyday decisions are gonna fit. And here’s the thing. Too many teams use their customer interviews to walk in and say, Hey, here’s my shiny solution I’m working on. What do you think? That’s not the [00:23:00] purpose of these interviews.

When I say talk to your customers every week, it’s not go sell to your customer every week. It’s not Go show off your shiny object every week is go talk to your customer. And learn about their world. Who are they? What are they doing? What are their goals? What are the stories in which those, what are they doing?

Why? Collect those stories. Your goal is to understand your customer’s mental model of how they approach whatever it is they’re trying to accomplish. So if I work at Spotify, I’m gonna interview people about the role music plays in their life, when they listen to it, where they listen to it, how they listening to it, where they learn about new music.

And I’m gonna collect lots and lots of stories about how they engage with music. It’s not gonna tell me what product to build. It’s gonna tell me how my customer’s mental model of music works. Mm-hmm. And then my job is to make sure my product matches that mental model. And so all those hundreds of decisions I’m making every day have to be [00:24:00] consistent with that mental model.

If they’re not consistent. It’s not gonna work for my customer. So it’s not that I have to get feedback on every single decision that I make. It’s that I have to build a mental model that matches my customer’s mental model. And that mental model tells me how to make all those daily decisions

Alexis: that leads us to the, the how and who are doing.

Who are doing. Okay. So that’s

Teresa: the why. So let’s get into the how. What I tell people is we get to take a continuous improvement mindset to our own discovery habits. So if you’ve never talked to a customer, forget that I told you once a week, just go talk to one customer. Like just find the first person to talk to.

And I don’t mean like go join a sales call, I mean. Talk to a customer about their world, their goals, their context, their stories, not your product, their stories. Once you’ve done that, I want you to think about how do I talk to my second customer and then by the time you’ve talked to two or three, I don’t need to [00:25:00] convince you, you should do it more.

You’re already convinced you should do it more because so much magic happens in those first couple of conversations. So like, if you’ve like for people listening, if you’ve literally never talked to a customer about their world, so I don’t mean your product, I don’t mean a sales call, I don’t mean handling a support ticket.

I mean just literally talking to another human and being curious about how they do whatever your problem is, Des, whatever your product is designed to solve. That’s it. Just how do you do this thing after you get to two or three? Now you’re like, wow, this is mind blowingly amazing. And we need to start to think about how do we operationalize it?

So how do we do this on a regular basis? We have to create a continuous pipeline of people to talk to. I recommend people automate the recruiting process. I share tips on how to do this in the book. We also have a course on customer recruiting that shares five different strategies on how to automate your recruiting process with lots and lots of examples, and [00:26:00] then you have to learn how to ask the right questions.

So how do you make sure you’re getting reliable feedback? We teach a very simple interviewing format focused on collecting customer stories. The reason why I do that is I think any human on the planet can learn how to do it. It’s evidence-based, it’s grounded in good qualitative research practices and it’s, it solves this problem of like, how do I build a mental model that matches my customers?

Alexis: Mm-hmm.

Teresa: Right? So like it doesn’t answer every research question you might ever have. We probably still want researchers involved in like other types of research, but it allows a product team to close the gap. Like, how do I make sure the decisions I’m making every day match the mental model of my customer?

And then once you’ve. Sort of worked on your pipeline of interview participant problems. You’re starting to practice asking better interview questions. Now you can look at your cadence. If you’re talking to someone once a month, try to get to every three weeks. Then try to get to every two weeks. I use the [00:27:00] guideline of once a week.

I think that’s our minimum. We def like that. We wanna aspire to plenty of teams do multiple a week. Plenty of teams do every day.

Alexis: Yeah, and I assume that. Product managers and probably, uh, UX people would probably be comfortable discussing with customers or discussing with real users. Our engineers on the team would benefit from doing it.

Teresa: Yeah, I want every single person who’s involved building the product to at least be listening to the conversations. What you’re gonna find is the more people on your team listen to the conversations, the more they’re gonna wanna get involved in the conversations. But I think you can start with, you can have the person on your team who’s most comfortable conducting interviews, conduct the interview.

And have everybody else observe or watch the video afterwards, but not, not clips, not just read the transcript, not just read the notes, see the participant [00:28:00] share their story. And then I think with time it does make sense to have multiple people on the team comfortable conducting interviews. It just helps with the resiliency of the habit.

If you have a product manager who does all the interviews and then they leave the company, what happens to your team? They go on vacation, you go two weeks without anybody conducting interviews. They’re sick unexpectedly who’s gonna conduct today’s interview? So the more people comfortable with it, the more resilient the habit is.

But really I want everybody watching the interviews, including our engineers.

Alexis: Yeah. You can see that I’m trying to find, uh, the arguments to convince people that it’s very, very important. Yeah. And making decisions. Hopefully as, as a team, more often than not, and as we are involved in those decisions, having that mental model is critical.

Yeah. So that’s a, that’s an important one. You mentioned the opportunity Solution tree before. Really beautiful name. [00:29:00] Um, do you have a concrete example to walk us through what it is really, but with an example, not just saying us. What it’s.

Teresa: Yeah. So in the book, I use streaming entertainment as my example, and that’s because it’s available worldwide, like Netflix is everywhere.

We’re broadly familiar with it.

Alexis: Yeah.

Teresa: So let’s talk about a tree. The purpose of an Opportunity Solution Tree is to help you as a cross-functional team, drive an outcome and to stay aligned in your discovery work as you drive the outcome. So the challenge is when we shift from focusing on just building outputs to trying to impact a metrics, so driving an outcome.

It’s messy. We have a lot of false starts. We do a lot of things that don’t work. We do some things that do work. We learn a lot from our interviews. It can feel really overwhelming of what do we pay attention to? What do we not pay attention to? As we get into solutions, it’s really easy to fall pre to like shiny object syndrome and we end up working with solutions that don’t actually [00:30:00] match anything we heard in our interview.

It just was like a cool application and new technology. We’re seeing a lot of that right now. Right? So the goal with the Opportunity Solution Tree is like, how do we keep everybody aligned and how do we help them know what to do when? So when we, when a team is new to driving outcomes, what they don’t realize is the whole nature of their job changes.

So when we’re told to build a thing, it’s very deterministic. Like it’s very. Narrowly defined like, yes, there’s a lot of decisions to make about the requirements for that thing and how to implement it, and the underlying data model and those decisions all matter. I’m not trivializing them, but what to do has been clearly defined when you’re starting with an outcome.

What to do. It feels like a blank page problem. It feels like we could do a hundred thousand things. How are we gonna decide? It’s this very open-ended ill, ill-defined problem. What I recommend teams do is they start by interviewing customers. They’re collecting stories. One of the things they [00:31:00] hear in their stories is pain points, friction, unmet needs, des unsatisfied desires, right?

So as they collect stories, they’re hearing about things that they could help. Those are opportunities. And so the team maps out the opportunities and then they’re gonna choose a opportunity to solve. So let me give the example. Using Netflix, I’m starting with an outcome. An outcome represents a business need.

They’re typically derived from your revenue model. So Netflix is a subscription business. The types of outcomes they’re gonna care about acquiring more customers, increasing their average monthly spend. Increasing how long they stick around. So retention, lifetime value, right? Those are the primary drivers of what drives revenue for Netflix.

Now, each of those I can further deconstruct, like let’s say I have a team that’s focused on retention. Okay, well, what are the factors that drive retention? This is almost always tied to the value your product delivers. So what does Netflix deliver from a value [00:32:00] standpoint? Well, they entertain me. Okay, well, how do I know that you’re being entertained?

Well, you might watch Netflix more often, so maybe my outcome is to increase the average viewing minutes per week. Okay, that’s my outcome at the top of my tree Now. I am, this is, I’m new to this outcome. I don’t know why you watch Netflix or how you decide how much to watch, or what prevents you from watching more.

So I have to go interview customers, and as I interview customers, I’m gonna just collect their story. Tell me about the last time you watched Netflix, or tell me about the last time you watched tv. Maybe you’re watching a competitive service. And as I collect those stories, I’m gonna hear things like. It took 45 minutes to find a show that I might like, or my friend recommended this show and I’m checking it out, but I can’t tell if I’m gonna like it or not.

Or we might hear stories like, I’m in the middle of watching this TV series, but I can’t figure out how to get back to it. Or we might hear things [00:33:00] like, I was in a hotel on a really terrible wifi network and it took like seven minutes for the show to load. It paused 14 times during my 30 minute episode, and it was a really terrible experience.

This is what comes from real world stories. Mm-hmm. Right? So now I can collect those as opportunities on my tree and I, what I recommend is that people organize their opportunities based on steps in the journey. So the top level of the tree might be, I need to find something to watch. I wanna have a good viewing experience.

I don’t wanna stay up too late, so like I wanna go to bed on time. Right? And then under, I can’t find something to watch. I need to find something to watch. We might uncover all these pain points. Like I can’t find the show I was watching. I can’t tell if the show is good or not. I just finished my show.

Like I want a similar show. I wanna know who’s in this show. Right? These are all opportunities, just like what does your customer need to be able to find something to watch? And then around the viewing experience, like what do they need [00:34:00] for it to be a good viewing experience? Well, they don’t wanna wait for it to buffer forever, or they wanna be able to rewind quickly and find what they’re looking for or.

They need to be able to pause to go get another beer, like whatever it is, right? This is what emerges from real stories. So then we collect all these on this visual and we organize them based on steps in the journey. We structure ’em, some are, some are sub parts of others, and then we get to decide, like we’ve taken an inventory of what we’re hearing across our interviews, and now we can make a strategic decision, like where do we wanna play?

Which of these opportunities are most important for us to solve? And this sounds so obvious and trivial, but like what do most teams do? They’re reacting to the most recent conversation. They heard. Stakeholder pulls ’em into a customer conversation. Somebody has a pain point, they’re like, oh, hands on deck.

Let’s solve that right now.

Alexis: Mm-hmm.

Teresa: There’s, we’re missing this strategic decision about where do we wanna play? And the thing is, the opportunity space is infinite. Like there’s a [00:35:00] million. Needs and pain points and desires that are unmet. When we talk to customers, we really need to make the strategic decision of what differentiates us in the market, what supports our company’s strategic initiatives, like where do we wanna play?

We can’t do all of this stuff. And so that’s a lot of what we get with the Opportunity Solution Tree is it gives us a place to collect all that we’re hearing, and it helps with this like overwhelm. We’ve talked to so many customers, they have so many needs. Where do we play? Well, we filter based on our outcome.

We make that strategic decision about what has an impact for us as a team, and then we choose a small starting place and then that bounds the types of solutions we consider and then we test, is our proposed solution gonna actually address that opportunity in a way that’s gonna drive that outcome.

Alexis: And then we are able to experiment and, uh, and really test all our hypothesis.

I love it. Oh, thank you very much. That was, uh, perfect. Impressive. You mentioned the importance of [00:36:00] outcome and versus outputs and, uh, the roles of leaders in changing their language and or changing what they believe they have to do. Do you see other things about the roles of leaders? In that way, different ways of D, different way of working.

Teresa: Yeah. So the first thing I’ll say is we’ve seen three major world event, two major world events that everybody has been subject to and maybe and a third depending on where you live in the world. That I think is finally teaching organizations that we need to be outcome focused. So the first was COVID.

The entire world shut down very quickly. Everybody worked from home. The way we work changed suddenly. What does this mean? It means that you could look at your roadmap and you probably had to throw a lot of it away. You probably had to change a lot of it. If you were Zoom, you had to react to a huge new market opportunity.

If you were building software for restaurants, you probably lost a lot of customers very quickly, right? Like we all just suddenly had to like adapt. [00:37:00] Okay. Second major world event, the rise of generative ai. Like we’re all going through this right now. Like what does this new technology do for me? How does it work?

It’s disrupting everybody’s road roadmap, like literally everybody’s roadmaps. Third one, and this is really regional, but I think it’s affecting a lot more people than we realize is just all the geopolitical climate, right? Whether we’re talking about the Russia, Ukraine, war, now we have Israel, Iran, we have.

Our craziness with tariffs affecting the global economic environment, right? There’s been like so much geopolitical craziness, for lack of a better word, that I think companies are really struggling with. How do we predict the year? And so I think the combination of all three of these things, and they’ve basically been back to back to back.

I think leaders are starting to recognize, like we’ve all said it for decades, right? Like there’s all these acronyms in the business literature about like ambiguity and uncertainty, and there’s frameworks, [00:38:00] but like companies don’t work this way. They still come up with five year strategic plans and they still want 12 month roadmaps, and they wanna know exactly what you’re doing when.

We still operate businesses as if the future is predictable.

Alexis: Mm-hmm.

Teresa: But I think we’re starting to see some cracks in this. I think we’ve had so much uncertainty and so much chaos, and so much craziness over the last five years. The companies are like, okay, like I. I’m tapping out like we’re no longer planning five years in advance because I can barely plan next month.

I think this is a good thing. This is, I think is the silver lining of all of the nonsense that we’ve been through, is that companies are starting to see, we absolutely have to learn how to be adaptable, but it’s a whole new skillset across the organization. Like, how does my CFO plan if we didn’t fund projects for the year?

How does my marketing team run marketing campaigns if they don’t know launch dates? How does my sales team close deals if they can’t say when features are coming? Like [00:39:00] literally everybody in the organization has to change the way that they work. And this is why we now have books on transformations and we have billion dollar consultancies on transformations and we have, right, and we have like hundreds of solo consultants supporting transformations like.

This is a giant shift for businesses and we don’t know how to do it yet. I’ll be the first to say we don’t know how to do it yet. Like it’s still a work in progress. We’re still feeling our way through it, but here’s what I know. From an organizational change standpoint and from a coaching standpoint, nothing changes until the mindset changes, until people believe there’s a need for the change.

I think what’s happened in the last five years is we’re starting to believe there’s a need for the change. So I’m excited about that. Like I’m not excited. We had to go through COVID. I am excited about generative ai. I’m not excited about the geopolitical stuff, so mixed bag. But I am excited that we are starting to see evidence [00:40:00] that companies are taking this seriously.

Alexis: Yeah. That’s a strong belief that could help us and getting to that desire. Yeah. To be more adaptable and, yeah. I, I. Discussing about beyond budgeting. Yeah. And being absolutely convinced and, uh, and is incredible and I, I was going back to my organization explaining why we needed to and not, not,

Teresa: yeah.

Alexis: That was not so easy to convince people.

Teresa: Yeah. One of my mantras this year is really around organizational change. Doesn’t happen as a big change. It happens through a series of teeny, tiny changes. So I like 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 that you work.

Then move on to the next habit. And it turns out when we focus on our own behavior, when we [00:41:00] change our own habits

Alexis: mm-hmm.

Teresa: People around us get curious. Hey, you’re doing this thing that’s really interesting. What is it that you’re doing? Now we have an invitation to share when we come in and say, Hey, I learned this new thing.

We’re doing everything wrong. What do people do? They dig their heels in. They say, no way. I’m stubborn that I, I hate frameworks. Influencers don’t know anything. You can’t read anything. You can’t learn anything from books. You just learn by doing. Product management’s different everywhere. Like we’ve all heard these things, right?

Alexis: Absolutely.

Teresa: Yeah. So. It’s really like, you almost have to be sneaky about organizational change and like the hard truth is it starts with yourself. Nobody wants to hear they’re the problem, right? So like the only way to drive change, I think, 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. That’s a, that was a perfect. What do you think, do you wanna share anything? Anything else [00:42:00] about. What you’re currently working on, you, you give us a glimpse or about anything else?

Teresa: Yeah, I’ll share. So if any listeners are new to my work, I do blog@producttalk.org.

The book is called Continuous Discovery Habits. I’m assuming we’ll add links to those in the show notes yet. The other thing I’ll share, so I’ve done a ton of work over the last, we’re almost coming up on 15 years, which is crazy to me about discovery, how to do discovery well, how to build fast feedback loops with your customers.

I love all of it. I’m not done. There’s still more work to do. There’s still plenty of teams not doing discovery. Um, but in this exact moment in time, like for the last four months, I’ve been diving deep on. How to use generative AI to support teaching. So I’ve been building my first LM based apps, which has been really fun and we’re already using some of them in our courses.

But it also introduced me to this whole new world of how product management is changing when the product that we’re building [00:43:00] is non-deterministic.

Alexis: Mm-hmm.

Teresa: And how do we measure quality when the product is non-deterministic? And I’m gonna be blogging way more about this, so like in July, I have a blog post coming out about.

What role AI prototyping can play in discovery. I’ll be doing a blog post about what role, like how cross-functional teams should be doing evals and guardrails for LLM based apps and how to navigate that. ’cause it’s really not clear who does what. And I probably will do be doing a blog post about how our roles are blending even more than they already have and like how we need to mentally prepare for that.

Like if we really identify as one role. How to maybe start to adopt an identity of other rules and like. Build out your toolkit, your skill box, um, and, and maybe have that be your focus. So I think we’re all going through a ton of change because of generative ai. And I, I’ve been reluctant to write about this stuff ’cause it changes so fast.

But I think after [00:44:00] four months of like building with it, um, starting to develop. A point of view and I’ll be sharing much more about that@producttalk.org.

Alexis: Excellent. I am eager to read about that. Thank you very much for all the work you’re doing. It’s absolutely fantastic. And thank you for having joined the podcast today.

Teresa: Ah, thanks for having me. This was a fun conversation.

Flow is one of those words every organization wants, and few consistently achieve.

Teams are busy. Delivery slows down. Dependencies multiply. “Agile” rituals exist, but friction remains.

In this episode of Le Podcast on Emerging Leadership, I spoke with Manuel Pais, co-author of Team Topologies, a book that has shaped how many modern organizations think about team design, platform strategy, and sustainable delivery.

What I appreciate in Manuel’s approach is that it stays grounded. It is not a perfect target model to impose. It is a set of patterns that help teams evolve their structure and interactions over time.

Here are a few key ideas from our conversation.

---

The four team types

Not labels, but building blocks

Manuel revisits the four fundamental team types from Team Topologies:

Stream-aligned teams
Cross-functional teams with end-to-end ownership of a clear stream of value for a defined group of customers. The focus is not “owning a component”, it is owning outcomes.

Enabling teams
Small groups of specialists who help stream-aligned teams acquire skills, reduce gaps, and adopt better practices. Their job is to mentor and accelerate learning.

Platform teams
Teams that provide internal services in a self-serve manner, reducing friction and cognitive load for stream-aligned teams. Platform is not “a team that receives tickets”. Platform is a product.

Complicated subsystem teams
Used sparingly, for domains that genuinely require deep expertise and would otherwise overload stream-aligned teams. Useful, but risky when overused because they increase dependencies.

This is the important nuance: the model is designed to reduce dependencies and overload, not to create a new set of silos.

---

Cognitive load

The limit leaders ignore at their own risk

A major thread in our conversation is cognitive load.

Even the best teams hit a limit when:

• they must understand too many tools and systems
• they must coordinate with too many stakeholders
• they must navigate unclear processes and responsibilities
• they carry knowledge that should not be theirs to carry

Cognitive load is not just “too much work”. It is also “too much to hold in mind” as a team.

Manuel describes how he and his collaborators went deeper after the book, partnering with organizational psychology research to better identify what drives cognitive load.

The key shift is practical:
Instead of guessing why teams struggle, leaders can look for the dominant drivers and prioritize actions that actually reduce load.

---

Interactions matter more than structure

A common misstep is to read Team Topologies and think the job is complete once teams are labeled.

Manuel insists it is not the labels that matter. It is the interactions.

Team Topologies describes three core interaction modes:

Collaboration
Two teams working together to solve a shared problem or explore a new solution.

Facilitation
One team helping another team learn, gain skills, adopt practices, and become more capable.

X-as-a-Service
A mature service that teams can consume independently, with minimal coordination.

Healthy organizations intentionally switch between these interaction modes depending on the situation.

This is especially important for platform teams.

---

Platform teams should not become ticket factories

Many organizations believe they already have platform teams. Often, what they have is a team that processes requests.

Manuel explains that platform teams need to alternate interaction modes:

• collaborate to discover what stream-aligned teams truly need
• facilitate to help teams learn and adopt practices
• provide X-as-a-Service when the service is mature enough to self-serve

The goal is to reduce cognitive load and improve flow, not to centralize control.

---

The leader’s role

Make change safe, gradual, and supported

One of the strongest leadership messages in this episode is about how change is introduced.

Manuel advocates for evolutionary change, not big reorgs.

For leaders, this means:

• explicitly setting expectations that change will be iterative
• supporting learning as responsibilities shift
• investing in training, enabling help, and platforms that reduce load
• ensuring teams are not left alone to “figure it out”

The point is not to impose a perfect future model.
The point is to keep learning and adjusting.

---

A powerful idea: invest in flow enablers

Near the end, Manuel highlights something many organizations overlook.

If flow matters, someone must be accountable for noticing and improving it.

He argues for investing in dedicated roles or groups focused on flow: people who identify bottlenecks, remove friction, and help teams improve interactions and ways of working.

Not as a one-off transformation program.
As an ongoing capability.

In organizations where this exists, the return can be significant because removing bottlenecks often unlocks value that was already there but stuck behind dependencies and delays.

---

A question to take with you

If you want more flow, what are you doing to actively reduce cognitive load

And who in your organization wakes up every day focused on improving flow

Reference Links:

• Team Topologies Official Website
• Team Topologies Assessment
• Team Temperature Tool

Transcript:

Alexis: [00:00:00] Welcome to the podcast on Emerging Leadership. I’m your host, Alexis Monville. Today, I have the pleasure of speaking with Manuel Pais, co-author of the influential book Team Topologies. Manuel is a leading voice on organizational design and team effectiveness. In ‘Team Topologies,’ Manuel and his co-author, Matthew Skelton, explore how successful teams organize themselves to achieve continuous and sustainable delivery.

Manuel, welcome to the podcast on Emerging Leadership. How do you typically introduce yourself to someone you just met? 

Manuel: Hi, first of all, thanks for for having me. Depends what is the context, but in terms of explaining what I do, the most difficult is to explain to my kids. So someone told me this week, I think a good way to think about it is almost like a teacher for [00:01:00] companies like I am.

I wouldn’t say necessarily teaching, but helping organizations think about what else they might need to do to improve flow, to improve the engagement of teams. Obviously all the motivational aspects of getting teams to be more, to feel more autonomous and empowered, and but also delivering more value more independently to the customers.

I see myself. In that way a lot. I’ve always had interest in kind of the educational part. I’ve done a lot of editing and reporting for InfoQ as well, for example. So although I’m a software engineer by background, I really like to help people and teams and organizations be able to reflect and think about, okay, what might we need to do different in order to.

Improve our flow, improve the way we work, and also [00:02:00] provide more value to the customers. 

Alexis: I really like the idea of increasing the value and increasing the satisfaction of the people who are within the organization. So the both things really like that. Team topologies. Incredibly influential. What initially you to the challenge of organizational design?

Manuel: I think there were a couple of things. One is, I guess out of my. Curiosity to learn and try new things. I started my career as a developer, a Java developer, and then I had different roles as tester, release manager, and then team lead. And so that allowed me to start kind of the same things from different perspective, right?

Mm-hmm. As someone in, in a test team look at. The work that the development teams are doing. You know, obviously I’m now have fairly fair, a fair amount of experience, 25 years, so I feel [00:03:00] a bit old, but I can remember well when there was all this friction between, you know, test team and the ops team and the dev team and the, the teams being so very much isolated and, and trying to do the best within their scope.

But that was not necessarily very helpful for. The customer at the end that is waiting for some changes or some new product and so on. So that kind of start got me started thinking, okay, why at the end of the day, we’re all working in the, we should be all working towards the same goal, which is, you know, to deliver this product or to deliver some new value to the customer.

So why do we have. Sort of sometimes very antagonistic views of each other. And then the other thing that happened was, this was sort of in the back of my head as I was working for different companies, and then when I moved into consulting around 2015, so together with Matthew Skelton, the other [00:04:00] co-author of the book, Tim Topologies, and we were doing consulting around DevOps and continuous delivery.

This. Feeling that actually a lot of the issues are not really so as much the technical side as it is the people, the interactions, the sometimes lack of direction or too much isolation. Between teams that were the real problem. So we, we would often have client engagements where we were asked kind of a more technical job to, you know, implement some pipelines, help us adopt some DevOps practices, which is, which is fine and they’re helpful.

But at the end, the real issues were happening in the interactions or lack of interactions between teams, incentives that were not. Aligned, which at the end of the day were not beneficial for the organization and, and the customers. So we, during this consulting years, [00:05:00] we were. Essentially applying the patterns that we talk about in the book team topologies and in our academy and so on, with different customers at the kind of more localized way.

Like, let’s see if, for example, the platform pattern, can we help this team usually, for example, team that’s taking care of the CICD pipelines, can they act in a more. Platform as a product type of way that we talk about. Right. What would be needed? Well, they would need to become, provide services that are more self-service.

They would need to reduce the amount of, you know, ticket based back and forth to reduce the time it takes to provide what, what, uh, product teams need. And so that was sort of the origin. And obviously today, almost six years after the first edition of the book, it’s really great to see. So many examples and case studies of actually applying the whole of, [00:06:00] or many of the team topology patterns together and that providing a lot of benefit and and return.

Alexis: You already started, and I’m sure you are probably a little bit tired of doing it, but could you briefly outline the, the four types of teams that you in the book? 

Manuel: Sure. It’s a bit like the. Playing your greatest hits. Right? But it’s totally fine. So the starting point are what we call stream malign teams.

So this would are very much your cross-functional product teams. Type that with two, I would say two particularities. One is that it’s a kind of product team, but that is working on end-to-end, that has end-to-end ownership of. A stream that is valuable to customers. So there are some identified types of customers at the end of the day for that team that they know these are the people or the [00:07:00] type of customers that we are serving.

And whatever we do, they are the primary customers that we need to sort of serve, if you like. And then the second thing is this idea of stream, because. You could say you have a product team, but that if they’re only, you know, maybe they’re taking care of some, one component of a large product and there’s a bit of confusion, right?

Is it a product team? Well, they’re working on a product, but do they provide value directly to end customers? No, because they just, between quotes, own one technical component. Right? So the idea of streamlined teams is. You need to clearly identify what are the streams, and this can be within one larger product.

You identify different streams of value to customers, which might be different user journeys, or it might be around different user personas for the same product. Or it can be, you know, one team is focused on acquisition, another on retention, and you know, whatever. [00:08:00] Makes sense from a business perspective, but that is aligned to some continuous stream of, of value to some kind of customers, and we wanted to make sure that was clear.

And then once you have these stream aligned teams with. As much as possible end-to-end ownership. Ideally from we can actually generate ideas and maybe some experiments and things. We want to try to improve our stream for the end customers all the way to, we actually are able to build this, this experiments or features or what have you, and deploy them and have them being.

Available to the customers, and that’s where things get a bit difficult because obviously you’re talking about owning the whole lifecycle from product ideation to customer availability of what you’re doing, and that’s where the problem of cognitive load comes in, right? This is a lot of information [00:09:00] overload for a single team and the competencies that you would need in such a team, right?

If, let’s say they have. No help. If you would say to a team, now you are on your own doing all this, it’s going to be very difficult. And we know that as time goes on, technology tends to become more complicated and more things we need to know and and more practices and so on. So then we bring in the, what we could say are support type of teams, but they’re critical.

To allow the streamline teams to work effectively. And so you either typically need to increase the skills and competencies in the streamline team. And for that pattern we find is very helpful is to have an enabling team. So that’s another type of team where usually a small group of experts in some domain of knowledge are intentionally so the key, the key here is that they actually.

Are putting in, they have the availability to focus on [00:10:00] helping the streamlined teams learn the skills and, and bridge some gaps in their competencies. And they’re also in a good position to bring to the organization innovation, new ways of working, or maybe some new tooling and making the bridge between what.

The organization does and, and uses today and what is available outside in, in the industry. And then we have platforms which typically you, I mean, we could say you might start with a platform team as in one team that takes care of some, some kind of services that are consumed by the s streamlined teams in an, in a way that makes their life easier.

Because if we provide a platform, but actually this is just adding up more effort, setting up more need to understand how the platform works, or you need to manage work through tickets to get things done, then that’s not. A very helpful platform in the, in the sense of reducing the [00:11:00] load on streamlined teams.

But usually it ends up being not just one platform team. For most organizations, you end up with what should be a platform group, like a grouping of teams working in a platform. Ideally, those teams inside the platform are also aligned to some streams of value to internal customers. The in the stream aligned teams, right?

Mm-hmm. And then there’s was another type of team that we. Sort of reluctantly felt we had to include no discredit to the complicated of system teams, but we should use them sparsely when there’s really, sometimes we know there’s a component or a service or some part of a larger product that is very complicated because either the algorithm is very complicated or it could be.

In some occasions, the technology is very outdated and you only have a few experts who understand how to make changes to this technology. There are some exceptional situations [00:12:00] where it’s say, actually from a cognitive load perspective, we need a team that takes care of this component or subsystem so that we don’t sort of.

Impact the other streamlined teams with all the knowledge that would be required for them to be able to make changes to this component, right? Mm-hmm. But we need, we need to be careful not to overuse this pattern because it then becomes very similar to, or you risk getting into component teams and then you start having all these dependencies.

Because if we have many component teams, then to make a change. That the customer needs, I’m gonna have to start coordinating between component A team, component B, and all these kind of issues that I think a lot of us are familiar with, 

Alexis: unfortunately. Yeah. You spoke about cognitive load as a, as a key element.

Can you come back to that and maybe, uh, illustrate with an example? 

Manuel: Sure. So in terms of brief. [00:13:00] Kind of background initially, cognitive load theory from a field of psychology. But essentially what we did in Tim Topologies is if there is cognitive load limit. So there’s a limit to our working memory, right, as individuals, but as a team, we, it starts as a group of individuals.

It, it’s more than that. But if I have a group of individuals, there’s also a limit to their capacity as a group. So what’s interesting then is that the cognitive load might have different natures, and even though we cannot cleanly split and say, well, this. Part of my working memories is allocated to the actual business problems, and this other part of my memory is allocated to some kind of more tool related problems or something like that.

Because you know, we’re not a c plus plus program, so we don’t work like that. Everything is sort of mixed, but if you start to be able to determine, [00:14:00] well, actually, what are the things that the team is responsible or has to worry about that maybe they shouldn’t. Because it’s not really helping them deliver value to the customers better or, or more effectively are things that are more distractions, right?

So we start to be able to differentiate, not just say, well, the workload is, is too high, or the cognitive load is, is high on the teams. That’s very common. But then. What is the kind of work that, and, and knowledge and needs that the team should focus versus what they actually should be kind of isolated from?

And so I. That is the key idea, right? So when we talk about platforms, for example, it’s always from the point of view, how are we gonna reduce cognitive load on the streamline teams? Well, if we provide easy ways to, you know, the typical examples are, you know, provision infrastructure or easy ways to deploy their [00:15:00] changes to production with deployment pipelines or easy ways to diagnose problems in the live environment.

All these things that, yes, the teams. Will help the teams to use them, but they don’t necessarily need to know all the details of how those things and those services work underneath. Right. That’s where we start to be able to push down and outside the team certain knowledge and details that they really should not be the core focus.

Right. ’cause I’ve talked to teams that had, they started counting and they had like had to understand. Over a hundred different tools that they used in their lifecycle and frameworks and all this stuff. So that becomes really not very productive. Part of the work with its after the book was published in 2019 was to, let’s take a more deeper analysis of what team cognitive load really means.

And so we partnered with Dr. Laura [00:16:00] Vais, who’s PhD in organizational psychology, and she was able to. Do the research and, and find actually different academia research and, and, and papers and, and findings that helped us. She was able to define a model to assess cognitive load on teams. And so this model that we’ve developed and has now been, we built a product based on this model, which is called temperature.

So as in taking the temperature of a team temperature. Mm-hmm. And so. What she found is that even though we cannot measure directly the cognitive load, we can assess what are the main drivers, what are the things that are driving cognitive load up in the teams right there. So there are a number of different potential drivers.

So it could be things related to the characteristics of the work itself. Could be about the characteristics of the team itself. It can [00:17:00] be about the work environment and tools. It can be about which processes we follow. So it’s really interesting and we start to see more organizations adopting this way of looking at almost like an indicator for team health and team productivity.

If. You are just looking and saying, well, cognitive load is high because teams are very overloaded and stressed, but you don’t have a way to go deeper and say, well, it’s actually because they have too many stakeholders asking. Things and there’s no clear direction, or is it because they have, you know, poor tooling that makes it difficult to do their work and increases cognitive load?

Without that kind of insight, then we’re sort of guessing what can we do to help these teams, right? And mm-hmm. We might. Be lucky, and obviously we talk to the teams. We might realize, yes, maybe we need some new platform services or [00:18:00] something else, or some training or what have you, but we might also actually be looking at the symptoms and not the real causes of that high cognitive load.

And that means we are wasting in a way our our time because we’re not actually working on the highest drivers of cognitive load. We might be working on some things that are helpful, but are actually not the main problems that we should be looking into. 

Alexis: I. Okay. And so in your experience, we have four labels for teams.

The temptation could be to, to put labels on team and consider, oh, eh, that’s why you have a so beautiful design and I’m done. What kind of common missteps organization make regarding those team interactions, but ’cause it’s not only leveling them, it’s really working on the interactions between them. 

Manuel: Yeah, no, I think you’re, you’re spot on that that is one.

Big issue is that even many organizations or or people of who [00:19:00] read Team Topologies or they heard about this, you know, types of teams, they will sometimes think that, like you’re saying that, well, we just design a new target operating model, or however you want to call it, and we have this perfect.

Idealization of which teams should we have, which platforms and you know, and now it’s just a matter of implementing, executing, and everything will be fantastic. And that’s not how things really work, right? So one of the. I would say the battles that we, we are still fighting is for organizations to take a much more evolutionary approach to organizational change as well.

The good thing is there are some really great examples now that we start to see where some organizations, I’m, I’m thinking in particular a company called Yasir. I think it is not very known in in Europe or the us, but they, they are a big app in the [00:20:00] North African market. They call it a super app for doing multiple things like food delivery, ride hailing and other stuff, financial services.

What’s interesting is that, you know, they had this typical growth spurt of the organization and things were not working very well anymore. Like they like in when they were a startup. Essentially they realized, okay, we need to change the way we organize because there’s all the dependencies. Teams are not autonomous, et cetera.

And they looked into team topologies, but they realized it’s not that team topology tells you it’s, it’s not a, in my opinion, it’s not a model for you to follow by the book is. Giving you some building blocks to think about what kind of teams we might need, how are things going to evolve over time? The evolutionary part is key.

So what they did that I found interesting is they actually intentionally said, let’s, I. Take small [00:21:00] steps and do, they had like four month iterations essentially, where they would say, well, we, we made this change. Like we split up this team into two smaller teams, or we tried to make this team more stream aligned, or we introduced some kind of platform service, so they would make small changes, try it out for a couple months and then.

Reflect and see how did this help us or not? How did it work? And then use that for the next iteration. It’s really almost like if you’re, if you would be back to when you know Agile was introduced, it’s like start breaking down this huge pieces of work that we used to, to have that required this big planning upfront.

And then at the end when you are delivering, you realize there are a lot of things that were not. Based on assumptions that were not true and all this stuff. It’s essentially the same thing, but for organizational change. Start to [00:22:00] break it down to a level where you can make small changes and learn from them and not think that you can put on paper this ideal design and this.

Then it’s just a matter of execution. ’cause that always typically doesn’t end up well. 

Alexis: Yeah. You mentioned something just before. There’s probably something about the platform teams that probably many organization could feel that they already have some platform teams. But you, you mentioned something about the interaction with the platform team, and it seems it’s not some, some teams to which you submit tickets.

That’s what, so tell me more about how, how platform teams behave. 

Manuel: Yeah, sure. Just before I do that, I think that that raises also the point that the interactions between teams, whether it’s you know, platform or any other kind of teams, are also key to that evolutionary approach, right? [00:23:00] It’s not just defining types of teams or trying to map your existing teams to stream aligned or enabling platform.

It’s actually looking at. The evolution and are these teams interacting in a way that is helpful or not? Are is, are the interactions clear or not? So that was also the key aspect of team topology is to provide, again, some building blocks, some core interaction modes for teams to leverage. And it’s not about saying, oh, we only do this interaction.

It’s about are this. Three types of interactions helpful to frame your communication and working with other teams so that you have a clear idea of what are we trying to achieve? Why are you, why are we collaborating? Is there like a common problem that we need to solve together? Or is this more like actually one team depends on the other because the other team.

Own [00:24:00] some, some skills or some tooling. So we, we are actually depending on them, it’s not that we, it’s not a collaboration in the sense of solving some, some type of problem. So this framing of the, the interaction modes helps us work better with other teams, with, you know, with less waste and, and with more purpose.

So the three interaction modes are collaboration, like I just mentioned, two teams working. Together on some common problem facilitating, which is one team that has some knowledge or skills that is helping another team learn and upskill and gain knowledge. And then we have what we call X as a service, which is obviously based on the ideas of infrastructure as a service, this kind of approach where ideally for a platform that is your.

Your goal for you, the services you provide in the platform, is that they can be consumed independently, that you have a service that is mature enough and resilient and has the right [00:25:00] onboarding and documentation for teams to be able to self-serve, understand what service does, and use it and go on with their work.

So. For platform teams. That sort of is one of the main interactions, but another kind of anti pattern I see is that related to the previous question, is that when organizations are. Defining and say, well, we need this platform. We need this. This teams in the platform, they typically jump to, oh yes, this service is gonna be consumed in this as a service way.

But oftentimes that is you need to alternate between, yes, at some point that service might be stable enough and and easy to consume, but. You need to go through collaboration first to understand what do the streamlined teams really need from the platform? What is the right interface? What should we abstract versus what we shouldn’t?

AB abstract in the platform. All that should be coming from [00:26:00] collaboration with the streamlined teams and finally the platform team. And there’s interesting. Case from Adidas that they do this very intentionally, where the platform teams should also expect to do some facilitating work because they will be typically experts in some domain, right?

Whether that’s infrastructure or testing or you know, something that the platform provides some service, but there’s the whole knowledge of the domain of the skill. That maybe your streamlined teams don’t have, so they, they might not even be able to use the platform properly because they don’t know what’s a good practice and why should I use this service that the platform provides.

Right. So I think a more mature view that I’ve, I’ve seen in companies like Adidas is to have this expectation for the platform teams or, or the teams working the inside the platform. You are gonna need to alternate between these three interaction [00:27:00] modes. Sometimes you’re gonna have to collaborate when you’re trying to build something that helps the teams to reduce cognitive load.

Sometimes you’re gonna have to help them onboard and learn about the service and the domain. Other times it’s acts as a service, so you basically need to take care of the operations of that service and obviously fix incidents and provide a good kind of support to the teams using that service. 

Alexis: It’s interesting because the way some people describe themselves tells us something about how they envision those interaction mode.

I remember when the book was just out and a, a team of architects in the company, which was a bit surprising to me, but that’s how they were organized. Those architects owned very complex things. 

Manuel: Yeah. 

Alexis: That, that all the, all the other teams were supposed to use, and that was very complicated for the other teams to use that.

And they consider themselves as, oh, we own that [00:28:00] complicated subsystem because all the others are, are so dumb, they dunno how to use it. And then, uh, someone read the book and they say, oh, well you are an enabling team. I said, based on their behavior, it does not look like that. 

Manuel: For sure. Yes, that’s.

Alexis: In that box was not helping because their behavior was exactly the opposite of what was needed for the other teams. 

Manuel: That’s a really good point, and when we were writing the book that the purpose of these types of teams was also to elicit certain kinds of behaviors that would be expected for these types of teams.

Right? Like you’re saying, you know, if you are in an enabling team, the expectation is not that you are. Sort of hoarding some complicated services and, and you’re the only experts who know how to change it, then that’s definitely not helpful for fast flow. And also it’s not expected behavior from an an enabling team, which is there to [00:29:00] teach and mentor and help others grow rather than being the smartest in the room.

Which is interesting because effectively. Also common question after the book is, okay then if you need these different types of teams, then for example, in a startup, then you. What do you do? Because you cannot have, you don’t have enough people to have dedicated platform enabling teams. And that’s interesting to me in this sense because it’s, again, it’s more about the behaviors and the teams are almost like an implementation detail between quotes.

At some point it makes sense to have dedicated teams, but if you are in a 30 people startup, yes, probably you, you have most everyone works in. Kind of streamline teams. Everyone can do everything, but that doesn’t mean you cannot have some enabling and platform behaviors. Where maybe in this scenario, enabling essentially means, you know, having some mentoring from people who are more senior in the company, [00:30:00] helping the new people or new teams.

Maybe the platform pattern in a startup is actually just. A few people who dedicate, you know, a couple of hours per week to document how are we doing, how we’re using AWS, how are we setting up our deployment pipelines? You know, you don’t actually have real platform services, but maybe it’s just a wiki that helps other teams.

Okay. If I follow this sort of guidelines and guidance, it helps me get started to deploy a new service or something like that. So the pattern is there and the behaviors are there, and then the actual dedicated teams is, might come later when you grow and you scale up. Also, you shouldn’t just never create the teams, the dedicated teams.

It’s a matter of scale, but the behaviors can be there from the beginning. 

Alexis: I, I really like that because that can really also facilitate the onboarding of new people on the team [00:31:00] because it clarifies how it works and it leaves some spaces that you don’t necessarily need to learn everything from in that particular area.

You. That part, you need to learn everything there. So let’s focus on that first. That’s helpful. I, uh, I feel you probably work with a lot of leaders in organization that would like to get the benefits, let’s say, of a fast flow organization. All the things you were describing at the beginning, what are their roles in the implementation in the way you, you see that?

Evolutionary change. 

Manuel: So do you mean like for specific types of, of leadership, like CTO or, 

Alexis: yeah, for example. Yeah. 

Manuel: Yeah. I think going back to the idea of an evolutionary approach, I think that would be one of the main things, especially people in senior leadership, is sort of setting the tone that. We’re not doing this big reorg where people might [00:32:00] be afraid that, you know, their role is gonna change or the the team they work with is gonna change.

It’s actually telling them, look, there’s gonna be changes, but we’re gonna be doing this in an evolutionary approach. So we learn and we adjust when things are not right. It’s not just, you know, one step change and then good luck and hopefully things are are better. So that would be. A big one. And it doesn’t mean that you need to be directly involved in figuring out what changes are needed.

It’s more providing the support that, you know, let, let’s, let’s do this and, and learn and evolve. And it’s also providing the support that. People are gonna need, especially if you know it’s, there are changes in terms of their responsibility, the competencies that they need. If we’re talking about, for example, you have teams that are going to ideally become more stream aligned with more end-to-end ownership, then make sure that we are identifying what are the gaps that these [00:33:00] teams have.

Because if they’ve never done actual user research or if they never done testing or what have you, then they’re gonna need help. They, they. Need to feel that they’re going to be supported in that journey, that there’s gonna be training or there’s gonna be some enabling teams perhaps. So providing that level of support and for people to know that we’re not sort of alone, and that we’re just being asked to do different things and there’s no support.

So you probably need to factor that into your budgets as well to make sure that we, we can do that. And yeah, I think tho those two things. Making it. There’s nothing like set in stone. It’s about learning and taking steps towards improving the way we work and how we’re delivering value. And secondly, that, you know, people feel like there’s gonna be support in this journey.

It’s not suddenly we’re gonna be asked to do something different without [00:34:00] necessary learning. 

Alexis: Excellent. And so looking forward a little bit, are there emerging trends or new challenges you’re currently exploring around team and organization? 

Manuel: Yes. I mean, we continue to do more research on team cognitive load.

’cause what we have so far, the model we have. It’s scientific model and, and it’s systematic, but obviously it’s not, we can never say it’s complete. There are so many factors that can influence cognitive load on teams. We have a pretty good starting point with model and with temperature that allows teams to have a pretty good view on what is actually influencing their cognitive load.

But there are. New areas of research that we want to explore. Obviously today with artificial intelligence and all the benefits, but also drawbacks it can bring. Mm-hmm. That’s an area that’s, that’s very interesting that we want to research, like how does it impact [00:35:00] cognitive load on teams where it’s important to, if we can help set expectations.

Right. ’cause. You could say, well, in general, our physical intelligence is going to reduce cognitive load if it’s able to do certain tasks and certain work that the teams don’t have to do themselves anymore. But on the other hand, because it’s not deterministic and because sometimes the tools don’t have the context as necessary, and you always need the humans driving that work, it might be increasing cognitive load.

For the teams, right? If you know the way the the tools work is sometimes helpful, sometimes not so helpful. But this is something we want to research. And then the other thing that we start to see that we kind of expected from the time we wrote the book, but it’s nice to see. Happening in, in real life, let’s say, is, uh, applying the ideas from team topologies outside of it.

So that can be, [00:36:00] there’s an example from a, a company Norway called Capra Consulting, where they actually applied the ideas to the whole organization, so to sales, to leadership. They actually. Shut down their management group and, and try to push down this decision making as much as possible to the stream teams.

Mm-hmm. So that’s one example. And then there are even examples. I’ve been doing a little bit of guidance with NGO in Latin America, where they’re also looking at the patterns of Tim Topologies and they don’t build any. Software, right? These are initiatives to promote inclusion of socially disfavor people in kind of the digital world and the digital working market.

And so they realized like they have some bottlenecks in delivering their initiatives, their social initiatives, and they start looking at, okay, could this team become more of a platform team so that they are not a bottleneck so that other teams can [00:37:00] self-serve what this team is doing inside the organization?

So I find that really, really exciting and, and I think we’ll see more examples of applying the patterns. Way beyond engineering and technology. 

Alexis: You mentioned the team temperature assessment or way of looking at the health of the team in a way, yeah. Is it something that is already available today? 

Manuel: Yes. So if you go to temperature.com, essentially it’s a product, but you can also find details about the model behind it so that you can understand what is the research that was done, what’s, what are the drivers that we’re looking at?

And temperature is the implementation of that model, if you like, into, into a product that’s free to use for up to 25 teams. So yeah, I would love feedback if people want to try it out and, and see what they think about the, the results. 

Alexis: Excellent, excellent. Thank you [00:38:00] for having joined the podcast. That maybe the one thing I would like to ask you is, what is the question I should have asked you?

Manuel: That’s a, uh, difficult question. I think we covered a lot of ground, I think in this time, and the question about, I think there’s still more questions about kind of how do you do this transformation from whether you are kind of a project oriented organization. Obviously today there’s a lot of organizations trying to be a product oriented organization.

I think there’s even. In my opinion, another kind of step, which is a value stream oriented organization where the products are a means to provide value, but you actually have a higher level view where you understand the value streams. But this journey, you know, obviously takes time and it’s not always easy.

One part of, like I said, is to take an evolutionary approach and, and the other thing. Is that what I’ve seen in many, [00:39:00] many organizations, they haven’t invested in internal people who focus on flow, right? Regardless how much we talk about fast flow, yes, you have transformation programs, but people who are actually there.

Role is to look at flow and look at where are the bottlenecks, where are the frictions, where are interactions not well defined and therefore causing problems, which in my view could be a sort of enabling role, right? But from a flow perspective, how do we. Improve the flow in the organization where sometimes maybe we have to help teams understand ideas from team topologies, but maybe other times we have to help them learn about lean development and lean product portfolio or what have you.

Right? But having this intentional group or people in the organization whose role is to, to do that, that’s something that I. I think the return on, on [00:40:00] that kind of investment is, is really high because as soon as you start identifying bottlenecks and you start to see where the work is, is waiting because of dependencies, unnecessary approvals and, and this kind of things, when you start to remove and unlock that.

The value to the organization is can be really high. And so having some people focused on that, obviously you, ideally, the teams themselves have this awareness and they raise. Issues where we are blocked or you know, the way this platform service is provided is not really helpful. That would be healthy, in my opinion, if the organization is set up so that everyone feels they can raise issues around flow.

But you probably. Would benefit a lot from having a group of people who are focused on this. Some organizations like ING Bank, for example, they do have a ways of working group. I’m not sure that’s still the name that they use, but [00:41:00] people who are helping. The rest of organization, learn about flow, learn about better ways of working and and things like that.

So I see that as a kind of flow enabler approach as well. 

Alexis: Excellent. Thank you very much, Manuel. Thank you for having joined the podcast today. 

Manuel: Thank you.