Episode 211: The Power of Team Topologies with Matthew Skelton
In this episode of the Product Thinking Podcast, I am thrilled to welcome Matthew Skelton, co-author of "Team Topologies: Organizing Business and Technology Teams for Fast Flow." We delve into the intricate intersections between team topology principles and product management, exploring how these frameworks can transform the way product teams work together to enhance collaboration and reduce cognitive load.
If you're looking to refine your team's approach to delivering outstanding customer outcomes, this episode is a must-listen. Matthew Skelton joins me to discuss the revolutionary concepts within "Team Topologies," highlighting their impact on modern product management and operations. We uncover how organizing teams around flow and customer value can drastically improve product outcomes. Matthew shares practical examples of how these concepts are applied in various industries, providing invaluable insights for anyone involved in managing or organizing product teams.
Curious about how team topologies can optimize your product processes? Tune in to hear Matthew Skelton's expert insights and discover practical strategies to enhance your team's workflow. Don't miss this opportunity to learn from a leading voice in the field of organizational design for software delivery.
You’ll hear us talk about:
Product Managers in Regulated Spaces (28:30)
We discuss the debate over whether product managers should be domain experts versus having deep product knowledge. Matthew provides insights into how teams can effectively leverage subject-matter experts without them managing the entire product line.
Breaking Silos in Teams (14:21)
Matthew and I explore how organizations can overcome internal silos, emphasizing the importance of collaboration across product management, development, marketing, and sales for cohesive product delivery.
AI and Team Enablement (51:54)
We dive into how AI is transforming team topologies and enabling teams, discussing the shift in AI enablement platforms and their potential in redefining team roles and productivity.
Episode Resources:
Matthew Skelton's Website: https://matthewskelton.com
Conflux Website: https://confluxhq.com
Team Topologies Information: https://teamtopologies.com
Other Resources:
Follow/Subscribe Now:
Facebook | Instagram | Twitter | LinkedIn
Episode Transcript:
[00:00:00] Matthew Skelton: The challenge is, of course, that SAFE has turned into a big certificate factory. It's a certificate circus. It's all about like getting as many people certified as possible. And then once that stuff is in an organization, it's very difficult to pull it out because people have got a a natural incentive to, to stay certified and to, to keep fighting for that way of doing things. On that basis, I would say no, it's no longer something that I would recommend now.
[00:00:22] And so we've arrived now where we are today kind of bringing together your work, particularly product operations and team topologies, and they're coming together. They're very complimentary, I think, because they've got the same underlying principles. It's start with user needs or start with the value consumer, understand what the value is, set things up in your organization. So it makes it easy to deliver that value in the right way. And rinse and repeat.
[00:00:47] Like that's, that's how we do stuff effectively, which for you and me is. It's obvious, but turns out for lots of people, it's, it's a very different way of doing things.
Intro
---
[00:00:56] PreRoll: Creating great products isn't just about product managers and their day to day interactions with developers. It's about how an organization supports products as a whole. The systems, the processes, and cultures in place that help companies deliver value to their customers. With the help of some boundary pushing guests and inspiration from your most pressing product questions, we'll dive into this system from every angle and help you find your way.
[00:01:24] Think like a great product leader. This is the product thinking podcast. Here's your host, Melissa Perri.
[00:01:33] Melissa Perri: Hello, and welcome to another episode of the product thinking podcast. Today, I'm thrilled to be joined by Matthew Skellen, co author of Team Topologies, organizing business and technology teams for fast flow. Matthew is a respected thought leader in organizational design for software delivery and has helped countless organizations reshape how their teams work together.
[00:01:51] In this episode, we're diving deep into how team topology principles intersect with product management and product operations. We'll explore how these frameworks can help product teams collaborate more effectively, reduce cognitive load, and deliver better outcomes for their customers. But first, before we talk to Matthew, it's time for dear Melissa, this is a segment of a show where you can ask me any of your burning product management questions, go to dearMelissa.Com and let me know what they are for a future episode.
[00:02:19] Melissa: Today's episode is brought to you by Liveblocks, the platform that turns your product into a place that users want to be. With ready made collaborative features, you can supercharge your product with experiences that only top tier companies have been able to perfect. Until now. Think AI co pilots like Notion, multiplayer like Figma, comments and notifications like Linear, and even collaborative editing like Google Docs. And all of that with minimal configuration or maintenance required. Companies from all kinds of industries and stages count on Liveblocks to drive engagement and growth in their products. Join them today and give your users an experience that turns them into daily active users.
[00:02:56] Sign up for a free account today at liveblocks. io.
Dear Melissa
---
[00:03:00] Melissa Perri: Here's today's question. Dear Melissa, I work on the digital team of a big bank. So the product I work on is not really a product by itself. It depends a lot on the financial products the bank offers. I currently lead the onboarding accounts team in the wholesale B2B side of the business.
[00:03:16] I'm struggling a bit with setting the right North star metric for the product, because of this duality of financial product, the accounts and the digital product counterpart. Hope you can shed some light. I love these types of questions because it's true. It can get a little complicated when you start to think about things that are not purely SAS and that's okay, but we can get to good metrics on what to measure.
[00:03:38] And this is where product strategy comes into play. And when you think about product strategy. at an organization like a bank. It's not just about the digital products. It also has to intersect with your financial products as well. So that's okay. And it's going to be very intertwined. So what you need to do is start to understand your flywheel of how your company makes money.
[00:03:58] So as a company, what are the overall goals in your wholesale B2B side? So if we're talking about banking, usually it's about those financial products. making more accounts, having more transactions, creating more loans, anything like that. And then of course you probably collect fees on top of those. So you might have a goal with the onboarding and the accounts team to create more accounts fast.
[00:04:20] Your strategy has something to do with that. So how can my software help us get more customers in so we can increase the amount of accounts that we have and that can help us serve more customers. Which allows us to collect more fees or have them do more transactions. And then that makes our bank run, right?
[00:04:37] That's our flywheel that we're looking at. Now, of course, there's always a cost factor that you can look at as well about how software can streamline that. But you want to make sure that it's tied back to the value that your customers are going to receive and that your bank is going to receive, right?
[00:04:50] That's what we're really looking at here. So what I would look at for you. Is saying, how does our onboarding, whether it's through software or, you know, with people who are helping the onboard on the bank, how does that help our customers get into our product and start experiencing value faster? So you probably want to increase the number of accounts created and opened.
[00:05:11] Now you want to think about how do you remove friction from that? How do you make it easy? So when I look at a Northstar metric from the product side, if you're looking at the software, you probably want to reduce something like the time it takes create an account. Maybe you are not doing a self serve flow where somebody can just come in and open an account by themselves.
[00:05:29] Maybe that's something you want to look into, but maybe it's not. Maybe you have people transacting in the bank like they have to come in and talk to a person. So you might think about how do I make this experience so great that people can get started, open their accounts really easy and have it be seamless, creating that software for my banking person to help them on board.
[00:05:47] Or you might think about it as the person who or the business that's going to be opening that bank account. How do I make it easy for them to actually do that? So you really want to get into What does it take for somebody to open an account today? What are the frustrations? What are the pains and what are the habits that would allow them to do this more seamlessly and to have a better experience?
[00:06:06] And then you want to set your North Star metric off of that. So it could be about reducing time for certain tasks or being able to do that. It could be about anything that really looks at giving them that first great experience. So when we talk about North Star metrics too, a lot of people like to just default to one.
[00:06:24] I don't like that. I like to create a system of metrics because you don't want to just be having everybody come in to create an account and then having them churn, right? Let's say you get, you do something in your software and it makes it so easy for people to create an account, like hundreds of them.
[00:06:37] They get in there and then they go, Oh, this is not really what I wanted. So they churn. That's not good. So you're always going to want to have some kind of balanced metric. I call them mutually destructive pairs. So some kind of system of metrics. Where maybe it's a number of accounts opened, but on the other side it could be a retention metric.
[00:06:52] So anything that you're actually going after, you're not just trying to gamify it. That's what I would look at for that. So for you, I would study the flow of what your users are doing in onboarding, try to figure out where their frictions are, and then that becomes your initiatives and your product strategy to help reduce that.
[00:07:07] I would still say that your North Star metric is probably going to be something that is tied to that accounts, right? Number of accounts opened, number of satisfied customers, something like that. And that's okay. Now you're just thinking about how does software contribute to that? What are the places that I can play to help make that metric better?
[00:07:25] So I hope that helps. You want to look at product as those leading indicators that signify those business outcomes. So what can you do to show that customers are having a good experience, that customers are completing their desired actions, which will result in that business value of making more money, reducing costs over time.
[00:07:43] That's your job to figure out what part you control. I hope that helps. And if you have any more questions for me, please go to dear Melissa. com and let me know what they are. Now it's time to talk to Matthew.
[00:07:54] Hi, Matthew. Welcome to the show.
[00:07:56] Matthew Skelton: Thank you. Hi Melissa.
[00:07:58] Melissa Perri: So for those of you listening out there Matthew and I were at a conference together where he was presenting on team topologies, and I was talking about product operations, and we started to talk about the intersection of product management, product operating models, team topologies, all the work he's been doing, and today we're going to dive into what does that look like?
[00:08:17] And what have we been seeing as the emergence of product operating models? And how do we build great teams for flow? So Matthew, from your perspective, you've been out there working with a lot of companies That are moving from the project to a product operating model. What have you been observing and what kind of work are you doing with companies to get there?
Moving from Projects to Product
---
[00:08:35] Matthew Skelton: Good question. So first off, I should say, like, I'm a little bit starstruck to be here still. You know, the, the emoji with the stars in the eyes that one. So it's great to be here. Thank you. So it's now five, just over five years since the Team Topologies book was published, which means I was writing it with my co author Manuel Perez.
[00:08:49] I was writing it actually six years ago because it takes a, book publishing is very not agile. It's very waterfall. And so a lot of the head of inbound contact and, and things that people approach us for relates to Team Topologies, not all of it. But a lot of it is, is related to the material and the ideas of the Team Topologies book, which we'll cover in a bit. But just in the last sort of year and a half or so, we've really been trying to dive down a bit deeper, like and ask ourselves, What is it that people see kind of in the Team Topologies book? How does that connect to kind of business outcomes and so on and so on? And I mean, looking back, it's kind of obvious.
[00:09:28] Like one of the things that they see is that the language in the Team Topologies book is really suit the language and patterns on ideas and practices and so on a super suitable, very, very suitable for product operating models. It's not at all surprising, right? Because from the same publisher as Team Topologies we've got Project to Product by Mick Kirsten and you know, other books by people like Dominika de Grandis who's also kind of in this sort of space.
[00:09:53] And, you know, Sooner, Safer, Happier by John Smart and his, and his co authors and so on and so on. Like lots of, in fact, the whole, my background is I'm coming from a technology background, engineering and so on. So I started my career doing software for brain scanning machines. It was a long time ago. And then move more towards kind of web based systems and so on and so on. And more recently, you're thinking about the relationship between teams and the products and software we're building. So that's where I'm now helping organizations to, to navigate this whole space. And effectively, the language and patterns in Team Topologies is very suitable for like connecting through to this product operating model. People have heard about it now, thanks to your books and all your talks and things like this and the stuff from Mick Kirsten and a whole bunch of other people. And of course, the whole, on the kind of technology side, the whole DevOps movement since about 2009. So as cloud became available, infrastructure was no longer a bottleneck.
[00:10:52] You know, IT infrastructure is no longer a bottleneck, and therefore we could have better flow in IT delivery. And a lot of that movement, which is where I, I've been involved in that since then, my first talk at a DevOps conference was in 2010. So I've been at this for quite a long time, 15 years nearly. And really the, all the, the learnings from that movement are really all about, let's find out what the value is. Let's get the, let's get the, the changes out of the door as quickly as possible. Nice tight feedback loops understanding user needs, all of this stuff, which is the right way to do kind of. Software delivery and operations, turns out that's basically the right way to do product as well, or it's, it's very, very complimentary. And so we've arrived now where we are today kind of bringing together your work, particularly product operations and team topologies,
[00:11:46] and they're coming together. Because I think they're very complimentary, I think, because they've got the same underlying principles. It's start with user needs or start with the value consumer, understand what the value is, set things up in your organization. So it makes it easy to deliver that value in the right way. And rinse and repeat.
[00:12:03] Like that's, that's how we do stuff effectively, which for you and me is. It's obvious, but turns out for lots of people, it's, it's a very different way of doing things. And so they're latching onto like a product operating model as a, as a way to get out of a very slow, very cost inefficient
[00:12:22] way of doing
[00:12:25] Melissa Perri: the DevOps people were like the product people of the development world.
[00:12:29] I always ended up at DevOps conferences
[00:12:31] and I've known the community for a while. I worked with Kevin Baer for a little bit too. And.
[00:12:35] Just like the whole premise of it, like, how do we make
[00:12:39] the infrastructure that developers use and how we actually get things out the door
[00:12:44] better and faster and do that flow.
[00:12:46] It's always made sense.
[00:12:48] And I feel like it never got carried through all the way
[00:12:51] to the product side of the house. And when I was looking at product ops, to me, it was a no brainer. Like, Hey, development teams have this. There's sales ops teams too, that do the same exact thing for salespeople. Like. Why do we not have this for product management?
[00:13:04] Like what, what does that mean? And I think product management at the time too, when I was going to these DevOps conferences, I was going there because so many people were like, Oh, we don't need product management in general. Like it was just so kind of new to a lot of organizations going through transformations.
[00:13:21] They weren't thinking of it as a formal function. Like you have a development team that reports up to a CTO or this whole You know, organization, I feel like it's taken a long time for product management to get that, get there, but now we're there. And now that we're there, it's like we're maturing and we're standardizing and we're figuring out how to do this.
[00:13:39] So it's always made logical sense for me that we should be thinking about how we enable the way that we do our work too, but it doesn't just help product management. It helps, it helps everybody helps the developers. It helps the customers. It helps salespeople across the organization. And what I really love about team topologies and your book is it's You know, formal roles.
[00:13:59] And I see so many people get like siloed in these, these roles and these functions. Right. And especially in product management, like we silo ourselves off from marketing all the time from sales. There's super big friction between sales and marketing and product sometimes tech, and we're not all working together, especially if you're shipping a software product, like.
[00:14:21] You can't do that in isolation. Like I can't ship a product without developers and I can't market that product without marketing and sales has nothing to sell if we don't get that out the door, so I don't understand why the flow isn't there in so many organizations. And that to me has always been interesting.
[00:14:39] And in your team topologies book, you go into how we should be collaborating around that, which I think is really interesting.
Breaking Silos in Teams
---
[00:14:45] Matthew Skelton: Exactly. So the Team Topologies patterns came out of the work that Manuel and I and others were doing in this whole DevOps space. Originally the word DevOps meant how development and operations work better together when back in the days when you had a separate IT operations team and some organizations still do. But effectively we got to the point where, certainly in Team Topologies, where we're asking the question, what does it take to have no handoff in the flow of value? That's the starting point. So you've got a mixture, a mixture of skills and capabilities inside a team. And that team, so because of the nature of technology, it's very complicated because the nature of the domains we're working in, lots of regulation, lots of nuance, lots of trading you know, details about how to, how to, how to work in that particular domain, whatever. We need people to be able to have long term ongoing grasp of the domain that they're working in or the technology domain or the technology aspects and the business domain they're working in. We can't just be skipping from one thing to another effectively. It's those days are gone. And now we need to retain that kind of ongoing context for safety reasons and for, and for good decision making around the product and, and, and all sorts of things. So we've got a kind of long lived team. aligned to this thing that we're working on, but we don't want any handovers. So we can't build, we can't just do like one team does development and then passes it to like a team that does testing and then passes it to a team that deploys it or whatever back in the olden days. We asked that question, like what does it take to make that happen? And almost everything else kind of falls out, comes out of that initial question. Because having handoffs in the flow of value delivery is one of the things that makes it very slow. And so we take that as our starting point. We want it to be very quick. But how can we do that quickly, safely, sustainably, with good domain fidelity, and so on and so on, and without breaking the product. We're keeping the product coherent, and so on and so on. Now to my mind, that's really obvious. It turns out that this is not at all obvious to lots of other people, which I think is why I'm here. The Team Topologies book, I mean, it's sold, I think it's now 180, 000 copies which is, I'm told is, is a huge number. It's certainly one of the, the, the top selling books from IT Revolution, the publisher. They do a great job in curating their catalogue and, and promoting the book and things. But it's clearly, it's clearly found, it clearly resonates with people. There's something about it that resonates. And we, as you said, we deliberately didn't try to plug in lots of different roles. It's not a framework. It's a way of thinking. It's a way of approaching problems. A way of, a way of thinking through solutions. To the extent that people are using the Team Topologies these patterns are well outside of IT. They're using it for managing doctor's practices in the UK, managing GP practices. They're using it for dealing with changes to higher education curriculum, so university courses. They're using it for thinking through how to provide better legal
[00:17:35] services in law firms. So instead of being bounced from one kind of legal practice or a legal discipline to another, you get a, like a holistic experience and so on and so on, because it's fundamentally about knowledge work. So we, we do know some people are.
[00:17:48] using the team to produce ideas in, sales and marketing too. There's a case study. I think we've got a case study coming out soon in,
[00:17:54] this space. So to go back to your point about sales and marketing and product being separate, like, I think there's an opportunity here to over time to see what that looks like going forward. To ask that question, what would it take for us not to have handoff between sales, marketing, product, technology, and for it to be way
[00:18:09] more like coherent
[00:18:11] Melissa Perri: Yeah. Cause we are.
[00:18:13] Matthew Skelton: together.
[00:18:13] Melissa Perri: Model, product management, development, design.
[00:18:16] We never talk about the sales marketing piece,
[00:18:18] right? Like where they come from. And it's just like, Oh
[00:18:21] yeah, those people, it's like, Oh, those people who actually market and sell our things
[00:18:25] to make money, we should figure out how to put them in.
Mistakes in Product Models
---
[00:18:27] Melissa Perri: When you're looking at applying team topologies to a product operating model, what, what do you feel like people are getting wrong? These days, like, what are some anti patterns that you've been seeing that are tripping people up from that flow and. On the, you know, the other side of it, what have you seen work really? Well. Yeah,
[00:18:50] Matthew Skelton: so in general, like when, when organizations are moving towards, it's a good question. I guess there's, there's, there's a few things. One, the first one is that some organizations completely underestimate the, the effort and the time it's going to take to move towards a product operating model. They just think they'll rename the project managers into product managers, and then we're basically done and, you know, it's going to fail, right?
[00:19:15] It's absolutely going to fail because, I mean, this is a whole separate kind of episode, but really This, the mindset between project and product is just so completely different. It's not something you can just do with a rename. Project assumes once you've finished that little package of work, that there's no ongoing effect from the way in which you chose to do that work.
[00:19:37] Whereas obviously product, we're thinking about kind of a holistic, holistic user experience or a way of packaging value in a way, which is coherent and so on. So completely different and some organizations aren't willing to, haven't realized they need to invest in, in quite a substantial change of mindset and ways of working and ways of funding and all the rest of it. So that's the first thing is kind of really underestimating the, the big cultural shift that takes place. And it's worth investing, I would say for most organizations, because that focus on value and the focus on coherence is, brings so many of the benefits as well, in terms of what it's like to work in that kind of space and being able to move faster in the market and all sorts of things that, that I'm not going to teach you anything.
[00:20:19] Right. You know this stuff. For team topologies, we've had some people read the first part of the book, like the first few chapters and then go. Oh, I get this. This is easy. Put the book down and then they miss, they don't read chapter six, seven, and eight in the conclusion, which is where the, the really important stuff
[00:20:39] is. It turns out that lots of business books are basically repeated. They're like two chapters at the beginning and then they, the rest of the rest of the book is just filler and it just repeated. So then that's what a lot of business leaders just do. They just read the first few chapters. I notice your book is not like that, which is good. So we've had, we've had people basically misunderstand what's going on there. They think it's, I think it's way too simple. They just fixate on the
[00:20:59] types of team and maybe a couple of other things and don't get the, the more important concepts out of it
[00:21:09] Which is, which is unfortunate. So we're, we're
[00:21:12] doing some work to try and like to counter that,
[00:21:15] Melissa Perri: what are the
[00:21:15] types of things that they're skipping there? They're probably like, oh, in the book for the people who don't know,
[00:21:21] Matthew lays out, like, these 4. Fundamental topologies where you got stream aligned teams, which are what we would call our product team. So for example, if you were at a bank and you have a product team around the credit card business, you know, at a giant bank,
[00:21:35] that's domain focused, stream aligned, you're delivering the value of the credit card to that customer.
[00:21:39] And then you have enabling teams that support those streamline teams to be able to do their work effectively.
[00:21:44] You've got complicated subsystem teams, which I think is interesting, especially for complex organizations. And that's more about domain knowledge.
[00:21:52] And deep,
[00:21:53] Like analysis, right?
[00:21:56] Matthew Skelton: And then the fourth one is, is a platform. So the types of team and the reasoning behind creating different types of team is, is, is important. And that's something that like doesn't appear until later in the book. So we start with the premise that like, what would it take just to have stream aligned teams?
[00:22:12] So teams are aligned to the stream of value. That's why it's called stream aligned. We decided not to use the word product because we'd been doing some work with cyber physical some cyber physical customers. So like, doing, working on hardware and firmware and software. And to those companies at the time,
[00:22:28] the product was the physical thing.
[00:22:30] Melissa Perri: I think that's the best
[00:22:31] decision you made though, too, because even in, like, banks, I get into the arguments
[00:22:35] about what's the product. They're like, it's the actual loan, right? Rather than.
[00:22:39] The whole system that actually,
[00:22:41] you know, figures out how much money you can get from the loan, the algorithms behind that,
[00:22:45] the way the loan is processed, how you actually get distributed the money, the way you pay it all of all of those things.
[00:22:50] So
[00:22:51] I feel like.
[00:22:52] The way that you called it.
[00:22:54] Takes away all of that nuance.
[00:22:56] Matthew Skelton: And I mean, this is a bit of a, this is a bit of an aside, but like, Yeah, we're actually working with, with one organization right now in the, in the in the financial space and they've, they've gone all in on product operating model and like every single thing is a product. And we're like, no,
[00:23:09] Melissa Perri: you're like,
[00:23:09] not everything is a product.
[00:23:10] Matthew Skelton: don't do that.
[00:23:11] Melissa Perri: Yeah.
[00:23:12] Matthew Skelton: Please don't do it. Clearly like there's massive value from, from using product thinking And product management approaches. Across the whole organization, like a whole organization, like really low level stuff, like who instead of building a, piece of technology, who is the value consumer for a stream of value around this thing here?
[00:23:29] Brilliant. Use, like, so, so use product techniques across the whole organization, but don't necessarily obsess that everything
[00:23:34] has to be a product with an external consumer that is just not realistic.
[00:23:37] Melissa Perri: The reasons why they do that too.
[00:23:39] I don't know if you've observed this, but this is what I've seen because I've run into that over and over again
[00:23:43] is for,
[00:23:44] because they're not used to the whole concept of product operating model and product managers and what product managers do, they think that in order to have a product manager, they have to be managing a full product.
[00:23:54] And they don't understand the nuance between you can have lower level product managers building features to contribute to a much larger product, or you could have a platform product manager who are working on
[00:24:04] enabling APIs that go back into it. So they try to make everything a product.
[00:24:09] And then they're like, okay, great.
[00:24:10] So now I can be the product manager for this product instead of being like, no, product managers are people who do this type of work around a value stream. Value streams can have multiple products or features or services associated with it. At the very top, you need the product thinking to think through the whole value stream and bring it end to end and help bring those products and features and services together.
[00:24:30] But it doesn't mean that, you know, every little thing in here is actually going to be a product.
[00:24:36] Matthew Skelton: Exactly. And we've got, we've got that as a concept in Team Topologies. In the book, we call it. We've got the concept of a platform. I actually really did dislike that word now. I wish we hadn't used it because lots of people just see a platform as a piece of technology. For us, what we call a platform in the Team Topologies book is anything which improves flow and reduces cognitive load or cognitive burden in the teams that are using that thing. And the smallest or the thinnest viable platform, as we call it in the book, could be like a wiki page. So imagine you've created a wiki page and said, Hey folks, here's a great way to use this particular technology. configure it like this, use that interface or that API or this something else. And if you do, if you use this thing in this way, it's going to solve like 90 percent of your problems in this space.
[00:25:21] We've done the research on it. We've worked out. This is a nice combination. We've curated the experience for the people who can use it. We haven't had to build anything ourselves because all of these services are like in the cloud somewhere or from another SaaS provider or whatever. And then The Stream Aligned teams, you know, we're focused on a particular product area. Look at the wiki page and go, wow, This is amazing. Bang, bang, bang, straight there. It's improving flow and those teams using it and it's reducing their cognitive load. And that's, in our terminology, that acts as a platform. That wiki page is acting like a platform. A lot of the technology is kind of outside, but we've got that kind of experience around it.
[00:25:59] And that speaks to kind of a product approach really, because like a curated experience is a kind of like a product, right? It's, it's a, it's, it's very similar. It's in that similar space. Cause to curate that, to curate, curate that wiki page, we have to understand the needs of the teams that are using it and trying to build things in that way.
[00:26:17] So we're. Reaching out to them and we're treating them as our customers or users and doing, you know, understanding their experience and, and asking them what they need and all the kind of stuff we'd expect to do if it's an actual product. But yeah, all the, the, the, the 14 types that, that we talked about in the book, they're all predicated on the, the, the, we, we start with a streamlined team, like what would it take just to have streamlined teams in the organization?
[00:26:42] So just focused on no handoffs, a mixture of skills, end to end value flow. And, and you know, that's, if you like an ideal state, so we don't have any we can manage all, all the, all the infrastructure or all of the data ourselves and we're, we're fully independent and we've got effectively like an ecosystem of separately viable products that we're offering and they can come together and work together nicely.
[00:27:10] And so on and so on. In reality, of course, The cognitive load is too high. Like we're taking on more and more of the security concerns or the regulatory concerns or the data concerns or the infrastructure concerns and our cognitive load is getting higher and higher. And so that's slowing us down. So at some point we want to take some of that stuff, which is not really domain centric, it's not really product.
[00:27:34] It's not really related to the product itself. the value consumer value. And we want to take some of those, some of that gubbins effectively and move it somewhere else. So it might be dealing with infrastructure or dealing with
[00:27:44] data or dealing with security or whatever. And that's where the other three types of team come in.
[00:27:49] So like a platform or
[00:27:50] platform grouping will take some of that stuff and provide it back to us as a service. Complicated subsystem is where you need people with like a really specialist expertise, like they might have needed, they might need like a PhD in mathematics, or they might need to know something about like a particular kind of regulatory reporting.
[00:28:10] It's like really detailed awareness complicated algorithm or something like that. And if, if, if that algorithm were left inside multiple stream alliance teams,
[00:28:20] or product teams, the cognitive load would be too
[00:28:22] high.
[00:28:23] Like, are we really going to hire multiple people with maths PhDs to do that work
[00:28:27] inside the product team?
[00:28:28] No, that just doesn't make any sense.
[00:28:30] Melissa Perri: This is
[00:28:30] Matthew Skelton: So we're,
Product Managers in Regulated Spaces
---
[00:28:30] Melissa Perri: like what you were saying here too, I think it's really interesting because this is a huge debate we get into,
[00:28:37] In product management about whether product managers need to be domain experts or from, and I'll, I'll give you an example of it in a second versus know product really well.
[00:28:46] And while I always say there, there are thresholds to that domain knowledge, like, you want somebody to know what types of products you're working on and you want them to be able to learn the domain.
[00:28:56] I see a lot of organizations in highly specialized areas, finance, healthcare, for example,
[00:29:01] insurance,
[00:29:02] where they will bring people in who have like deep insurance backgrounds and no product management background.
[00:29:08] And then they'll run the whole product line because they say, well, they're the ones who know the inner workings of insurance. So they have to build the product. And what I've done is, is pulled a lot of those Subject matter expertise out when they don't know product and put them into those complicated subsystem teams, like, you're talking about so that they can advise on the.
[00:29:29] Those pieces of, you know, let's say, like, health care, like, what a nurse would need to be able to prescribe or what you would be able to show an electronic health record system for, let's say, the medicine you're dosing or, like, be able to surface those insights, but they're not necessarily. Around the entire interface design of a product, or the flow, or the workflow is going to be following.
[00:29:49] Matthew Skelton: exactly. We're thinking about knowledge. We're thinking about awareness. We're thinking about cognitive load. We're thinking about, yeah, knowledge work effectively and where capability should sit. the other type of team that we talk about in Team Topologies is called an enabling team. And this is often where the expertise would sit. In a complicated subsystem, those experts will be building something like building a, a particular like like an, an engine for reporting or an engine for calculation or something for the using experts, their expertise inside that quite. specific sort of bit of the product, if you like. But there's another way to use expertise, which is What we call an enabling team. The enabling team doesn't, does not build anything. They're there to uplift the skills and capabilities inside a streamlined team. So let's say they're, they've got some expertise in compliance or in, in yeah, regulatory reporting or whatever. And they're working with a stream aligned team for, let's say a few days or maybe a week or something to help that Stream-aligned team understand how they need to build things in The aim is always to leave that Stream-aligned team independent and not dependent on the experts all the time. So we're going to upskill them, we're going to teach them about this thing, help them understand it better, work with them so they've got a good understanding or better understanding, and then detach if you like, like leave them so that they can be independent again. Or maybe that team detects that we really need some upskilling and need some training.
[00:31:12] Okay, cool. Or we really need to actually. Have a company wide policy of hiring people with increased awareness of a particular. thing, like financial regulation or something. We actually need more people with that kind of expertise. Okay. Let's go and hire some more people. They could also detect the fact that like 17 after 20 teams have all got the same kind of problem relating to regulatory reporting, something, something. Okay. Well, we probably need to have a service like an API that all of those 17 or 20 teams can actually call to do this thing because they're all struggling in the same way, then it makes sense to build something in a platform and provide it as a service. So we've got that kind of detection. We've got that, we're, we're looking for these problems that are, that are recurring, but then for which we can have a useful solution from a kind of central API or something like that. There's a really good way,
[00:32:03] of thinking about things in these terms. This example of how the Teams Topologies language and patterns helps us think through like where we place capability in a dynamic sense. It's not just about like an org chart. It's about how we respond to. Changing technology regulations business challenges, whatever, how we respond to that on an
[00:32:22] ongoing basis.
[00:32:24] Melissa Perri: What I like about that too, and maybe we can talk a little bit about how you see this with product operations is.
[00:32:30] You know, you're, you're talking about how things that help at scale, right? If I'm on a new billing team, I'm going to go help these places in isolation. These other teams in isolation, help them out a little bit, but
[00:32:42] I get to see the patterns.
[00:32:44] And now I get to scale the knowledge once I observe those patterns and see those problems over time.
[00:32:49] And if we think about.
[00:32:51] Those teams just being embedded in one team, right? Those people being embedded in one team or never
[00:32:56] coming to other teams. We don't get to see the patterns and the problems over time.
[00:33:00] And to me, like,
[00:33:01] that's a big critical part of product operations is like, you are looking at all the teams in product management and saying, what do they need? Can I build a platform for this? Can I, you know, enable them in some way? Can I fix this with the process? It doesn't necessarily have to be a product, but it has to be.
[00:33:18] You know, from a, from a tool perspective, but you're looking across all of these different teams and saying, what can I do to make this faster and to help our flow of work? And to me, that's always made sense. So I'm curious, like what your take was when you saw product operations and how you saw it fitting into team topologies with product management?
[00:33:36] Matthew Skelton: Right. So I've run outta stickies, what do you call these little market tabs. I've run out of them because I was marking so many pages. Right? And so when I listened to the podcast on, on Lenny's podcast with you and Denise, I was like, wow, this is amazing. And I listened to it twice. I listened to it on the, on the flight out to Germany, on the way back again.
[00:33:53] 'cause I, I had to, I had to re-listen to it. I was like, this is amazing. This is just like, there's so much alignment in terms of the, the, the intent. Behind, like, the material in the two books, the intent is, you know, rapid, safe, ongoing flow of value by thinking through, like, where we're putting that cognitive burden or where we're putting the particular, like, domain context and so on and so on, like, who should be doing what, if you like, like, how can we change who does what in order to allow
[00:34:19] people to focus and so on. So yeah, I mean, when I was reading these patterns, like yeah, that totally makes sense. Like it, it is seeing, it's seeing it, it is talking about how we do work. It's talking about it with slightly different language, but very similar to be honest, but slightly different perspective. And Team Topologies is coming from a slightly different perspective, but effectively it is got the same underlying principles.
[00:34:41] I think we, we, there, there's, there's a lot of. I'm not saying it's exactly the same because like the context is, is, is a bit different, but the, I think the underlying principles are
[00:34:50] very, you know, highly aligned.
[00:34:52] You come from a product perspective and I've come from a kind of technology ish perspective, but really we're trying to solve, I think, pretty much solve the same problem, but it's not, it's very close. Yeah, so I loved it. I've, I've, I've got loads of quotations, which I plan to to extract from here and put on social media at some point. And make the
[00:35:14] connection basically to to the stuff that's in, that's in Team Topologies. I don't think it's, I
[00:35:18] don't think it's all obvious.
[00:35:20] Like,
[00:35:21] Melissa Perri: guess not because I still get.
[00:35:23] Push back from it so I had somebody post on LinkedIn the other day. When is everybody going to realize that product operations is the biggest grift out there.
[00:35:32] I'm
[00:35:33] Matthew Skelton: What? It's madness. It's just madness.
[00:35:37] Melissa Perri: too, but I, like, I get I get this stuff all the time. And I,
[00:35:41] it's so hard for me
[00:35:43] to, one,
[00:35:44] I can tune out
[00:35:45] naysayers, but I also want to listen to feedback.
[00:35:47] Right. And I think my views on
[00:35:49] product operations, they evolve and I think we're going to get into it in a little bit about how AI has
[00:35:54] replaced some of my thoughts previously. But
[00:35:57] as a concept, I feel like, you know, I've worked with
[00:36:01] dozens, almost like probably hundreds of organizations at this point and seeing these patterns over and over and over again, when it comes to product management at scale.
Product Ops at Scale
---
[00:36:08] Melissa Perri: And I feel like the biggest naysayers of Of product operations always comes back to they haven't really done this stuff at scale,
[00:36:15] right? Like they've never actually tried like, what, you know, we were talking about this a little bit before we jumped on. But like, what if you're the chief product officer of a bank?
[00:36:23] Like, I know many CPOs at banks and I work with them and they have 500 product managers reporting up through them. Like, A lot of the pushback I get is, oh, you know, some of this work, it's almost always around the governance and the processes pieces, but, like, I go, oh, you know, that should be the, the chief product officer's job or the VPs job to go and make sure that people know how to write this strategy correctly.
[00:36:49] And I'm like, okay, like, when I was at Athena Health, I, you know, Worked with the chief product officer, but I did not expect him to go train our 365 product managers on how to write an Epic in the right format. That was going to allow us to roll that up into a strategy that he could interpret and then be able to look at what's our progress towards our business outcomes.
[00:37:12] Right. That was my job. I was
[00:37:14] Matthew Skelton: madness.
[00:37:15] Melissa Perri: the product operations person. Like I came in as a consultant, but I became the product operations person. And I said, okay, I'll build the templates. I'll make sure everybody understands this, but I'm going to go around and figure out what's, you know, what's breaking our flow here and help with that transformation.
[00:37:28] And I feel like a lot of the work that I've been doing along the way and transformations, when I leave as a consultant, if you don't have somebody. there to take over this, this falls apart, right? Like it's, it's not a swoop in, teach a lot of people stuff. So that's why I transit, like that was the first place I stood up product operations and it was like, okay, this is your job now to take this over.
[00:37:53] Cause my work's not done yet. Like. I came in for a year and a half. We made huge progress, but they still have a long way to go, right? They still have platforms and tools and functions to do it. And now, you know, Tim is their head of product operations and he's still going. He's still building out amazing things there, but there's so much pushback.
[00:38:11] I think from people who haven't seen this work effectively, especially around those enabling pieces, when it comes down to like process and. Tools or anything like that. Even if you talk about roadmaps and I'm like, roadmaps are like one of the most important things a company could have for visibility.
[00:38:28] And if you do that wrong, you don't get any visibility at scale. Like, I can't just turn to 500 people, ask them what they're doing.
[00:38:34] Matthew Skelton: It's almost
[00:38:35] as if some people think that things should
[00:38:37] be hard for people. Rather than easy. Like I think in the team's budget, we talk about we quote someone called Evan Botcher who, who talks about like how to how to define digital platform and I think I'm paraphrasing now, but, but in Evan Botcher's article, he, he says something like. Your platform should make a platform
[00:38:57] should make the right thing to do easy, something like this, like, like, why wouldn't you, so you've got, you've got an idea of like the right way to do something, or at least an effective, a really effective way of doing something in this context, in, in this industry, in, in this, with this technology,
[00:39:11] whatever, like, why wouldn't you want to make that as easy as possible for people to do, do it that way? So that, and then that's why you put in a platform, for example, you might call it a platform, you might just call it a set of services, whatever, that, that makes it easy for other teams or, or, or product managers or whoever do things in an effective way in the way that you want to do it. You're encoding that kind of way of working inside those, inside those APIs or inside the services to me,
[00:39:34] I'm sure to you, like. Why would you want to
[00:39:36] do that?
[00:39:37] But like to some people, it seems, it seems that they're almost offended that, that some people like teams would then find it really easy to do things better. It's like, well, we're trying to make the organization more effective and to serve the user needs better. like,
[00:39:49] why wouldn't you want to do that?
[00:39:52] Melissa Perri: don't get why
[00:39:54] the other pushback I get is like, it's a rite of passage for product managers to, to go like, learn MongoDB and try to pull stuff out of a database.
[00:40:02] Why,
[00:40:03] like, what's like,
[00:40:05] why, why, like, that's not their job.
[00:40:07] Their job is to interpret the data,
[00:40:10] be able to analyze the data and do that.
[00:40:12] But
[00:40:12] why do we have to let them recreate these processes and, and tools and everything off the side of their desk? It's like super inefficient. And most people just want to get their job done. Like they just want to
[00:40:23] build great products and whatever's standing in the way of that,
[00:40:26] why wouldn't we want to
[00:40:28] make that easier?
[00:40:30] Matthew Skelton: Yeah.
[00:40:30] Yep. And again, I think that's the
[00:40:32] mindset, like we're expecting to, we're thinking through. How can we make, how can we simplify things? How can we make people's jobs easier so that they can focus on what the value is? Like, like, let's understand what the value that we can provide in this organization and clearly loads of organizations, it's more about HIPPO.
[00:40:50] It's more about the highest paid person's opinion. And it's more about kind of the hierarchy and a bunch of things like that, rather than actually providing value. And that's ultimately what this project to product transition is sort of about really is. Getting organizations to, to really, it's like they're on the psychologist's couch, like, tell me about yourself. What value do you provide?
[00:41:13] And it's actually quite awkward for some organizations. They're not set up to do it because they're not set up to be like honest about the actual value that they're giving to the customers and that kind of thing.
[00:41:21] So then that's where some of the awkwardness arises in, in, in this kind of space, really, and actually that's one of the things that team topologies kind of exposes really is any lack of clarity about mission and purpose. Because we're having to, you know, we're saying align teams to. The flow value. Well, what's the value?
[00:41:37] We don't really know what the value is. We haven't worked in those terms, and It's really interesting to see that realization that people go, Ooh, Yeah, we really do. We really don't. So we really don't think about the value to the users. Therefore, how can we align teams to a flow value? Like it's, it's these kinds of approaches. I don't know where you've seen this as well, but these kinds of approaches are like a lens or like a, like a prism that then refracts the light. And you, you see that the organization kind of has got some very. different opinions about how
[00:42:11] to do work, let's say.
[00:42:12] Melissa Perri: Yeah, I
[00:42:13] Matthew Skelton: exposes, like different mindsets or something
[00:42:16] Melissa Perri: I find to a lot of the naysayers on product ops are probably not doing real product management, right? Like, maybe they're doing
[00:42:23] some of the,
[00:42:24] some of the grunt work around. They're like, trying to show boat as if they're really busy, but they're not really doing the value delivery pieces of it.
[00:42:30] And I have seen that in a couple of organizations as well.
SAFE and Big Batch Planning
---
[00:42:33] Melissa Perri: So. One thing, though, I do think the pushback on the process and the governance piece though, is due to a lot of the agile process and, you know, safe and all of that stuff. Like, I feel like everybody thinks process is a bad word now, right?
[00:42:49] Anything that has to do with process, like that word, we can't talk about process. What have you been observing out there
[00:42:55] with safe and especially with, with Teams Topologies and, and how are you helping people like break out of the safe mentality there?
[00:43:04] Matthew Skelton: Great question. So the
[00:43:06] scaled Agile framework decided to include some of the
[00:43:09] terminology from team topologies in, I
[00:43:11] can't remember which
[00:43:12] Melissa Perri: They do
[00:43:12] Matthew Skelton: or something a few
[00:43:13] years ago.
[00:43:14] Melissa Perri: it's so funny. They're just like,
[00:43:16] I'm just going to grab this thing and shove it on the map.
[00:43:19] Matthew Skelton: it's, it's, so I came up with a way with With a with an analogy for this. So, you know, if you think about blueberry muffin, it's being carefully put together. The blueberries in the middle have been baked. It's like when you bite into it, it's like, Oh, it's really nice.
[00:43:37] But you can take a raw muffin and push
[00:43:38] some blueberries in.
[00:43:39] It doesn't make it a blueberry muffin,
[00:43:41] right?
[00:43:41] And that it feels like that's what, some of these approaches where they're just kind of cannibalizing or bringing in lots of different approaches and there isn't really a high degree of coherence around it, it feels a little bit like that, but but, and like there's, there's a side effect of that is actually that we, thanks, thanks to Scaled Agile Frameworks, thanks to SAFE, we actually get a number of sales leads because they've discovered Team Topologies through that, and then
[00:44:05] we, and then we get a call.
[00:44:07] So like a one
[00:44:08] level,
[00:44:08] Melissa Perri: that's good.
[00:44:09] Matthew Skelton: okay, kind of handy. But, but. But stepping, stepping back a bit two things. Safe, I think has got an interesting place or something like safe where you're doing big batch coordination and testing and releasing and so on. Has a place for products that are disconnected from the internet for large periods of time. Satellites, submarines, power stations, hopefully. Things that need to be perhaps cars, even vehicles, like autonomous boats and things like that.
[00:44:41] Like these things are literally disconnected and need to run disconnected for substantial periods of time because there's no, there's no signal. So you kind of want to test those things in isolation in big batch, because that's how they're going to operate. Fighter, fighter planes, for example, stuff like this.
[00:44:56] Like you don't want them to be. internet connected. You deliberately want to disconnect them. So I think there's a place for approaches that are very big batch like that. But, you know, that place is really not like, you know, big business systems, banks and stuff like this, because you want to be able to change, you need to need to change those systems on a much more fine grained basis. So there's that side of it, which is like the whole approach is suitable for certain things, but very unsuitable for, for internet connected business systems. At the same time, I think the scaled agile approach seems to seem to act like a kind of a walking frame or a crutch for organizations that are coming from a very waterfall place and trying to be more nimble. And it's like an intermediate step, like, like someone who, like, let's say they've, they've they, they, they couldn't walk. And so they've been going through physiotherapy. And so using like a walking frame to do that. Well, okay. Use a walking frame for a bit. And if that helps, that's cool. Yeah. But how, how do you get beyond that?
[00:45:56] So we're, we're talking, we're talking to an organization in Europe at the moment. And we've, we've worked with a few in the past where they, they had used Safe for a bit. And now they've got to a point actually where that they don't need the crutch anymore. They don't need the walking frame. So they want to get out of it. And so helping them to kind of shift away from that. big batch approach into something way more nimble. Clearly it needs the architecture to change. It needs ways of working to change. A whole load of stuff. But we do see that. And
[00:46:23] it's a long journey to be honest. Like someone who's gone through physiotherapy, it takes a long time to get to the point where you can run. So initially it's just walking without the walking frame and then it's maybe jogging or walking faster. And then finally you can actually run and go to a marathon and do that every day. Then you get, then you're at the point where you're deploying. multiple times a day across multiple different products independently. And that's kind of the, I mean, that's been, that's been the state of the art in some organizations for like more than 10 years. Right. But that's kind of where organizations find value to be able to do that, that kind of nimble
[00:46:59] approaches to product,
[00:47:00] but it takes a while.
[00:47:02] Melissa Perri: Yeah. And when you're looking at safe,
[00:47:06] You know, I was talking to Lenny about this on his podcast too. And a lot of people were asking, you know, would you start at safe? Do you think there's an approach
[00:47:15] that's
[00:47:16] better to start at?
[00:47:18] Instead of safe when people were trying to achieve that delivery type, especially just get things out the door delivery type mindset.
[00:47:26] Matthew Skelton: So I've been talking quite a
[00:47:27] bit to M Campbell Pretty who's one of the, one of
[00:47:31] the leading experts in SAFE and has been for ages based in she's in Australia. So we're working together on, on, on some ideas and some, some comparison and so on and so on, and I'm hoping to do some more in 2025. I, I, in theory, I think SAFE is a, is a reasonable place. If,
[00:47:49] if, if the organization is, has the equivalent of a, like a, is in physiotherapy. If they can't walk by themselves, then using SAFE as a walking frame or a crutch might be okay. The challenge is, of course, that SAFE has turned
[00:48:00] into a big certificate factory.
[00:48:03] It's a certificate circus. It's
[00:48:04] all about like
[00:48:05] getting as many people certified as
[00:48:06] possible. And
[00:48:07] then once that stuff is in an organization, it's very difficult to pull it out because people have got a a natural incentive to, to stay certified and to, to keep fighting for that way of doing things. So it's On that basis, I would say no, it's no longer something that I would recommend now, not because of the technique itself necessary, but because of the,
[00:48:25] the whole industry around it.
[00:48:27] Melissa Perri: Yeah.
[00:48:27] Matthew Skelton: But it does seem to help some organizations. And yeah, certainly, like I said, for the context where systems are not internet connected, then. It does seem to be a useful
[00:48:40] approach. Hey,
[00:48:44] Melissa Perri: always. I talked about this a little bit on Lenny's podcast, but
[00:48:47] I've seen people, I feel like their big room planning sessions
[00:48:51] inspired the right
[00:48:53] type of mindset of let's all get together and like hash this out. And I, I've seen people
[00:48:58] really benefit from adopting that.
[00:49:00] And organizations come a long way from that,
[00:49:03] but then it turns into the big batch part that you're talking about.
[00:49:05] Right? Where they interpret it. I don't know if safe says this, or they interpret it, but I've never seen an organization interpreted differently. So let me put it that way as well. Where once you plan that quarter, there is no changing, right? And there's no room for discovery and nobody knows when to do discovery and how to feed discovery in.
[00:49:23] And they're kind of like sprinting back to back. And like I said, I don't know if that's a safe thing or a way that people are implementing it, but I've never seen anybody implement it differently in the, like, dozens of organizations I've worked with that did safe. So it gets into that flow problem, right?
[00:49:36] Where now you're bottlenecked. By this planning session, and if you have new information coming into you, which hopefully product ops can enable, because you can look at it in real time and start to understand what's going on. You can't change it. You're like locked in. Or that's what people expect and then from the portfolio side, it's kind of spin up all these kind of like portfolio manager type people in some of these safe organizations that don't have like a good product history.
[00:50:01] When that role is typically like a head of product who would oversee like many products in that area. But they treat it as like a different thing than a product manager. Like it's not product. It's like, those are the portfolio people over there. And they look at the portfolio, but you need that product mindset in order to manage portfolio and understand the value and like connect it that way.
[00:50:21] So now we're spinning up like different roles and different teams. Everywhere. And it's like, no, that's the portfolio team. And they're like, this is the product team. And never the two shall talk and meet and actually like do strategy together.
[00:50:33] Melissa Perri: The issues in safe is like, it spins up so many different teams and nobody's bringing them back to kind of what you talk about in the team topologies is like these teams that are aligned to value and going straight through.
[00:50:46] So I see always a break in how we determine what's valuable and then get that out
[00:50:51] the door.
[00:50:52] Yeah.
[00:50:53] Matthew Skelton: Yeah.
[00:50:53] And it's, it's got the assumption that things need to be very big and chunky rather than like, what would it take not to need to have that kind of coordination
[00:51:03] and to allow the value to emerge kind of more asynchronously. So we can deploy this new API over here, and we'll deploy that thing over there into production, and then eventually there's a new user interface change that comes in,
[00:51:21] sees the new APIs, and bang, we've got some new
[00:51:24] capability. We don't have to
[00:51:26] clump all that stuff together into one big
[00:51:29] block of change.
[00:51:31] But for some people, that's very It's, they can't get their head around it. They can't get their head around things being about the value emerging effectively bit by bit over time. And then suddenly it is that when All the pieces are there.
[00:51:45] Then the value emerges. They're like, well, why don't we just like pull it all together, put it on a massive great truck and deploy it all at the same time, but other options are available effectively.
AI and Team Enablement
---
[00:51:54] Melissa Perri: Yeah. One of the other things we were talking about too is how AI is affecting team topologies and enabling teams. What have you been observing in the shift of AI enablement platforms? All of that?
[00:52:08] Matthew Skelton: So there's obviously different types of AI, right? And there's the AI, which helps people to generate content and generate ideas and that?
[00:52:16] kind of thing. And then, I mean, There's like a sort of like a spectrum, but there's, but at the other end of the spectrum, there's, you know, Sort of agentic or agent based AI which then can go and make decisions and, and, and deploy new stuff and effectively innovate on products or define new new workflows or whatever it might be.
[00:52:40] There's clearly, there's clearly a lot of workflows that are going to get speeded up in the kind of human based, like humans using these kind of tools, developing these more quickly, getting insights more quickly in terms of data and reporting And metrics and dashboards and correlations and and so on generating code.
[00:52:57] That kind of thing, which is good. It's fine. The only challenge is that certainly in the code generation side, like writing code was never really the bottleneck, not properly, it's understanding that has been the, the, the, the most important thing, like a high fidelity understanding of what we're actually doing.
[00:53:14] The insight that I had recently though, was that actually, One of the insights, actually, if you think about executives in an organization, let's say it's the CEO or the COO or whoever, someone in, someone in sales and marketing, or even product, interacting with, with technology teams in some organizations is a bit like prompting chat GPT or Claude.
[00:53:40] It's like
[00:53:41] they, they, they say some things, they do a magic incantation
[00:53:44] and then some gobbledygook pops out and they go, Oh no, we didn't mean that. Try something different. And then something else pops out and I go, no, that's a bit closer. How, what else do I need to do I need to use like a special handshake or like a magic phrase.
[00:53:57] And it, it probably doesn't feel very much different from, from like prompting, prompting kind of a group of humans to build software. Probably doesn't feel that much from prompting a chat GPT, because we've not taken the time to really connect things better and understand. Build like awareness of, of, of, of how to, how to frame things so that the output is better.
[00:54:20] And, and so I guess that's why that's the kind of perspective from, from, from some leaders. They don't, they, they haven't had much luck with, with humans. So why don't, why don't we try, '
[00:54:32] Melissa Perri: Replace
[00:54:33] 'em,
[00:54:33] Matthew Skelton: don't we try AI instead? I've been thinking through, so, so just stepping back. So there's clearly going to be, there already is like lots of things that are going to be speeded up.
[00:54:42] By generative AI and generative AI plus other kinds of tools as well. It's not just about the generative stuff, but, but, but there's some, there's lots of shortcuts there. So fine. Lots of stuff will get speeded up. We'll be able to, to get certain things done quicker. We may even be able to get certain kind of product things tested way quicker.
[00:55:02] So you might be able to build and generate like 200 different versions of something. Login page, user journey, whatever. Something, something, something, deploy them into production, get some feedback or, or, or even run, run these against some synthetic users. So generate some synthetic users with some like you know, with some ways of behaving or some particular input that these, that the LLM can generate.
[00:55:27] Find the find the three top performing versions of that product or that feature or whatever it is out of the 200 And just throw away the code for 197 of them. We're never going to use it, don't care.
[00:55:40] That seems reasonable. Like we, we don't need to keep that code around. We'll just keep the code from, from the three that were interesting. and then we'll work on that.
[00:55:47] So it does open up some interesting new kind of like
[00:55:49] possibilities for how you even think about,
[00:55:52] The, the approach to, to product, like now we can now actually do testing at like 10 X or 100 X compared to before we don't need to
[00:56:01] bet so heavily on one particular thing. We can actually get the data to do it.
[00:56:04] So that's kind of cool.
[00:56:07] that changes the, the, the
[00:56:08] change of the cost dynamics around certain kind of
[00:56:11] you know, like market probes and things like that.
[00:56:12] Melissa Perri: Yeah. I think. There's like a whole thing about how AI is going to replace product managers. And I think that's not true. I do think it's going to replace some of the menial tasks that we do on a day to day basis. I also think it's going to empower product managers to do their job better and empower us to be able to ship better, faster, like you're saying. So where I've been really excited in the product ops space with AI stuff. And I do think on this enablement side and this platform side, like you're talking about, I think AI is going to be key players. Of doing those functions that.
[00:56:46] those teams are doing, right? Like to, to be able to enable product managers. One, I think it's getting a lot easier to query large sets of data and be able to ask you questions and come back with, Oh, yep. This is like the trend and user behavior that we've been observing based on your question, but you still need to know what's the right question to ask, right? And that's what takes a product manager.
[00:57:06] But now I don't need to go to a data analyst to go pull SQL queries and do all this stuff here. I can. You know, have my, my data platform and with the AI type interfaces that they're putting on it now, I can just ask the questions and it will be able to spit it back out at me. That's so much faster than what is out there right now.
[00:57:25] Like blows my mind compared to what we used to have to do. So now I've got the data I need to make decisions faster. On the other side for the customer and market insights piece, we have a lot of LLMs that are aggregating internal customer data that we've, we have. We have the behavior sets from, you know, our, our user analytics things, but also from like sales calls from user research from support tickets, all of those things.
[00:57:48] We're able to go through that instantly now and surface up problems and be able to react to it
[00:57:53] in real time,
[00:57:54] which is amazing.
[00:57:55] Matthew Skelton: You can do it in aggregate as well. So like, what's the, what's the aggregate sentiment around this thing or that
[00:58:00] Melissa Perri: Are people happy? Are they not like we used to run NPS studies for that. And then nobody wanted to answer them. And we always had problems because you would pop up an NPS survey in the middle of somebody's workflow and they'd get real pissed and be like, well, 1, I hate you.
[00:58:12] I would never recommend you. Right? Like. So, it's now it's actually some good feedback that we can get out of this other stuff and not disrupt people's workflows. So, I think there's so many things that are enabling us to build better products and learn about our customers. And I'm really excited to see the tools evolve on it, and I see that as a critical part in product operations, like getting that stuff in there so that our product
[00:58:34] managers can actually
[00:58:35] take
[00:58:36] advantage of it
[00:58:36] And use it. Mm-hmm
[00:58:39] Matthew Skelton: And part of that is about understanding like the nature of particularly generative AI and some of the, the tools alongside it This stuff doesn't understand. It's pattern matching. It's next token predicting. The humans are still understanding. We've still got the empathy. with the users, or we should have, hopefully we have, empathy with the users of the, of the value we're producing. and we've got the, humans have got the intent. We've got, we're able to like understand the organizational intent is and discuss it.
[00:59:11] and agree it. And then we can frame the, so we can, we can use these tools to to pull stuff and help us in my job. But even if we're using AI agents, we're framing the mission and the context for these agents in a particular way to, to achieve a particular goal. I was thinking about this more generally with in the future where there's lots of kind of AI workers, effectively, agents, and like, how would you, how do you get to the point where, let's say you've got an ensemble or a pool of, of, of agents, AI agents, how do you. get to the point where you trust them to do the right thing, effectively?
[00:59:49] Like, would you really give them full access to your production database across the entire estate? Would you allow them to deploy all kind of random services and workflows and things just willy nilly or anywhere? It's like, probably not. That's probably not the wisest thing because we know what happens when people, like humans, have got unfettered access.
[01:00:08] Things are going to go wrong. That's why I got security policies in place. That's why we've got, typically speaking, Teams aligns to, on a long term basis, aligns to particular products or product areas or domains or whatever it is. And that's about, you know, you, you're bounding their context literally domain driven design talks about bounding context, right?
[01:00:26] And, and and you, there's, there's evidence now that, you know, smaller language models are more effective at certain things than large language models. They've got a smaller domain context. Well, guess what? This is information processing we're talking about. And it's not surprising to me at all that you see.
[01:00:40] But going back to the 70s and 80s, expert systems, very small, tight focus of domain expertise. Okay, they're going to perform quite well in that area. They can't, can't transfer that to something completely different. It's not surprising at all. It's the same thing we've seen in humans, because this is fundamentally about information processing and knowledge and awareness and context and things. so I mean, this is pretty early days, but it seems to me like that the patterns in teach qualities and product operations. will apply to agentic AI, we're using the same principles and we're saying, well, how would we get to the point where we trust a pool of AI agents? Well, we, we'd set some parameters.
[01:01:20] We'd, we'd limit access to certain things. We'd give them some goals. We would make sure that their mission is aligned to the, to the outcomes and things, and make sure that there's some comeback if, if things go wrong. That's how we've done it with humans, right? That's probably how we're going to trust something that's autonomous.
[01:01:36] The organizations that have managed to allow autonomy, autonomous teams to work at speed and at scale have solved that. It's the same kind of trust parameters, I think, that we put in place for Agentica AI. And the same with product operations, like you'd want to be giving
[01:01:54] You give it, give you make available data, insight data to the, to the AI agents.
[01:01:59] Well, how'd you do that? Well, that's kind of a product operations thing. You're giving it to humans and you're giving it to AI agents. It's kind of the same thing. I mean, we'll see, we'll see. But, but that, it feels right to me because it's, it, because the nature of the, when you frame it in that sense, kind of like it's knowledge work, it's manipulating information, it's about setting goals, it's trying to achieve something, it's ultimately the same, the same kind of task from my perspective.
[01:02:23] Melissa Perri: Oh, I'm excited to see that evolve over time and I agree with you. I do think that's gonna be a key player here.
[01:02:30] Matthew,
[01:02:30] thank you so
[01:02:31] much for being on the podcast. If people wanna
[01:02:32] learn more about you Team Topologies, where can they go?
[01:02:36] Matthew Skelton: They can find me at matthewskelton. com.
[01:02:39] That's my website.
[01:02:41] With links off to other places.
[01:02:43] My consulting company is Conflux, which you'll find at confluxhq. com We're working with all kinds of organizations in all parts of the world. And the, the Team Topologies website, where you'll find all the information about Team Topologies and kind of how to get involved and how to become an advocate and everything else and our community and live stream and a bunch of other things you'll find at teamtopologies. com.
[01:03:05] Melissa Perri: Great. Well, thank you again, Matthew, for being on and thank you to our listeners out there, we will put all of those links that are show notes at product thinking podcast. com. Thanks again for listening to the product thinking podcast. We'll be back next Wednesday with another amazing guest and send all of your questions to dear Melissa. com in the meantime, we'll see you next time.