Transcription
And over the last 20 years, one of the things that changed in the agile community— and not all of them, thank goodness— but unfortunately many of them, especially in Europe, decided to take agile in a different direction. They took it in a direction of process and predictability, and the result is they are not getting the benefits of agile.
The easiest way to see that is most of them are releasing once a month or worse, once a quarter. If you're doing that, you're not getting even the most basic benefits of agile. It's just agile theater; this is just waterfall with a marketing name of agile. That's unfortunately what's happened.
Who do you blame for that? I really blame the agile coaches in the community and the industrial complex— all of these certification programs and everything that are just BS. We all know they're BS; they know they're BS. But they are, and it's a shame because agile really can deliver real benefits, but those are the agile principles, not the way the processes have been formalized.
Hey there, welcome back to the show! I'm Aonso, and I'm your host. Before we begin, I just want to take a moment to say thank you. Thank you so much for tuning in! I am so excited to have you here and to share with you this exciting and spicy episode with the one and only Marty Kagan.
Marty has probably observed and advised more product teams and leaders than anyone in the world. For many, he is the Godfather of product management. He's a bestselling author of some of the most iconic books in our industry— he wrote "Inspired," "Empowered," and recently launched "Transformed." He's probably one of the world's most requested speakers in product conferences.
In this episode, Martin and I discussed all things transformation— moving from projects to products, why agile can only really help with a third of transformations, and why it's also the easiest part. We talked about product leadership being the key to enabling transformations, product ops, how AI will impact how we build products, and so much more. This was so fun, and I really hope you enjoy this conversation as much as I did.
All right, without further ado, Marty Kagan!
All right, Marty, we are live! How are you today?
I'm good, Alonzo, thanks! I am so happy to see you. You've just released your latest book, "Transformed," yet another masterpiece. I just wanted to say that it wouldn't be an understatement to say that your work and SVPG in general has been a remarkable contribution to the product community.
First things first, I have a lot to dig into in this conversation. You wrote "Inspired," probably the best product management book for so many people out there, and you wrote it specifically for product teams. Then you wrote "Empowered," specifically targeted for product leaders, and now you wrote "Transformed." So, who's this book for, and why is it needed, Martin?
Sure! Well, like you said, the first two books were really for product teams and product leaders, and it's all about techniques that we see used in the best companies. However, it's also true that right from the very first edition of "Inspired," the probably single most common piece of feedback we would get is that people would say, "The good news is they'd say they like this; they want to work this way; they believe this is the right way to work." But then they immediately would say something like, "But our company could never do this. It's so different than what we do. I don't know if it's even possible for us to change."
And you know, that's what we've been doing for 20 years— helping companies to change. So we knew it was possible, but in truth, we're just a handful of people working with a handful of companies.
What we wanted to do with this book was to kind of definitively answer that question— to show people, yes, it's possible. It's hard, but it is possible. Here are a dozen companies, just like you, that have changed. None of them are Silicon Valley companies; they're all from around the world. If you want to change, you absolutely can.
So that was the goal of this book. It's really, instead of a product techniques book, it's a change management book. It's more about how do you make these changes.
And I love that you targeted that book particularly to that audience, specifically because I see a lot of companies that need to transform, that need that change. Everywhere I go in Scandinavia and in Europe in general, I see so many product managers entitled, but what they're really doing is just a product owner in a delivery team or a feature team. I see so many teams with both product managers and product owners focused on outputs, given a roadmap with features. I see— well, I don't see product leadership through product leadership, and I see an insane focus on delivery frameworks like Scrum and even worse, perhaps, like SAFe and other things.
So, Mario, I wanted to ask you: Is this a global challenge, you think, or do you think Europe is particularly behind in the way most of their organizations structure themselves and operate from a product operating model perspective?
Yeah, I mean, there's a temptation to say, "Oh, well, you know, San Francisco, Silicon Valley, they're way ahead, and the rest of the world is behind." But I really don't think that's true.
First of all, you can be right in San Francisco and find companies with these problems. Unfortunately, I think it's terrible to say that, but it's true. You can find these problems all over the U.S., especially on the east side of the U.S.
And it's also true that in places like Europe, including Scandinavia— how about Stockholm, right, with Spotify? You can find amazing companies that are fantastic, really the good examples of what we talk about.
So, I don't think it's like that. It's more— it's not the location; it really has to do with the leaders and what they believe. If any of those leaders have worked in a company like you may know, with Spotify, the founders had done tech product companies before that. So this was not their first rodeo, as we say. They were able to take what they learned and did a beautiful job with that.
In other cases, you could argue Spotify had it easier because they started that way with their founders. They really did with the important things. On the other hand, a company like Trainline in London had none of this. This was classic everything you just described— old school, you know, delivery frameworks and outsourced engineers, and they completely turned themselves around.
How did they do that? Well, they brought in some leaders that knew how to do that, and that's what they did.
So when you speak about the best organizations versus the rest, which has been a theme from your work for many years, what's then the criteria to bucket some of these best organizations that you see all over the world? Is it what they do differently than the rest, or is it what they generically speaking don't do?
Well, definitely some of both, I would say. By the way, the way we sort of define the best is a company that has proven that they can consistently innovate at scale on behalf of their customers— come up with solutions that their customers love but work for their business. So that's kind of how we define it.
There are some well-known companies that do that; they're really not a secret. They're usually the most successful financially— companies in the world, so the stock market recognizes these companies.
So that's how we define it. What does it really mean when you look at those companies? That's what I think we try to share. When you look at those companies, there are, by our count, 20 principles that you find in those companies that are in all of them. Really, even if they have very different cultures— you know, like an Apple culture is very different than a Spotify culture, it's very different than a Netflix culture— but all of those companies have these principles that they live.
So we refer to them as product-first principles, and I actually think that's what's important. In companies that are not doing these things, that are not able to innovate, you usually don't find most of those principles. It's a very different model.
So, for example, the most— I think probably the most fundamental principle of a strong product company is that they understand the need to experiment. They understand that without experimentation, you get no innovation. They just understand that.
So, you know, you go to a good company, and of course they experiment; they run them constantly. But you go to most companies? No, they don't. What they do, at best, is what we call optimization experiments, which are these trivial A/B tests where they just change something like the size of a font or the color of something, and they see if that does better, if it makes them more money.
Of course, they should do that optimization, but that's not experimentation. That's not what we mean by experimentation. And so that's as basic as you get— an experimentation culture.
Now, there are a lot of different ways to do experiments because there are lots of different kinds of products with different kinds of risks. But if you don't have a way to do experimentation, you're just not going to innovate, as one example.
But there are many examples. Let's dig into that one a bit, and then let's move into some of the other principles. Of course, we won't have the time to cover all 20, but this one— experimentation. You mentioned that optimization is one thing, and real experimentation— really testing ideas continuously over time— is another thing.
What ingredients must be in place for an organization to be able to continuously experiment, just like some of the best organizations in the world that you've seen?
Well, that's actually a big question. So what do you need in order to really live these principles? We argue the most important thing is you need a set of competencies; you need a set of skills on the teams that most companies that have not decided to work this way, they don't have those competencies.
You alluded to some of them before, but for example, you need engineers to play a front-and-center role. So if your engineers are outsourced, you're not going to be able to do these things. They're just not going to happen. I can't point to a single consistently innovative company that outsources their engineers.
In fact, I joke to CEOs sometimes that a good company would no sooner outsource their CEO than they would outsource their engineers. It just makes no sense. And so that's a whole different way for them to view these things.
Now, why is that? That's because the main source of innovation is our engineers. They're the ones that are working with the enabling technology, so they're the ones that know what's just now possible.
So, you know, that's one critical core competency. Another one that you often don't find in most companies because they really don't understand the importance of this is a professional product designer. They might have some graphic designers around, but they do not play this role that we need— a real product designer to do— somebody who really takes responsibility for the customer experience at every touchpoint with that.
And then, of course, one of the ones you mentioned— a real product manager, not a product owner, not a feature team project manager type, but a real product manager— somebody who is shaping the product right alongside with the designer and the engineers.
These product managers are very skilled in their customers; they're skilled in the data; they're skilled in how your business works in detail— like how is your product sold, how are they marketed, what's the go-to-market in general, how are they funded, how are they monetized, what are the compliance constraints, what are the legal constraints, privacy constraints? Who else on the team knows these things?
So they need a product manager as well. And then these cross-functional teams— once you have those skills, the other big thing that's needed is they now need to be empowered. The word we use is empowered, which means they need to be given the problems to solve, not just the features to build.
Then they can use these skills to go run these experiments and then figure out what works and then deliver it to our customers. So that's, you know, there's a lot there that needs to be in place, and none of those skills really happen unless you have good product leaders that know how to recruit these people and coach these people.
So if you had to point to one thing that really is missing from companies that haven't done this, it's probably the product leaders. Because unless you have serious product leaders, they won't assemble the teams we've been talking about.
I totally agree, and I really want to dig into product leadership just in a bit. But let's just dissect what you said. You've mentioned that what companies are missing is a set of competencies to test ideas continuously to be able to do so. And you've mentioned, of course, the role of the product manager, a real product designer—not a graphic designer. We're talking about a full stack, you know, service design, industrial design if it's hardware, UX/UI— a proper product designer.
And I have to dig into this one a little bit because, Marty, in Norway, we have a pretty decent design community. A lot of product organizations surprisingly have actually great designers— you know, great service designers and so on.
And sometimes, I bet it's because probably the whole way they organize themselves is more towards feature teams rather than empowered product teams. But sometimes there's this clash between who owns what because the service designer or a real product designer is incredibly competent to do discovery, and then they see the role of the product manager to basically risk viability.
But when it comes to value, they feel that sometimes, "Well, we are more than usability; we do more than usability; we are also responsible for value." But then there's sometimes a clash. What's your take on that collaboration? Because I know you probably have a lot of great thoughts on how great teams actually collaborate.
Yeah, and we're talking here about a real empowered product team. Not because you can have a similar symptom with a feature team, but that's not about value; that's just about the designer doesn't understand what the product manager is trying to do because they're not— they're just really a project manager.
But in your scenario, I think it's more interesting, which is it's a real empowered product team, and now you have a product designer and a product manager both focusing on and able to contribute a lot to value.
And by the way, this is what we call our favorite situation. This is exactly what we want, right? This is what we want. We actually want a little better— we also want the engineering tech lead to contribute, you know, feel real passion about value as well.
So the way it is, we want to make sure whatever we build is valuable, usable, feasible, viable. That's all. I mean, lots of engineers contribute to value in many ways. That's why often innovations happen from them. And of course, designers do— a lot of that value is delivered to the user through the user experience, right? It's literally coming through the experience.
So we love it when everybody takes responsibility. So when we say, you know, a designer is accountable for usability, what that really means is if the system is unusable, we're going to hold the designer accountable for that. We're going to be like, "Where were you on this? How could this happen?"
If a product is not valuable— in other words, people do not choose to buy it— the person we're going to hold accountable for that is a product manager. That doesn't mean that the rest of the team doesn't help, and we want them to help with that. But we have people who are accountable, just like for viability.
In fact, that's often where it's more of a problem. The product is something our customers absolutely value and love; the problem is it's got a legal issue or it's got a compliance issue. Whose fault is that? Well, that's the product manager's fault. They are supposed to know the viability constraints. It's not the designer's fault; it's not the engineer's fault.
So we're looking at accountability there. So we love it when all of them care about all of these things.
And the scenario you're bringing up— I'll be honest, it's more common in a B2C product than a B2B product. In a B2C product, one of the challenges with consumer products is that every user is a buyer. And that means that a lot of times, the designer is in a great position to help with value of the customer.
In a B2B product, it's usually not because the user and the buyer are very different people. And so the designer is in a good position to help the user get value, but they often don't even talk much to the buyer. The product manager is doing that.
I see.
So, let's go back to the principles, Marty, just to explore a little bit more some of the 20 principles you wrote in your latest book. I particularly wanted to dig into "Innovation over Predictability," which I love because, again, a lot of the organizations in Europe that I see organize themselves around projects.
So how is this principle, "Innovation over Predictability," valuable for an organization running projects? Why is it important for them?
Well, in fact, the whole move to the product model— a lot of people just describe it as moving from projects to products or from projects and output to products and outcomes. That's really what's going on.
That's not unique to Europe, just to be very clear.
It's a global problem.
The truth is, it's a global problem because it's a lot easier to tackle predictability. It's a lot easier. And unfortunately, where it falls apart is when you look at the success of typical projects. Depending on which industry experts you want to listen to, it's somewhere between 70 and 80% of those things built in projects don't deliver the value that they were promised.
So we know it doesn't really work. Why doesn't it work? Because predictability is not the hard part. Now, we do want predictability; that is a desirable thing, right? If we're building something for our customers, they kind of need to know often when that's going to be there, especially if they have to plan for it.
But predictability is time to market; outcomes is time to money. And what we really care more than even predictability is time to money.
The irony is the project model is so inefficient that we can usually get both time to market and time to money faster if we do the product model than if we do the project model, just because there's a lot of inherent inefficiencies of the project model.
The people who build the thing are building it for one shot; they rarely are able to do the many iterations that we need in order to get it successful. And of course, in the product model, that's the basis— you own this and you continue to improve the outcomes.
And there's technical debt issues that happen more with the project model, and there's no accountability in the project model. There are all these issues, and those are pretty well documented— the issues with the project model.
So it's just that I think most of the world understands the problems in the project model, but they don't know that there's an alternative. And so, you know, we're trying to share that there's a much better way to do this, and the good companies have been doing it differently for many years.
Love that!
So I think some companies, they're not aware of an alternative, and other companies, they read your stuff, and it's very inspiring, and they hear you well, and they want to transform, but they just don't know where to begin. Right? That's why the book "Companies"—
Exactly, precisely!
But so just very shortly, for an organization that has been running projects for many years and they want to transform, they need to subscribe to a lot of different principles and change the way they see the world. But what would you say are sort of the most important things, apart from getting the competencies that we talked about in the beginning? What else should they focus on to really transform to a product operating model?
Well, probably one of the biggest challenges for the senior leaders is that when you look at something like agile, they don't really have to worry about agile because that's something that the IT organization does, and they either do it well or not.
But the senior leader is like— it's like something that IT does in the— if you move to the product model, it's not like that. It impacts the entire company. It impacts sales, marketing, the CEO, often the board. It impacts compliance, legal, HR.
And so there's no sort of delegating it to say a chief digital officer or a chief transformation officer. This is something the CEO and the senior leadership team have to decide they want to change the way they work.
And because it impacts the senior leadership team, that is a much bigger and more disruptive undertaking.
So, but then you— okay, so you talked about agile, and a lot of these senior leaders, they think agile will be the answer to some of their problems, and they invest a lot of money on the so-called agile transformations and agile process implementation because they believe that it's going to bring them better outcomes.
And you know, they bring all these agile coaches and, you know, very well-intentioned people, but then after a year or two, the outcomes are not necessarily what they expected. What do you think the problem is? Where do you think— do you think these investments in these agile transformations are valuable?
Do you think this is a problem with senior leadership that they need to just think completely different about what they actually need?
Yeah, well, there's sort of two levels to this situation. Let's talk about agile. The first level is it is important that the senior leaders understand the changes that agile can bring. I mean, it doesn't— we'll talk about why even these benefits often don't come, but if you do it well, there are real benefits.
But what they don't understand is those benefits don't even attack the biggest parts of the problem. They attack basically one-third of the problem. We talk about when you transform, there are sort of, at a high level, three big things you're tackling. Agile helps you with this first one— changing how you build, how you build, test, deploy.
The second one, though, is how do you solve problems? Agile doesn't help you with that at all. And the third one is how do you decide which problems you want to solve? Agile doesn't help you with that at all either.
And these three— the truth is the first one is the easiest of the three.
Now, it doesn't even address the bigger two. Now, that said, the first one is still really important. And 20 years ago, when agile was first becoming popular, more companies were getting real benefits from agile because fundamentally agile helped us change how we build, test, and deploy in order to be much more responsive to our customers and actually have much better quality and velocity.
But it was all based on principles. And over the last 20 years, one of the things that changed in the agile community— and not all of them, thank goodness— but unfortunately many of them, and I have to say many of them in Europe especially, they decided to take agile in a different direction.
They took it in a direction of process and a direction of predictability, and the result is they are not getting the benefits of agile. The easiest way to see that is most of them are releasing once a month or worse, once a quarter. If you're doing that, you're not getting even the most basic benefits of agile.
And it's just agile theater; this is just waterfall with a marketing name of agile, and that's unfortunately what's happened.
Who do you blame for that? I really blame the agile coaches in the community and the industrial complex— all of these certification programs and everything that are just BS. We all know they're BS; they know they're BS. But they are, and it's a shame because agile really can deliver real benefits, but those are the agile principles, not the way the processes have been formalized.
And unfortunately, this has happened to way more than agile. This happened— if you remember Six Sigma before agile, there were great principles there, but a lot of process people took over Six Sigma and applied it in ways that made no sense, and it just destroyed companies.
So yes, I think the whole— today, the way most companies do agile with agile coaches and product owners that have been trained by people who have never done product before and all the rituals and none of the results— it's ridiculous.
And you know, I've been calling that out for a while. That's not the way it needed to be.
So if you're a CEO, though, and you feel like, "All right, I was sold a bill of goods with agile. I thought it was going to solve all these problems, but now you're telling me it only solves one-third of the problems, and furthermore, the people we hired were not even good ones to do that third."
And so there are a lot of CEOs that are justifiably unhappy about this, and I think that's why you're seeing a backlash.
Yeah, yeah, absolutely.
And I mean, you mentioned something very interesting, which is whenever you have these movements, you have process people take over.
Yeah, they can— if you're not careful, see—
Yeah, they can, of course.
So, and this has happened with agile to some extent, and I'm just thinking about product ops. You know, it's a slight— it's a slight divergent in our conversation now, but what I'm afraid is that there's a very thin line with product ops becoming yet another sort of process mentality and governance and so on.
Just like we've seen with agile, you see product ops departments that they are now starting to— some of course, not all— but some just taking over process and standardization and healthy standardization and governance.
And there's a new book out there as well that also discusses this, and I think for someone reading "Transformed" and reading some of the new latest books on product ops and seeing what some companies are implementing, there's a bit of mixed signals there as well.
Yeah, it's true. I mean, this product ops is still very early, though. It's very early. And unfortunately, I have seen some companies that define product ops just the way you defined it, and that's a problem.
It's the same problem, really, but it's a problem. And the good news is I've also seen companies define product ops very differently, which is very helpful in my opinion.
But it's not— it's a very different definition. It's a tricky one because, you know, product ops is just the same idea conceptually as devops and design ops. But product doesn't really have that need in the same way, so it's kind of this placeholder, and different people and different companies have kind of filled that definition themselves based on their goals.
And so if you're looking for process and governance, yeah, that can happen. On the other hand, one of my partners, Chris Jones, was telling me about a company he met where they brought in a product ops person— one person— who views it as his job to spread the product model around the company, which is all principles.
And he was like, "That's awesome!" And I said, "Yeah, I love that too! That's awesome! I wish more companies would do that." In other words, product ops doesn't have to be a process enforcer; they could be principle enablers.
Exactly! That would be great!
Now, of course, that's what the managers, the leaders are supposed to do too, but having, say, a very experienced product person like a principal product manager who's there to help share those principles— love that!
So there can be good definitions of product ops; there can be others that are just— one of the ones that I'm worried about is nothing to do with process, nothing to do with process at all, but I don't like it, which is there are some companies that have a definition of product ops which is instead of having a product manager and a product owner, like you talked about and like SAFe has— that nonsense— well, they have a product manager and a product ops person doing the same low-level stuff.
And their argument is the product manager has too much work to do, so we'll give all the little tasks to product ops, which is, you know, it really does bother me. We've got so many people in the world who think product managers— they don't even see the value in them.
And then you have some product managers saying, "Oh, and not only am I not valuable, but I have to have all these other people helping me," even though developers don't have— devops doesn't mean that every developer has somebody assigned to do their dirty work for them, right? And designers don't have somebody like that.
So it's, you know, that's a little bit of nonsense as well.
So complicated! But today, the definition of product ops is not uniform. There are too many different definitions.
So I have strong opinions on each definition, but the first thing I need to know is which definition is it— one of the good ones, one of the bad ones, or is it one of the ones that really don't matter? It's just a name.
Absolutely! I mean, I think this is a problem in general, not just with product ops, but the fact that there's a term that is coined, and then there's so many misinterpretations, and then there's a load of— there's a notion of people that go out to spread their message that is not sort of the good definition, like you talked about.
And then junior people, you know, becoming product managers or wanting to be a real product manager for the first time, they go online and they read all this madness— all these definitions that what a product manager actually does, and then you see it's a product owner responsibility.
So that's an issue, and I'm a bit concerned with that becoming a trend for product ops— like more and more people spreading the bad definitions of it.
I don't know how that's— it's sort of the nature of the internet.
It's very hard to, you know, it's hard to know what to do there.
Yeah, we'll just have to let things play out probably.
At least you're being spicy about it, Marty, and I love that you're spreading the good definitions to a lot of people, so that's a great start.
So back to the three main things that organizations need to do. You talked about, you know, agile helping you potentially with a third, and then you talked about the two others that are much more important— particularly which problems to solve, which is related to product leadership.
And I wanted to dig into that a little bit. I want to dig into this because I don't see a lot of true product leaders out there. And you've mentioned that there's a lot of misinterpretation of the role of a product manager. I think this is even worse for product leaders.
I think the definition of what a great product leader actually does is not there for many people. So let's dig into product leadership in general.
You've written that a product leader managing a product team or leading a product team spends around 80% of her time coaching and staffing. Can you please elaborate on that?
Yeah, first, some probably terminology. We use the term product leader as short for all the managers of product managers, product designers, and engineers. So we say product leader just because that's a lot less words.
But normally, the product managers report to a director of product management, the designers report to a director of design, and the engineers report to a dev manager and an engineering director. So they are getting this product leadership help from their manager.
Now, the other thing to talk about when you talk about product leaders is first-level product leaders, which is managing an individual contributor like an engineer, designer, or product manager, and then higher-level ones, which are more managing managers.
What that was referring to— what you cited— was first-level managers, people managing individual contributors. The primary job for those people is to coach and develop their people. That's how almost everybody who's good learned the craft of product. Certainly, how I learned the craft of product— most people I know, that's how they learned it. They worked for a manager that knew how to do the job and was doing their job to coach you.
This is referred to as coaching. It's like at Google, for example, the number one attribute of their managers, as rated by their people, is the manager is viewed as a good coach.
Like Bill Campbell used to say, you cannot be a good manager today without being a good coach. So this is what you're doing— you're helping your people learn how to do the job.
Once— that's why 80% of your time is staffing and recruiting— sorry, staffing and coaching. Of course, the better you do at staffing, the easier it is to coach, but that's your job.
The other 20% of the time is on product strategy, on product vision, and sharing that with the teams. But as you go higher, to say chief product officer or chief technology officer, it's really reversed. Only about 20% of your time is in coaching and staffing, and the rest of your time is the product— the strategic context because you're responsible really for the product vision, the product strategy, the team topology, the objectives.
In other words, the problems to solve. So what I just described is what I would argue is normal in strong product companies. That's just how— that's what I see.
On the other hand, if you're a feature team company, it's a completely different game because in a feature team company, the feature teams are set up to serve the business. So the job of a product leader is really to staff this— it's like an agency. You're staffing teams who can serve the business.
What does that mean? There's really no product vision to speak of in those companies. There's certainly no product strategy. You don't have those things because they're not empowered product teams.
The coaching is a lot lesser responsibility. You're there to build what you've been told to build. So it's a completely different job, and I would say the person who has the biggest change when you move to the product model are the product leaders.
That's very interesting. Back to our first part of the conversation— this is where most organizations, at least the ones I've seen, that's what they lack the most— is true product leaders.
And they might have those product leaders entitled, you know, directors of product, even a CPO, but what they're doing is, you know, they're not spending any time coaching their teams.
And so what they're doing is basically managing the portfolio of the projects and being the ones accountable for the business results, not the teams, right? So it's a complete different model and different job, as you mentioned.
And they're not really taking responsibility for the business results because they can't. They're really just the stakeholders are the ones defining what's getting done.
But, you know, I would say in that scenario, which is very common all over the world, a company wants to transform, but the product leaders have never done this before. They never worked this way before.
This is why we talk a lot about product coaches. Because you can either replace your product leaders with people who know how to do this, and that is what some companies do, or you can bring in a product leadership coach to help those product leaders learn at the same time their people are learning.
And the truth is, in preparation for this book, over the last two years, we've been building a network of people we could recommend. We have a long list of coaches in Europe and in most of the world today.
And we don't have any financial ties with any of them; we just wanted to know who are the good coaches out there, who are the ones that have done product well that we could introduce to a company.
And we're still finding more all the time, but today we have a good set of people in most parts of the world that we can say, "This person, if you spend a couple of months with this person, they can show you what you don't know and help you through it."
In fact, a lot of the transformations you read about in the book, that's what made them work— is a product coach that helped them for the first few times.
Absolutely! I talked with Gabby and with Hope a few weeks ago.
Oh, good! Well, they're perfect. They're excellent examples of product coaches.
Absolutely!
So just to summarize, Marty, what you said— one of the most important things for companies to transform is to change how they decide which problems to solve, and that is a core product leadership responsibility for most product organizations.
There are basically feature product organizations with feature teams; they lack that. They may lack that role— perhaps not in title, but in actual role, they may lack that.
And one way to solve it is either recruit an actual product leader or get external help from product coaches. Is that correct?
That's right!
Great! Is there any particular skill or competency that CPOs must have that is very different than, for example, a director of product?
Oh, well, sure! But it's the same as a CTO from a director of engineering. You know, as you get higher in the organization, you have more on your shoulders, more responsibilities, more of the strategic context is actually coming from you.
So a CPO is the top of the product line, and a CTO is the top of the engineering line in general. And so those are the people that are most critical.
In fact, we tell companies that want to transform the three people that really you want to make sure are working together as they need to is the CEO or the general manager, if it's a business unit, and the CPO and the CTO. Those three are the ones that are either going to make it work or not.
So basically, if you have a CEO that is not subscribing to the principles that you write in the book and that is incredibly feature-oriented and, you know, top-down and so on, are all of these product people doomed? Or can they do a lot to push that information forward?
Well, what you're describing is a situation which is pretty common, which is one or more of the senior leaders are not convinced, right? They're just not convinced.
So they know what they know, but they don't know what else there might be. So the job of the product leaders is to win over the hearts and minds of these leaders.
The way they do that is by showing them what's possible and earning their trust. So you could— they could just say, "Oh, well, my CEO doesn't get it, so I'm going to leave." And some of them do that.
But I always encourage them, "Look, the CEO doesn't get it probably because the CEO has never seen it." And they are— do you expect somebody who's never seen it to just say, "Okay, I'm giving you all this control, and hopefully it works out well?"
Most CEOs are not going to do that. What they'll say is, "Okay, I'll give you space to do a test, an experiment. If that works, I love that; we'll talk about expanding that experiment. If it doesn't work, though, I have still protected the company from what might be a bad direction."
They don't know. That's how we prove this stuff. You start by showing small, and then you earn the right to go bigger.
I explained it recently to one of the CPOs that I was coaching, and he seemed to respond well. The way I explained it is it's kind of like a multi-level game where you start by playing level one, and once you've finally shown you really know level one, you get entry to level two.
And then you get to show— build your skills, and you're good, and then you get entry— you've earned entry to level three. It feels a lot like that. You're earning trust every way up, and you can start with a product team— a single product team.
Absolutely!
And of course, having a strong CPO really helps, or a product leader in general.
Absolutely!
You mentioned something that is very important: the strategic context is owned by the product leader. That person is crafting a product vision, inspiring everyone, convincing people, leading with that vision, crafting the product strategy to make that vision a reality, team topology, all of that jazz— team objectives.
And one of the counterarguments that a lot of people would say is, "Well, product strategy should be owned by the team because they are closer to the insights." So that's kind of one of the counterarguments that I hear the most— countering the argument of strategic context is owned by the leader.
So how have you seen in some of the best organizations that you've observed, how do they close that loop of the insights coming from continuous discovery towards the leader to, based on those insights, continuously craft the strategic context and communicate it back again?
Yeah, how do you close that loop? And this, by the way, I do— because I have heard so many agile coaches basically recommend that, so I think that's where this comes from.
But if you think about it for even five minutes, it makes no sense. Think about that. First of all, we should say product strategies that the product leaders own that is informed by insights that come from product teams. So that's no question.
But think about it this way: a typical medium-sized organization, not even a big one— it's worse for a big one— say they have 30 product teams. Do you really want 30 product visions and 30 product strategies?
The whole point of product strategy is to make sure your organization is pursuing the most important problems. How can each team decide that? How is that even possible for each team to decide that?
First of all, they don't even have visibility to the whole holistic view. But even if they did, you would get 25 interpretations, and you're not going to— you know, all they're doing is picking what they want to do as opposed to what are the most important opportunities to pursue.
So what I think is going on is these are organizations where they have no idea like what really goes on in a product company and what the strategic context is. Otherwise, these agile coaches would never be recommending this.
It just is nonsense.
Now, the whole idea of an empowered team is they are given a problem to solve, and the team is able to figure out the best way to solve that. And there is a kind of strategy— it's a discovery strategy, how are you going to do that? A delivery strategy, how are you going to build and deliver this?
So there are still other forms of strategy, but product strategy comes from the product leaders, just like business strategy comes from the senior leaders.
The site, for example— are you going to sell internationally? That is a business strategy decision that doesn't come from the product leaders; that comes from the CEO and the head of sales and the head of finance.
Are we going to sell our products internationally? If they decide yes, then that probably does impact the product strategy because, for example, certain kinds of products— say products that are very successful in the U.S. can be big failures in China because there are very different ecosystems, very different culture in China.
And so you may need a completely different product strategy for that. Does that make sense?
Makes total sense!
And I, you know, I've written about this as well, and I think the biggest point that people miss is, you know, they go online and they see— they read about the role of the product manager and the role of product owner and so on, and product strategy is part of that role.
Even in some of the most sort of well-known certification schools and whatnot, they talk about this, and they don't even address product leader as a role because in these organizations, they don't have these people.
Yeah, it was actually funny because I wrote a post that went completely viral— like 1 million views type of post— that just mentioning the differences that you just highlighted on product leader versus product team.
And a lot of the comments were stuff like, "Why are you inventing a new agile role?" You know, comments like this. It just makes you really reflect on, "Okay, well, so that's where you're coming from."
You just don't— they don't even know the existence of the role, and that's the brutal reality.
A lot of the problems with the agile coaches, they don't even know what they don't know because they've never worked in a product company before.
And I really think this is unintentional. Like, I don't think these people are malicious; it's just that they are out there teaching what they think is a process, and all they're doing is spreading bad practices.
So how can an agile coach learn the craft of product to, in consequence, help the organizations more than what they are doing today? Marty, what do you think?
Well, first of all, communicate— I mean, if an agile coach can't actually help the engineers learn how to do something like continuous delivery, then I don't see them with much value at all.
At the minimum, they should be able to help the teams with the kind of test and release automation needed to do continuous deployment, at a minimum. If they can't do that, that team might need a real delivery coach to help them with this.
But there are several agile coaches that are experienced engineers that can help with delivery.
So you want to make sure that your contribution is real; there's something real there, not just, "Oh, we're looking at the team dynamics." That is not enough, and also that's what the managers are doing.
That is not enough, and the managers need to be doing that in order to coach their people.
So the other thing I've recommended to product— to agile coaches is go work at a product company, even for a few months, even if you have to volunteer there, not to bring them anything, but to learn how product really works.
And then you can help a lot of others. And I would encourage them to think of agile back to the core manifesto principles and just realize if you're teaching something like SAFe, this has nothing to do with the agile principles.
Nothing at all!
I totally agree!
So, Marty, very, very quickly before we wrap up, let's just very quickly discuss the future of product management. There's, you know, a lot of debates and trends, and I know that you have some opinions on the impact of AI on roles like product owner, actually.
The— how good AIs are becoming when it comes to automation and basic tasks that product owners would potentially do. So what's quickly your take on the impact of AI in the world of product management?
Well, that's an hour topic, really, of the impact of AI because it can certainly help. First of all, AI helps us in the products we build, but you're really asking how can it help us as we build?
And that is how does it impact the roles? It's certainly already impacting the engineering roles, and it's starting to impact the designer role, and I think it'll also impact the product management role, starting with the low-lying fruit.
And I do tell people— because I have a lot of friends that in the U.S., it's pretty rare that somebody has called a product owner. Like, that's a European thing because that was meant to be a role, not a job.
So it's a role that a product manager plays, but in Europe, a lot of people, that's all they are— is that role. And I tell them, "Look, just for you and your family, you should protect yourself. You should raise your skills so that you're not just so easily replaced."
I shared with— I've been sharing this; it's even though it's very depressing— but a CEO of a company in Europe that had 200 product owners. I met the CEO, and the CEO told me that he was pretty convinced that he could remove all 200 product owners, and nobody would be sad; that they wouldn't miss it.
You do not want to be in a role where the CEO believes that. And the truth is, it's hard to argue because do we really need that? Most of the engineers don't think it's needed; most of the designers don't think it's needed.
I think they're right. If that's all you have is agile coach-trained product owners, you could use the money better probably on engineers and designers.
So that's not good. You want to protect yourself, so you want to upskill. And that means moving, you know, building your skills from a product owner to a product manager.
And you can do that. I mean, there's no reason not to. I know countless people that have done that, and you can even do a lot of it just on your own. Books can help; there are courses you can take, but just do it!
Absolutely!
Yeah, and your books can certainly help. And I was just— you know, generative AI is going to impact other things. It already is impacting product strategy— sometimes for good and sometimes not for good.
It just depends on people are learning better ways to use things like ChatGPT to help them with their job. But, you know, I'm pretty convinced it's going to impact all of us, and I'm just hoping it's the good way.
Absolutely!
Marty, unfortunately, I would talk for hours, but we don't have more time. The usual closing question is, where can people find you? But I mean, Marty Kagan— most people know where to find you.
But are you in a new space that people should know of, or are you more active in a particular space that people should know of these days?
Well, I've given up on Twitter, so I'm not there anymore. So it's just LinkedIn is the last social media site standing. And then SVPG.com— that's where we publish all our stuff.
And so, yeah, feel free!
Amazing!
Marty, thank you so much for joining us. It was a real pleasure talking with you.
Well, thanks for inviting me, Alonzo! Good luck!
All right, that was it for today! I hope you enjoyed the episode. Make sure you subscribe to my newsletter so you don't miss out, and see you next time! [Music]