The challenge is, of course, that Safer's turned into a big certificate factory.
It's a certificate circus.
It's all about 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 teams and they're coming together they're very complementary i think because they've got the same underlying principles it's start with user need 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 is obvious but turns out for lots of people it's it's a very different way of doing things.
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 think like a great product leader.
This is the Product Thinking Podcast.
Here's your host, Melissa Perry.
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.
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 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.
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 in 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 Northstar 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 on board.
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 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.
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 making more money and 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.
Thank you. Hi, Melissa.
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?
Good question. So first off, I should say like I'm a little bit star struck to be here still you know 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 teen topologies book was published which means i was writing it with my
co -author manual prairie she was writing actually six years ago and 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 the people approach us for relates to teen topologies not all of it but a lot of it is related to the material
and the ideas in the teen sporties 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 teen sporties 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 like one of the things that they see is that the language in the teen Bodies book is really suited.
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 Bodies, we've got Project to Product by Vic Kirsten and other books by people like Dominica DeGrandis, who's also kind of in this sort of space and Sooner, Saiter, Happier by John Smart and his co -authors and so on and so on.
There're 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 we're building.
So that's where I'm now helping organizations to navigate this whole space.
And effectively, the language and patterns in data properties is very suitable for 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, on the technology side, the whole DevOps movement since about 2009.
So as cloud became available, infrastructure was no longer a bottleneck.
IT infrastructure was no longer a bottleneck.
And therefore, we could have better flow in IT delivery.
And a lot of that movement, which is where 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 that all 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 very very complementary and so we've arrived now where we are today kind of bringing together your work particularly products operations and teach bodies and they're coming together because i think they're very complementary
i think because they've got the same underlying principles it's start with user need 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 it turns out for lots of people it's it's a very different way of doing things and so they're latching on to like product operating model as a as a way to get out of a very slow very cost inefficient way of doing things 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 bearer for a little bit too and just like the whole premise of it like how do we make the infrastructure the 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 sales people 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.
It 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 Exactly.
The team technologies 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 back in the days when you had a separate IT operations team and some organizations still do.
But effectively, you got to the point where, certainly in team technologies, 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, because of the nature of technology, it's very complicated.
Because of 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, 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 just do like one team does development and then passes it to 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 and to my mind that's really obvious it turns out that that is not at all obvious to lots of other people which i
think is why the teams bodies 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 catalog 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 which resonates and we 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 a way of thinking through
solutions to the extent that people are using the team's bodies patterns are 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 a like a holistic experience and so on and so on because it's fundamentally about knowledge work so we do know some people are using 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 But 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.
Yeah, because we 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.
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 so in general like when when organizations are 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 unwilling 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 I'm not going to
teach you anything about, you know, 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 6, 7, and 8 in the conclusion, which is where the really important stuff is.
It turns out that lots of business books are basically repeated.
They've got two chapters at the beginning, and then 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 they just read the first few chapters I noticed your book is not like that which is good so we've had people basically misunderstand what's
going on they 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 counter that what are the types of things that they're skipping there they're
probably like oh in 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 teams 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 analysis, right?
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 to teams so teams that are aligned to the stream of value that's why it's called streamlined we decided not to use the word product because we've 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 the product was the physical thing 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 you know figures out how much money you can get from the loan the algorithms behind that exactly the way the loan is processed how you actually get distributed the money the way you pay all of all of those things so i feel like the way that you called it takes away all of that nuance
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 Not everything
is a product. Please don't do that.
Yeah. Please don't do it.
Clearly, there's massive value from using product thinking and product management approaches across a whole organization, like really low -level stuff.
Instead of building a piece of technology, who is the value consumer for a stream of value around this thing here?
Brilliant. So you can use product 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.
The reasons why they do that, 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.
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 that 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 every little thing in here is actually going to be a product exactly and we've got we've got that as a concept in team supporters in the book we call it we've 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 team supporters book is anything which improves flow and reduces cognitive load or cognitive burden in the team that using that thing and the the smallest or the thinnest viable or 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've worked out this is a nice combination we've curated the experience 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 sas provider or whatever and then the stream
aligned teams you know that were focused on a particular product area look at the wiki page you 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 our
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 it's a it's it's very similar it's in that similar
space because to curate that to curate curate that wiki page we have to understand the needs of the teams that are using it and trying 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 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 streamlined
teams in the organization so just focused on no handoffs a mixture of skills end to end value flow and and yeah that's if you like an ideal state so we don't have any we can manage all all the infrastructure 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 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 so 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 aligns teams or product teams, the cognitive load would be too high.
Are we really going to hire multiple people with maths PhDs to do that work inside the product team?
No, it just doesn't make any sense.
This is interesting.
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 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 is pulled a lot of those subject matter expertise out when they don't know product and put them into those uh complicated subsystem teams like you're talking about so that they can advise on the those pieces of you
know 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 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 the other type of team that we
talk about in team technologies 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 a particular like like an engine for reporting or an engine for calculation or something for 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
there they've got some expertise in compliance or in regulatory reporting or whatever and they're working with a streamlined 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 to leave that streamlined
team independent and not not dependent on 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 so they've got a good understanding or better understanding and then detach if you like like lead 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, 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 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 he responds to changing technology, regulations, business challenges, whatever.
How we respond to that on an ongoing basis.
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 things that help at scale, right?
If I'm on a new 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 you know 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 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 right so I've run out of stickies what do you call these little marker tab I've run out of them because I was marking so many pages, right?
So when I listened to the podcast 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 flight out to Germany on the way back again because 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 intent behind the material in the two books.
The intent is rapid, safe, ongoing flow of value by thinking through where we're putting that cognitive burden or where we're putting the particular domain context and so on and so on, who should be doing what, if you 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's talking about how we do work.
It's talking about it with a slightly different language but very similar, to be honest, but a slightly different perspective.
and teacher 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 like the context is a bit different but the I think the underlying principles are very highly aligned you come
from a product perspective and I've come from a kind of technology perspective but really we're trying to solve I think pretty much solve the same problem where it's not, it's very close, yeah so I 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 Teams policies.
I don't think it's all obvious.
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 all the time 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 tune 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 get into
it in a little bit about how AI has replaced some of my thoughts previously but But as a concept, I feel like, you know, I've worked with dozens, 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.
And I feel like the biggest naysayers of product operations always comes back to they haven't really done this stuff at scale.
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, OK, when I was at Athena Health, 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. I was basically 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.
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.
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 where 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 and he's 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 it's always as if some people
think that things should be hard people rather than easy like I I think in the team sponsor, we talk about, we quote someone called Evan Botcher, who talked about how to define digital platform.
And I think I'm paraphrasing now, but in Evan Botcher's article, he says something like, a platform should make the right thing to do easy, something like this.
Like, why wouldn't you, so 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 technology, whatever.
Like, why wouldn't you want to make that as easy as possible for people to 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 APIs or inside those services.
To me, I'm sure to you, like, why wouldn't you want to do that?
But to some people, it seems that they're almost offended that there are 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.
Why wouldn't you want to do that?
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? Why? Why? Like, 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?
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, like let's understand what the value that we can provide in this organization.
And clearly loads of organizations, it's more about HIPAA, 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 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 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 we don't really know what the value is we haven't worked in in those terms and it's really interesting to see that realization that 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 uh like a lens or like a like a prison that then that 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 yeah i also feel like it exposes like a different mindset or something like that 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 that stuff 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 Teams Apologies?
And how are you helping people like break out of the SAFe mentality there?
Great question. So the Scaled Agile Framework decided to include some of the terminology from Teams Apologies in, I can't remember which person it was, six or something a few years ago.
It's so funny. they're just like i'm just gonna grab this thing and shove it on my mat 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 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 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 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 are one levels 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 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 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 it's that that place is really not large big business systems banks and stuff like this because you want to be able to change you need to need to be able to change your 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 scale -dagger 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's 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 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 from marathon and and do that every day then you get
then you're at the point where you're deploying you know 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 approaches to product but it takes a while 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.
So I've been talking quite a bit to M.
Campbell Priti, who's one of the leading experts in safe and has been for ages based in, she's 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 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 into a big certificate factory.
It's a certificate circus.
It's all about 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 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 um my like problem with it as always and i talked about this a little bit on lennie'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 like hash this out and i have 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's it's 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 the portfolio team and 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 yeah and it's it's got the assumption that things need to be very big and chunky yeah rather than like what would it take not to need to have that kind of coordination yeah 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 their head around things being about the value emerging effectively bit by bit over time and then suddenly when all the pieces are there then the value emerges.
They're like well why don't we just 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.
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?
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 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 are going to get speeded up in the kind of human base, like humans using these kind of tools, developing these more quickly, getting insights more quickly into the data reporting and metrics and dashboards and correlations and so on, generating code.
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 bottle egg not properly it's understanding that has been the the 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 even 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 it's like yeah they 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 oh it's a bit closer what else do i need to do
i need to use like a a special handshake or like a magic phrase 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're not taking the time to really connect
things better and understand build like awareness of of how to how to frame things so that the output is better 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 replace them 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 by generative ai and generative ai plus other kinds of tools as well it's not just about the generative stuff, but there's some, there's
lots of shortcuts there.
So fine, lots of stuff will get speeded up.
We'll be able 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 these against some synthetic users.
So generate some synthetic users with some ways of behaving or some particular input that the LLM can generate.
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. That seems reasonable.
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.
it does open up some interesting new kind of like possibilities for how you even think about the the approach to to product like now we can now actually do testing at 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 the the change of the cost dynamics around certain kind of market probes and things like that?
Yeah, I think there's 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 faster, like you're saying.
So where I've been really excited in the product ops space with AI stuff, and I do you 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
one 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 the 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, 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 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 you can do it in aggregate as well so like what's the what's the aggregate sentiment around this thing or that thing 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 mps survey in the middle of somebody's workflow and they'd get real pissed and be like one one i hate you 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 managers can actually take advantage of it and use it.
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.
We'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 these humans have got the intent we've got we're able to like 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 you let's say you've got an ensemble or a pool of of agents ai agents how do you get to the point where you trust them to do the right thing effectively 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 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 align to particular products or product areas or domains or whatever it is.
And that's about, you're bounding their context.
This really domain -driven design talks about bounding context, right?
And there's evidence now that 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 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 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 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 authentic AI and the same with product operations like you'd want to be giving you give it give you make available data inside data to the to the AI agents well how do 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 the nature that 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 kind of task from my perspective.
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?
They can find me at matthewskeleton .com.
That's my website with links off to other places.
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 teen topologies website where you'll find all the information about teen 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 teen topologies .com.
Great. 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 at 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 dearmelissa .com in the meantime.
We'll see you next time.
