Loading summary
Transcript47 lines
- [00:00]
Matthew Skelton
The challenge is, of course, that SAFE has turned into a big certificate factory. Yeah, 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 natural incentive to stay certified and 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. And so we've arrived now where we are today. Kind of bringing together your work, particularly product operations and team to bodies. And they're coming together. They're very complementary I think because they've got the same underlying principles. It's start with username 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. 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 a very different way of doing things.
- [00:58]
Melissa Perry
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 product pressing product questions, we'll dive into this system from every angle and help you think like a great product leader. This is the Product Thinking Podcast. Here's your host, Melissa Perry.
- [01:33]
Hello and welcome to another episode of the Product Thinking Podcast. Today I'm thrilled to be joined by Matthew Skellin, co author of Team Organizing Business and Technology Teams for Fast Flow. Matthew is a respected thought leader in organizational design for software delivery and and has helped countless organizations reshape how their teams work together. 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 the segment of the 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. 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 copilots 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 live blocks to drive engagement and growth in their products. Join them today and give your users an experience that turns them into daily active users. Sign up for a free account today at liveblocks IO. 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. 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 SaaS. And that's okay. But we can get to good metrics on what to measure 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. 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. 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? 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? 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 and 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. 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 North Star metric from the product side, if you're looking at the software, you probably want to reduce something like the time it takes to create an account. Maybe you are not doing a self serve flow where somebody can just come in and open an account by themselves. 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 onboard. 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? Where 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? And then you want to set your North Star metric off of that. So it could be about reducing time for a certain task 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. 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, 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 balance 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. 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. 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? 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 the making more money, reducing costs over time. 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 dearMelissa.com and let me know what they are. Now it's time to talk to Matthew. Hi, Matthew. Welcome to the show.
- [07:57]
Matthew Skelton
Thank you. Hi, Melissa.
- [07:58]
Melissa Perry
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 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?
- [08:36]
Matthew Skelton
Good question. So first off, I should say, like I'm a little bit starstruck to be here. Still 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 teacher publish book was published, which means I was writing it with my co author, Manuel Perry, who was writing it actually six years ago. It takes a book. Publishing is very not agile, it's very waterfall and so a lot of the kind of inbound contact and Things that people approach us for relates to Team Topologies. Not all of it, but a lot of it is related to the material and the ideas in 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's bodies but 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. Like one of the things that they see is that the language in the Team Topologies book is really suitable. The language and patterns on ideas and practices and so on are 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 other books by people like Domenico de Grandis, who's also kind of in this sort of space and Sooner Safer, Happier by John Smart and his co authors and so on and so on. 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 moved 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 building. So that's where I'm now helping organizations 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. You know, IT infrastructure is no longer bottleneck and therefore we could have better flow in IT delivery and a lot of that movement, which is what 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 learnings from that movement are really all about. Let's find out what the value is, let's get 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 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. And they're coming together because I think they're very complimentary, I think because they've got the same underlying principles. Start with username 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. Like that's, that's how we do stuff effectively. Which for you and me is obvious, but turns out for lots of people it's a very different way of doing things. And so they're latching onto like a product operating model as a way to get out of a very slow, very cost, inefficient way of doing things.
- [12:25]
Melissa Perry
I always thought the DevOps people were like the product people of the development world. I always end up at DevOps conferences and I've known the community for a while. I worked with Kevin Baer for a little bit too. And just like the whole premise of it, like how do we make the infrastructure that developers use and how we actually get things out the door better and faster and do that flow? It's always made sense and I feel like it never got carried through all the way 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? 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. 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. 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 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 less about, you know, formal roles. 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 if we're not all working together, especially if you're shipping a software product, like 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. And in your Team Topologies book you go into how we should be collaborating around that, which I think is really interesting.
- [14:46]
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 were better together when back in the days when you had a separate IT operations team and some organizations still do, but effectively 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 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 details about 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. Those days are gone and now we need to retain that kind of ongoing context for safety reasons and for good decision making around the product 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 ask 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 the Teens Bodies book, I mean it's sold, I think it's now 180,000 copies, which is, I'm told, is a huge number. It's certainly one of the top selling books from IT Revolution. The publisher, they do a great job in curating their catalog and promoting the book and things. But it's clearly found, it clearly resonates with people. There's something about it which resonates and as you said, we deliberately didn't try to plug in lots of different roles into. It's not a framework, it's a way of thinking. It's a way of approaching problems, a way of thinking through solutions. To the extent that people are using the teams bodies patterns well outside of it, they're using it for managing doctors 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 services in law firms. So instead of being bounced from one kind of legal practice or a legal discipline to another, you get like a holistic experience and so on and so on. But it's fundamentally about knowledge work. So we, we do know some people are using the team's body's ideas in sales and marketing too. There's a case study, I think we've got a case study coming out soon in 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, 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 more like coherent?
- [18:12]
Melissa Perry
Yeah, because we together model product management, development, design. We never talk about the sales marketing piece. Right. Like where they come from and it's just like, oh yeah, those people, it's like, oh, those people who actually market and sell our things to make money. We should figure out how to put them in. We. When you're looking at applying team topologies to a product operating model, what do you feel like people are getting wrong these days? What are some anti patterns that you've been seeing that are tripping people up from that flow? And on the other side of it, what have you seen work really well?
- [18:50]
Matthew Skelton
So in general, when organizations moving towards. That'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? 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 finish that little package of work that there's no ongoing effect from the way in which you chose to do that work. 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 are willing to, I haven't realized they need to invest 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 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 brings so many other 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. But I'm not going to teach you anything about you stuff. 15 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 really important stuff is. It turns out that lots of business books are basically repeated. They're like two chapters at the beginning. And then the Rest of the rest of the book is just filler and it's just repeated. So then that's what a lot of business leaders just do. 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, think it's way too simple. They just fixate on the types of team and maybe a couple of other things and don't get the more important concepts out of it, which is unfortunate. So we're doing some work to try and to counter that.
- [21:15]
Melissa Perry
What are the types of things that they're skipping there? They're probably like, oh. In the book, for the people who don't know, Matthew lays out like these four fundamental topologies where you got streamlined teams, which are what we would call our product team. So for example, if you're at a bank and you have a product team around the credit card business, you know, at a giant bank that's domain focused, stream aligned, you're delivering the value of the credit card to that customer. And then you have enabling teams that support those streamlined teams to be able to do their work effectively. You've got complicated subsystem teams, which I think is interesting, especially for complex organizations. And that's more about domain knowledge and deep like analysis. Right.
- [21:56]
Matthew Skelton
And then the fourth one is a platform. So the types of team and the reasoning behind creating different types of team is important. And that's something that doesn't appear until later in the book. So we start with the premise that what would it take just to have stream aligned teams so teams are aligned to the stream of value. That's why it's called streamlined. We decided not to use the word product because we'd be 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, the product was the physical thing.
- [22:30]
Melissa Perry
Yeah, I think that's the decision you made though too because even in like banks I get into the arguments about what's the product. They're like it's the actual loan, right. Rather than the whole system that actually figures out how much money you can get from the loan, the algorithms behind that, the way the loan is processed, how you actually get distributed, the money, the way you pay it, all of those things. So I feel like the way that you called it takes away all of that nuance.
- [22:56]
Matthew Skelton
And I mean this is a bit of an aside but like, yeah, we're Actually working with one organization right now in the financial space and they've gone all in on product operating model and like every single thing is a product. And we're like, no, not everything, please don't do that, please. 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? Brilliant. Use that. So use products, techniques across the whole organization, but don't necessarily obsess that everything has to be a product with an external consumer. It's just not realistic.
- [23:38]
Melissa Perry
The reasons why they do that too, 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 is for, 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. 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 enabling APIs that go back into it.
- [24:07]
Matthew Skelton
Exactly.
- [24:08]
Melissa Perry
So they try to make everything a product and then they're like, okay, great, 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. But it doesn't mean that, you know, every little thing in here is actually going to be a product.
- [24:36]
Matthew Skelton
Exactly. And we've got, we've got that as a concept in Teams Bodies in the book we call it, we got the concept of a platform. I actually really 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 teams produce book is anything which improves flow and reduces cognitive load or cognitive burden in the team 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. Like 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% of your problems in this space. We've done the research on it, we 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, that's, 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 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 very similar, it's in that similar space because to curate that, to create, 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. 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 four team types that, that we talk about in the book, they're all predicated on that. They're, we, we start with the stream aligned team, like what would it take just to have stream aligned teams in the organization? So just focused on no handoffs, a mixture of skills, end to end value flow. And that's if you like an ideal state. So we don't have any, we can manage all the infrastructure or all of the data ourselves and 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 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, it's not really related to the product itself, the value, consumer value. And we want to take some of those, some like Gubbins effectively and move it somewhere else. It might be dealing with infrastructure or dealing with data or dealing with security or whatever. And that's where the other three types of team come in. So like a platform or a 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 need, they might need like a PhD in mathematics or they might need to know something about like a particular kind of regulatory reporting. It's like really detailed awareness, complicated algorithm or something like that. And if that algorithm were left inside multiple stream aligned teams or product teams, the cognitive load would be too high. Like are we really going to hire multiple people with maths PhDs to do that work inside the product team? No. Right. It just doesn't make any sense.
- [28:30]
Melissa Perry
This is interesting. Go ahead. Like what you were saying here too I think is really interesting because this is a huge debate we get into in product management about whether product managers need to be domain experts or from and I'll give you an example of it in a second versus no product. Really well. 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. I see a lot of organizations in highly specialized areas, finance, healthcare, for example, insurance, where they will bring people in who have like deep insurance backgrounds and no product management background 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 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 those pieces of let's say like healthcare, like what a nurse would need to be able to prescribe or what you would be able to show in 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 somebody's going to be following.
- [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 properties is called an enabling team and this is often where the expertise would sit. So in a complicated subsystem, those experts will be building something like building a particular, like an engine for reporting or an engine for calculation or something. They're using 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 does not build anything. They're there to uplift the skills and capabilities inside a stream aligned team. So let's say they've got some expertise in compliance or in 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 streamlined team understand how they need to build things in that space. The aim is always to leave that streamlined team independent and not dependent on the experts all the time. So we're going to upskill them. We'll teach them about this thing, help them understand it better, work with them until 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. 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 out of 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 looking for these problems that are recurring for which we can have a useful solution from a kind of central API or something like that. There's a really good way of thinking about things in these terms. This example of how the team topologies language and patterns helps us think through 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 ongoing basis.
- [32:24]
Melissa Perry
What I like about that too, and maybe we can talk a little bit about how you see this with product operations is, you know, you're talking about how things that help at scale, right? If I'm on an enabling team, I'm going to go help these places in isolation, these other teams in isolation, help them out a little bit. But I get to see the patterns and now I get to scale the knowledge once I observe those patterns and see those problems over time. And if we think about those teams just being embedded in one team, right, Those people being embedded in one team or never coming to other teams, we don't get to see the patterns and the problems over time. And to me, like, 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 enable them in some way? Can I fix this with a process? It doesn't necessarily have to be a product, but it has to be 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 what your take was when you saw product operations and how you saw it fitting into team topologies with product management.
- [33:36]
Matthew Skelton
Right. So I've run out of stickies. What do you call these little marker tabs? I've run out of them because I was marking so many pages. Right. 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, because 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 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 people to focus and so on. So, yeah, I mean, when I was reading these patterns, like, yeah, that totally makes sense. Like, it is seeing it's. Seeing it's 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 teeth Body is coming from a slightly different perspective, but effectively it's got the same underlying principles. I think there's a lot of. I'm not saying it's exactly the same because the context is a bit different, but I think the underlying principles are very highly aligned. 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, really. It's not. It's very close. Yeah. So I loved it. I've got loads of quotations which I plan to extract from here and put on social media at some point and make the connection basically to the stuff that's in team's produce. But I don't think it's. I don't think it's all obvious.
- [35:21]
Melissa Perry
Like, I guess not because I still get pushback 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? I'm like, I get sent this to my friends too, but I like, I get, I get this stuff all the time and I. It's so hard for me to. One, I can two out tune out naysayers, but I also want to listen to feedback, right? And I think my views on product operations, they evolve and I think we're going to get into it in a little bit about how AI has replaced some of my thoughts previously. But as a concept, I feel like, you know, I've worked with dozens, almost like probably hundreds of organizations at this point and seen these patterns over and over and over again when it comes to product management at scale. And I feel like the biggest naysayers of product operations always comes back to. They haven't really done this stuff at scale deal. 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? 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 chief Product Officer's job or the VP's job to go and make sure that people know how to write this strategy correctly. And I'm like, okay. When I was at athenahealth, I 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. Right? That was my job.
- [37:14]
Matthew Skelton
I was madness. Exactly.
- [37:15]
Melissa Perry
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. And I feel like a lot of the work that I've been doing along the way in 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 because 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, or they still 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, 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. And if you do that wrong, you don't get any visibility at scale. Like, I can't just turn to 500 people and ask them what they're doing.
- [38:35]
Matthew Skelton
It's almost as if some people think that things should be hard rather than easy. Like I think in the teams project, we talk about and we quote someone called Evan Botcher who, who talked 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 should make the right thing to do easy. Something like this, like, like why wouldn't you? So you 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 this industry, in this, with this technology, 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 makes it easy for other teams or product managers or whoever to 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 those services. To me, I'm sure to you, like, why would you want to do that? To some people it seems that they're almost offended that there are some people like teams will 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, why wouldn't you want to do that?
- [39:51]
Melissa Perry
Exactly. I don't get why. The other pushback I get is it's a rite of passage for product managers to go learn MongoDB and try to pull stuff out of a database. Why? That's not their job. Their job is to interpret the data, be able to analyze the data and do that. But why do we have to let them recreate these processes 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 build great products and whatever's standing in the way of that. Why wouldn't we want to make that easier?
- [40:30]
Matthew Skelton
Yep. And again, I think that's the 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, let's understand what the value that we can provide in this organization. And clearly loads of organizations, it's more about Hippo, 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 really. It's like they're on the psychologist couch. Like, tell me about yourself. What value do you provide? 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. So then that's where some of the awkwardness arises 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, we're saying align teams to the flow value. Well, what's the value? 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. And people go, oh 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 flow value? Like, it's, it's these kind of approaches. I don't know where you see this as well, but these kind of approaches are like a lens or like a, like a prism that then refracts the light and you see that the organization kind of has got some very different opinions about how to do work, let's say.
- [42:13]
Melissa Perry
Yeah, I also feel like different mindsets.
- [42:16]
Matthew Skelton
Or something like that.
- [42:16]
Melissa Perry
I find too, a lot of the naysayers on product ops are probably not doing real product management, right? Like maybe they're doing some of the, some of the grunt work around there, like trying to showboat as if they're really busy, but they're not really doing the value delivery pieces of it. And I have seen that in a couple organizations as well. 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? Anything that has to do with process, like bad word, we can't talk about process. What have you been observing out there with safe and especially with team topologies? And how are you helping people like break out of the safe mentality there?
- [43:05]
Matthew Skelton
Great question. So the Scaled Agile framework decided to include some of the terminology from team topologies in. I can't remember which version it was six or something a few years ago.
- [43:14]
Melissa Perry
It's so funny. They're just like, I'm just going to grab this thing and shove it on the map.
- [43:22]
Matthew Skelton
So I came up with an analogy for this. So if you think about blueberry muffin, it's been carefully put together. The Blueberries in the middle are being baked. It's like when you bite into it it's like oh, it's really nice. But you can take a raw muffin and push some blueberries in. It doesn't make it a blueberry muffin. Right. 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 feels a little bit like that. But, but, and like there's a side effect of that is actually that we thanks, thanks to scaled Agile framework, thanks to Safe, we actually get a number of sales leads because they've discovered teams bodies through that and then we, and then we get a call. So like a one level that's good. Okay, that's 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. Like these things are literally disconnected and need to run disconnected for substantial periods of time because 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 planes, for example, stuff like this, 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 that place is really not big business systems, banks and stuff like this because you want to be able to change, you need to be able 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 Internet connected business systems. At the same time I think the scaled agile approach seems to seem to act like a kind of walking frame or a crutch for organizations that are coming from a very waterfall place and trying to be more nimble. And it acts like an intermediate step, like someone who let's say they couldn't walk and so they've been going through physiotherapy and so they're using like a walking frame to do that. Well, okay, use a walking frame for a bit and if that helps, that's cool. But how do you get beyond that. So we're talking to an organization in Europe at the moment, and we've worked with a few in the past where they had used SAFE for a bit, and now they've got to a point actually where 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 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 for a marathon and do that every day. 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 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 kind of nimble approaches to product, but it takes a while.
- [47:02]
Melissa Perry
Yeah. And when you're looking at safe, 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 that's better to start at instead of safe? When people are trying to achieve that delivery type, especially just get things out the door delivery type mindset.
- [47:27]
Matthew Skelton
So I've been talking quite a bit to M. Campbell Pretty, who's one of the leading experts in SAFE and has been for ages. Based in Australia. We're working together on some ideas and some comparison and so on and so on. And I'm hoping to do some more in 2025. In theory, I think safe is a reasonable place. If the organization has the equivalent of 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 into a big certificate factory. Yeah, 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 Natural incentive to stay certified and 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 whole industry around it. Yeah, 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 approach.
- [48:43]
Melissa Perry
My problem with it, as always, and I talked about this a little bit on Lenny's podcast, but I've seen people, I feel like their big room planning sessions inspire the right type of mindset of let's all get together and hash this out. And I've seen people really benefit from adopting that. And organizations come a long way from that. But then it turns into the big batch part that you're talking about, right, where they interpret it. I don't know if SAFE says this or they interpret it, but I have never seen an organization interpret it 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. 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? 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 spun 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, 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. So now we're spinning up like different roles and different teams everywhere. And it's like, no, that's a 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. 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. So I see always a break in how we determine what's valuable and then get that out the door.
- [50:54]
Matthew Skelton
Yeah, 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 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, sees the new APIs and bang, we've got some new capability. We don't have to clump all that stuff together into one big block of change. But for some people that's very, it's. They can't get their head around it, they can't get head around things being about the value emerging effectively bit by bit over time. And then suddenly is that when all the pieces are there, 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.
- [51:54]
Melissa Perry
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 that.
- [52:09]
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 kind of thing. And then I mean there's like sort of like a spectrum, but there's at the other end of the spectrum there's sort of agentic or agent based AI which then can go and make decisions and deploy new stuff and effectively innovate on products or define new workflows or whatever it might be. 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 so on, generating code, that kind of thing, which is good. It's fine. The only challenges certainly in the code generation side, like writing code was never really the bottleneck, not properly. It's understanding that has been the most important thing, like a high fidelity understanding of what we're actually doing. 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 sales and marketing or even product. Interacting with technology teams in some organizations is a bit like prompting ChatGPT or Claude. It's like they say some things, they do a magic incantation 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 they go it's a bit closer. What else do I need to do? I need to use a special handshake or a magic phrase. And it probably doesn't feel very much different from like prompting kind of a group of humans to build software probably doesn't feel that much from prompting a ChatGPT because we've not taken the time to really connect things better and understand, build like awareness of how to frame things so that the app is better. And so I guess that's why that's the kind of perspective from some leaders. They don't, they haven't had much luck with humans. So why don't we try replace them, try AI instead. I've been thinking through so just stepping back so there's clearly going to be. There already is lots of things that are going to be speeded up by generative AI and generative AI plus other kinds of tools as well. It's not just about the generative stuff, but 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. So we might be able to build and generate like 200 different versions of something login page, user journey, something, something, something, deploy them into production, get some feedback or even run, run these against some synthetic users. So generate some synthetic synthetic users with some like you know, with some ways of behaving or some particular input that these, that the LLM can generate. Find the, find the three top performing versions of that product or that feature or whatever it is after the 200 and just throw away the code for 197 of them. We're never going to use it. Don't care. That seems reasonable. Like we don't need to keep that code around. We'll just keep the code from the three that were interesting and then we'll work on that. That it does open up some interesting new kind of like possibilities for how you even think about the approach to product now. We can now actually do testing like 10x or 100x compared to before. We don't need to bet so heavily on one particular thing. We can actually get the data to do it. So that's kind of cool. That changes the cost dynamics around certain kind of market probes and things like that.
- [56:13]
Melissa Perry
Yeah. 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 op 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 those teams are doing. Right. Like to. To be able to enable product managers 1 I think it's getting a lot easier to query large sets of data and be able to ask questions and come back with oh yep. This is like the trend in 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. 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 have 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. 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 have. We have the behavior sets from our user analytics things but also from sales calls, from user research, from support tickets, all of those things. We're able to go through that instantly now and surface up problems and be able to react to it in real time, which is amazing.
- [57:56]
Matthew Skelton
You can do it in aggregate as well, so what's the aggregate sentiment around this thing or that thing?
- [58:00]
Melissa Perry
Are people happy or are they not? 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 one I hate you. I would never recommend you. Right. Like so it's now it's actually some good feedback that we 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 and product operations like getting that stuff in there so that our product managers can actually take advantage of it and use it.
- [58:39]
Matthew Skelton
And part of that is about understanding like the nature of particularly generative AI and some of the other tools alongside it. This stuff doesn't understand. It's pattern matching. It's next token predicting. The humans are still understanding. You've still got the empathy with the users or we should have. Hopefully we have empathy with the users of the value we're producing and we've got the humans have got the intent. We're able to understand the organizational intent is and discuss it and agree it and then we can frame the so we can use these tools to pull stuff and help us in that job. But even if we're using AI agents, we're framing the mission and the context for these AI agents in a particular way 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 agents, AI agents. How do you get to the point where you trust them to do the right thing effectively? 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. 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 aligned to particular products or product areas or domains. Or whatever it is. And that's about, you know, you're bounding their context, literally. Domain driven design talks about bounding context, right? And there's evidence now that smaller language models are more effective at certain things. On large language models, they've got a smaller domain context. Well, guess what? This is information processing we're talking about. It's not surprising to me at all that you see, 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 transfer that to something completely different. It's not surprising at all. It's the same thing we see 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 team topologies 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'd set some parameters, we'd limit access to certain things, we'd give them some goals, we would make sure that their mission is aligned to the outcomes and things and make sure that there's some comeback 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. The organizations that have managed to allow autonomy or 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 magentic AI. And the same with product operations like you'd want to be giving you, give you make available data, insight data to the AI agents. Well, how do you do that? Well, that's kind of a product operations thing. You're giving it to human, humans only, giving it to 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, 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.
- [62:24]
Melissa Perry
Well, I'm excited to see that evolve over time and I agree with you. I do think that's going to be a key player here. Matthew, thank you so much for being on the podcast. If people want to learn more about you and Team Topologies. Where can they go?
- [62:37]
Matthew Skelton
They can find me@matthewskeleton.com that's my website with links off to other places. My consulting company is Conflux, which you'll find@confluxhq.com and we're working with all kinds of organizations in all parts of the world. And 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@team topography.com great.
- [63:06]
Melissa Perry
Well, thank you again, Matthew, for being on and thank you to our listeners out there. We will put all of those links at our show notes@productthinkingpodcast.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.