#1 Marty Cagan - Transformed: Moving to the Product Operating Model

Speaker A: Welcome to the Product Masterclass podcast. In today's episode, we sit down with Marty Kagan to dive into his latest book, Transformed. We will explore how companies can successfully shift to a product operating model. And we'll also discuss what inspired the book, practical solutions for CPOs to drive transformation and the critical role of CEOs in driving changes. Marty shares insights on balancing top down versus bottom up transformation and how individual contributors so PMs NPOs can influence their organizations. We will also discuss the impact of AI on product teams and touch on the differences between European and American companies in navigating transformation. So tune in to learn how to win hearts and minds in your organization and lead meaningful change.

Speaker B: And here we go. We are live with Marty Kagan. Welcome, Marty.

Speaker C: Thanks very much, Thomas. Good to be back with you.

Speaker B: Yeah. Uh, or good morning, so to say. Right. It's, uh, you just said it's 8 o' clock in the morning. We have here four, uh, o' clock in the afternoon. It's great to have you back. And Marty, you just released a new book publishing date today. How does that feel if you stand up and the book is out?

Speaker C: Yeah, the book is out. I just, it's funny because, um, you know, usually the public, usually American companies release in US first and then Europe later. In this case it was released in Europe three weeks before the U.S. so, uh, it's only today that, uh, most Americans got a copy. So that's, that's fine.

Speaker B: Yeah. Uh, I just had one, uh, guy from India complaining that, you know, like, uh, that the book is a little bit late in India. He, he would prefer if it's first shipped in India. So next time maybe. Okay.

Speaker C: Okay.

Speaker B: Uh, Marty, I just, you know, like, I don't need to introduce you. Everybody who's in, uh, watching, I guess knows you because you just, you know, like, you shaped the picture of product management in the last, um, years and the last, uh, century. Um, 10 years, 20 years, 40 years. Yeah. You worked 40 years in product management. Right. I think Inspired.

Speaker C: Yeah.

Speaker B: You wrote in 2008, if I'm correct. Right. It was for product manager and discovery. Then you moved up the level with empowered, uh, uh, on team level. Right. And now Transformed, what, um, is it, you know, like, what is the main idea, you know, um, with transformed? What, what do you change, Want to change in the world with this book?

Speaker C: Yeah. Transform was different. It's a little different. The idea was, well, like you said with Inspired, we wanted to share the techniques of discovery and product teams and it Empowered. We wanted to focus on product leaders. And the good news was a lot of people told us they really liked the books. That's good news. The bad news is they, so many people told us that, uh, they didn't think it was possible for them to change. They just thought. They just said, if you saw our company, I can't tell you how many people say, if you saw our company, you would know it's impossible for us to change, to work this way. Our managers, our leaders, our company, we're just never going to work that way. And, you know, we've been working with companies for 20 years. Mostly that's what we do is, uh, help them change. And so we knew that wasn't true. But what we wanted to do was prove it and show people how to change. So the other books are really about how to do product. This book is how to change so that you can do product well. And we wanted to both show people real case studies. And by the way, one of the things that I think is special about this book is, unlike the other ones, all the examples are outside of Silicon Valley. So they're not Silicon Valley. We did because it's, you know, most Silicon Valley companies are born in this model. But, uh, but that's not true in a lot of the world. So what we wanted to do is show companies that literally changed. Uh, you know, we didn't want to hide the fact that it's hard because it is hard to change, but we wanted to show that it is possible. And then I think the most important part, uh, is you. We wanted to show what those companies were able to do, do after they transform, so that the level of innovation is. And so the book highlights companies all over the world, uh, you know, in, uh, several in Europe, several. One of my favorites in Saudi Arabia, which is not known as the tech hub, but just did an amazing job in healthcare regulated industry, in B2B SaaS, and all these areas that so many people think it's not possible. And we wanted to show it is possible.

Speaker B: Yeah, Marty, I prepared a lot of questions to understand how you do the transformation. But uh, first, you know, like, um, let's have a short overview, uh, of the book. The content. I think, you know, the, the core of the book is, uh, you laid out three dimensions. You have four competencies and you have 20 principles. Yeah. So let's just go quickly through it, the three dimensions. Can you just give a quick overview, um, what's in there?

Speaker C: Well, first of all, the reason we did that, another difference between inspired and empowered in this book. Is inspired and empowered were just written for people like you and me, right? Product people, uh, engineers, designer product managers, product leaders. However, Transform was written for anybody in the company, from the CEO to the head of sales to the head of finance to marketing people, to the people on the product team. So we needed to try to describe how good companies work in a way that the whole business could understand and help. And so the tech, we don't cover the techniques, but we do cover the principles. And that's what you're getting at. And that's referred to. We also needed a name for this and we selected the product operating model. We didn't come up with that name. Other people did. We just wanted to, uh, we wanted something that was um, a, ah, conceptual model. It was neutral, it wasn't a framework or a process. So anyway, the way we. At the highest level, at the very highest level, it's actually just about moving from output to outcomes. That's the very highest level. Uh, and you've all, everybody's heard that for a long time now, moved outcomes. That's not new. What's new is how do you do that? Because that is much easier said than done. All right, so how do you do that? That really means changing. In most companies, it means changing three big things. The first is how do you decide what to work on? How do you decide the most important problems to solve? What are the opportunities to pursue? What are the challenges or threats to address? That's what most companies call product planning. Uh, but how do you decide which problems to solve? In good product companies, they do that differently. It is primarily around product strategy. So that's the first area. The second area is how do you solve those problems? In most companies, uh, that have not moved to this model, they have feature factories and feature teams. So the teams are given roadmaps of, uh, features and projects and they're just asked to design and code them. And moving to the product model, that is very different. That's the difference between a feature team and an empowered product team. That's the difference between product design and product discovery. So product discovery is uh, the heart of changing how you solve problems. And then the third big dimension is changing how you build, test and deploy your solutions. So if you want to prove outcomes, you need to be able to have everything instrumented, all the analytics, all the telemetry, all the monitoring so that you can show the, that your new change is delivering the outcome you need, uh, you also need to take care of your customers. And so these are the reasons why, uh, we change how we build. Now this is sort of a messy one because this was supposed to be the reason companies moved to Agile. Uh, but as you probably know, a lot of companies think they're agile, but they're releasing once every quarter and you keep. And, um, even once every month is not Agile and it's not helpful. So we had to be more clear about what does it really mean to change how you build. And so those are the three things at the highest level, changing how you decide what problems to work on, changing how you decide how you solve those problems, and changing how you build and deliver those solutions. Okay, so if you double click on that, how do you do that? Well, first of all, it requires four new competencies that in most companies that have not transformed, they need to develop these competencies. Now there's another messy one because most companies think they have these people already because they often have these titles, but they don't have these jobs. And what we're talking about is serious product managers, not feature team product managers, but serious empowered product managers, professional product designers and professional engineering tech leads. Uh, and then the product leaders that are responsible for developing these people, those are the four new competencies, you know, at a very high level. And then of course, what do those people do? Well, they do product strategy, which I mentioned. They do product discovery, they do product delivery. So those three things are kind of well known. They also are really fundamentally about creating good product teams and establishing a good solid product culture, which is really about how you make decisions and how you empower people. So those are the, uh, concepts, those five critical concepts. And then stop me anytime because I could go all day on this. But, um, the next level is when you look at these concepts, what they really boil down to is a set of first principles. And this is what I think is most important in the product model. Because anybody who's ever worked with, say, a company like Apple and a company like Amazon, they're very different in culture. However, they're very consistent in the principles. So to me, what's important is the principles. That's why there is no one good way to do product. There's many good ways to do product, just like there's many bad ways to do product. Product. What matters are those principles. So, uh, and there are 20 principles that we go through in the book. I won't try to explain all 20 minutes here. An example of a common product principle, an important product principle is the, the need to embrace experimentation. Most companies don't do that, actually. They don't experiment or when they do, they just do these trivial little optimizations. Like, we'll try changing this color to blue, and we'll see how it does. That's not really an experiment. That's not what we mean by an experiment. We mean trying something much bolder. Uh, and so that's product discovery, course and the skills to do. But that's a principle. One way or another. Whatever techniques you want to use, you need to embrace experimentation. Uh, that's, um. I mean, I, uh, could keep going. There's principles array, there's principles around culture, there's principles around delivery, there's principles around all that. But that's what's important. And that's the first. That's really the first half of the book is to describe what it means to work this way. Second half of the book, since you asked, the second half of the book is how do you change? How do you move to this model? And we shared what we do, um, and have done for a while. And for us, it starts with an assessment. And we shared our actual assessment, the questions we use. So you can do this yourself. You don't have to, you know, do this yourself, and it'll take you a little longer, but it's worth doing. And I think there's no reason people can't do it. And then you can understand, because if you want to transform, first you need to know what you're transforming to. And that's what we just talked about. But then you have to know what you're transforming from. You have to know where you are right now. And every company is somewhere different. And so the assessment will tell you where you are. When you have that assessment and you have the destination, then you can prioritize your work and you can say what's most important for this company now. And that leads to a transformation plan, and then that leads to a whole bunch of techniques to help you transform, depending on where the areas you need to transform are.

Speaker B: Excellent.

Speaker C: Um,

Speaker B: I looked up, uh, who's in this call today, and we have a lot of product leaders, about a third and, uh, product managers, and then we have adjacent, um, roles here. You've been talking on our conference last year, and, um, we had a lot of conversations. And let me paint a picture of where I think a lot of companies stand today. Right. And let's just take a product leader, maybe somebody who's listening, um, to this conversation. Many of them said, told me a similar story. And it goes like that. They all read your books, you know, they know how to do that. And the tech and product team are actually enthusiastic to work like you described that. Right. And they try it. Yeah. And it's almost like a bubble, right. Where they try to apply, um, your thinking, but the world around them, the rest of the company, they have just a different mindset and it's mostly project driven. Right. The hand over what they need is need, uh, to be done right. They give them feature requests and it's just total different mindset.

Speaker C: Yeah.

Speaker B: So what do you tell those people how to start the transformation?

Speaker C: Yeah. Well, first of all, you just answered your original question. That's. You said it better than I did. That is exactly why we wrote the new book. Because I hear what you hear. I've been hearing that every day for more than 10 years. Virtually every day. Uh, so that is very normal for people. Uh, it's just very normal unless they happen to already work this way. And then they say, well, we're already doing this, but if they're not, this is the problem. And so the, you know, I mean, I'm not trying to sell books right now, but the reason we wrote this was to answer your question, just literally right there. And so we said, well, okay, let's talk about how we think you should go about this. Because this is what's hard. What you're really. If you look between the lines, Thomas, what they're pointing out is that it's not really that hard to change the product people, right? The designers, the engineers, the product manager. The hard part is changing the head of finance, the head of sales, the head of marketing, the CEO, uh, the legal officer, the complex compliance officer. And that's why transformation is hard, because it impacts the whole company. It really does. There are very few people that are not impacted in a transformation. So that's why I was saying, that's why we had to describe that in a way the whole company can understand. But let's talk more generally for a minute because a lot of those product leaders, they think, I mean, uh, what I'm sharing right now is very similar to the kind of one on one coaching that I do with product leaders. And they'll say something like, my head of sales doesn't want to do this. My head of CEO doesn't want to do this. They don't want to change. Uh, and so what I. And they're like, my hands are tied. I can't, you know, I can't do that. And I spend time showing them you can do much more than you think you can do now. You have to earn that trust. You have to show the leaders, you have to show the head of sales that you understand their situation, you understand their customers, which are also your customers. You have to show the CEO that this is actually a more effective way of working. So I try to encourage those people to show what they can do. You can earn every level here. Here you can even start as an individual contributor and start showing your manager what you can really do.

Speaker B: M m. Let's stick for a moment, um, uh, with the product leader. So what I hear typically is, okay, I could approach my CEO but you know, like having such a huge, you know, one off, um, thing that maybe there is not enough trust. Yeah. Influencing the people are, which are on the same level, like marketing, sales, whatsoever. You don't have the authority to tell them what, what, what to do. Right. It's different with their own role, you know, like, okay, help the product manager, uh, in their division. Yeah, but that's typically not the solution. Right. So what would you suggest? You know, go to same level people, try to nudge them into the product model or go through, um, the CEO and you know, bring it downwards or like, like what's the best strategy from your experience?

Speaker C: Right.

Speaker B: How to, how to do that? Right.

Speaker C: It's a good question. Well, first of all, I should say I don't think there is one answer to that because it depends on a lot of things. It depends on the size of the company that makes a big difference. In real big companies, we recommend you do division by division. Don't try to do it all at once. With small companies you can be much more aggressive. Um, but let me just say there are many techniques. And I said half the book describes techniques. However, there is one technique in particular that we recommend more than anything else, which I think is the more direct answer to your question. And that's a technique that's called piloting technique. By the way, we didn't invent any of this. Uh, this stuff has been around. We're just sharing it. Uh, pilot teams mean, let's say you've got the scenario you described. The company is skeptical. They don't want to. And they're right, by the way, to not want to just switch all at once. That is a very dangerous thing to do. Uh, it's risky because you might actually hurt before you help. You don't want to do that. So what we recommend is pilot teams. What that says is that you go with your colleagues and say, look, um, do we believe we need to transform? Most of the time the other leaders do believe that things need to get better. It's either a competitive threat or financial rewards. Whatever it is, there's some reason they say, okay, let's do an experiment. Let's try this for one or a small number of product teams. Let's see together how well this works. If it works well, we can spread it around, we can grow to more teams. If it doesn't work well, we can either try again with a different approach or maybe, maybe that's not for us. So, uh, a pilot team is a safe, non threatening, low risk way of trying out these things and letting your sales organization decide, is this better than what we had or not as good? Uh, letting your marketing people, your everybody in the company observe. So that's our go to technique. There are lots of other variations of that. Like we can do pilot teams for each of those three dimensions so that each group is, each team is working on. So there's a lot more variations here. But the most important concept is you don't have to try this out for the whole company. You can try it out on just a product team, which I think in general is the smart thing to do.

Speaker B: Yeah. So basically you suggest, um, an experiment to your peers on the same level and say, okay, let's try whether we can have a better solution and more satisfying working, uh, culture, um, around us.

Speaker C: And the results, most importantly is, uh, because you can make the work culture argument, but most of your stakeholders will not be sympathetic to that. The real argument that works for most stakeholders is the outcomes outputting. Right. They want business results. If you can show them that they get more outcome for the money, that's what speaks to most stakeholders.

Speaker B: At the end of the day, it all comes back to the purse. Right.

Speaker C: I mean that's just the way business works. So, um. But you know what's interesting is I find this is true in nonprofits as well. Nonprofits, absolutely. I mean they have even less money, so they care about getting real results for what they spend.

Speaker B: I think, uh, the difference between a business and a nonprofit is 10% profit margin. The business takes it for themselves and the nonprofit just distributes it and makes a service cheaper. But you know, and inherently you need to have a valid business model. Otherwise it never works. Otherwise it's just, you know, giveaway. So let's double click on the um, on that thought. Right. Have one team run because like, there is a lot of structure in place which makes that hard to do actually. Right. We have a annual planning and stuff like that. Right. You have a lot of structure and um, changing a company Always means changing people. Right. If I'm used to hand over the product team a solution which I require for 10 years. Right. It's hard to adapt, um, um, with this sample, um, or test team. Right. How do you facilitate that or how do you do that?

Speaker C: What.

Speaker B: You know, like.

Speaker C: Yeah, well, you're spot on. What makes it hard is the people. Uh, right. You're. You. We're talking about a change management process for a lot of people. So that's, uh, not to sound like a broken record, but that is why we like pilot teams, because it is much more, um, it's much gentler for the people when it is for ex. Let's play this through. Let's. Your scenario is very realistic. So we. Let's say the company agrees that in principle it makes sense to try this with a product team. But then they say, the CFO says, but we still have a funding project, uh, process based on projects. So what do you do with the annual planning process? What we suggest, it's very easy. Lots of people have done this is, is that they go to the CFO and say, in support of this experiment, rather than funding a project, can you just fund a product team for some number of quarters? It might be one quarter, it might be three or four quarters, whatever. Uh, which is a very minor change for the finance people. They can do that. And then we tell them, and instead of funding a project which is output, but you're funding an outcome and which of course is self finance, it's like, yeah, that's what matters to us is the outcomes. And their biggest frustration is usually because they fund projects, but they don't get outcomes. And now they're able to more directly fund an outcome. And the hope is the team will come much closer to delivering that outcome, maybe even exceed that outcome. That's what we're hoping for. Uh, so that's a minor change to finance, it's a minor change to planning. And everybody knows we're doing this as part of an experiment. And if it works well, great. It's not a very big change to the model if it doesn't work well. It has been very low risk test.

Speaker B: Uh-huh. Okay. I guess for. For different stakeholders in the company, it's presumably mostly the same discussion. Right. Finance will mostly come around.

Speaker C: Yeah, I picked that.

Speaker B: The objection.

Speaker C: That's usually the hardest one.

Speaker B: Uh, okay. Uh, about sales, actually, you know, to be.

Speaker C: Oh, that's a great one. Sales is another hard one. It is. Now, a lot of companies don't actually have a direct sales Organization. So for different. But they all have finance organization. But if you have a direct sales model, then building trust with sales is usually the most important hurdle. Uh, and in fact one of the case studies in the new book I'm most excited about sharing with the world is a very heavily sales driven company in the B2B SaaS world. These are typically the last places to be open to the product model. And a company that exactly they had tried, you know, they were not getting the results so they transformed. And this, it tells the story of how the product organization earned the trust of sales. And uh, I will tell you, one of the remarkable things that they did was that sales, uh, sorry, the product teams took salespeople along with literally hundreds of customer visits. And it did not take long before sales realized that product knew much more about what it took to make a customer successful than they were even aware of. And that was the key to them delivering building systems that actually their customers loved. Which of course, course nobody likes that better than sales.

Speaker B: Interesting. Um, typically it's the other way around. Right? Sales um, is protecting their key accounts. And uh, they want to, they're doing

Speaker C: that because they don't trust product. And to earn trust of sales you have to show that you understand this. Uh, I, the, the uh, case study is on a company called Data site. And I, I uh, encourage anybody because a lot of people will say, I mean look, you hear these excuses all over the place. We have a direct sales organization. We can't do the product model. We're in a regulated industry. We can't do the product model. We build hardware. We can't do the product model. We're a brick and mortar company. We can't do the product. None of these are true. And the best way to show they're not true is to show them counter examples. So I'm hoping those counter examples will uh, will open people's eyes to what's possible. I do know though I'm not naive because there are a lot of people that are just looking for a reason not to change. That's again human nature. And so at the very least there will always be people that say our company is different.

Speaker B: So I guess the uh, product model in action section and the Overcoming Objections should guide readers, you know, through these discussions. Right?

Speaker C: Uh, that's the hope. I think it's worth calling out. I didn't mention that yet. One of the longest sections in the book is, is entitled Overcoming Objections. And the truth is there, there are always some people that just don't want to Change. We were just talking about them. But more, the more realistic problem is that people are willing to change, but they have legitimate objections. For example, the finance person does not understand how it will work in the new model. And they want to know their job is to protect the assets of the company. So they should know, uh, or sales doesn't understand, and they want to understand how this changes when product teams go directly to customers or compliance officers or legal officers need to understand how they do their job in the product model. And so we've been hearing these objections for many years, and we think they're all legitimate objections. We just shared the objection and shared our answer to those objections so that any company that tries to transform is prepared for those questions.

Speaker B: What is your preferred way? Or what is, you know, the best practice, um, to bring these thoughts into the organization? Do you have, like, a management, uh, circle where you discuss, discuss this, uh, topics, or do you do it one on one on one? Or like, what is, what is your, you know, out of your experience? You went through that process many times.

Speaker C: Yeah.

Speaker B: What works best?

Speaker C: Well, I do think, um, you know, different product coaches have different approaches, and there's no one. There's not just one way that works. Uh, and my partners and I, we get together twice a year in person, and we always talk about what we've learned about do we want to change any of our recommendations here? How does this. Because that's basically what my partners do all the time. So our best guidance is what we included in the book.

Speaker B: So.

Speaker C: And it's a little complicated, but it starts with an executive briefing. Because unless the senior executive team understands what we've been talking about, you and I here for the last half hour, unless they understand that they can't make. Even if they agree to support a transformation, they need to know what they're getting into, because pretty soon they will figure it out. It is important for them to understand in advance what they're getting into. So we like to start with an executive briefing that's about two to three hours with the senior leader. And it talks about what the product model is really about, why companies change to it, and what it would mean for them. So that's an executive briefing. And if the company and we tell them, like, don't move forward unless you believe you want to do this. I want to. We want to answer your questions, but only move forward if you think it's the right thing for your company. If they do decide to move forward. Uh, we start with an assessment. I was mentioning that before an Assessment. So now we need to see where they really are. Um, and then that assessment leads to a planning. We call them a transformation planning workshop. Basically where you, where you chart out your plan. What is. Like, for example, if we recommend, uh, a pilot team, which team would be the pilot team or how many pilots and what should each pilot team pursue? These are the kinds of questions we're answering in that pilot team workshop. Uh, and then there's very often some training required because I mentioned those, uh, competencies. If they don't have people with those skills, they need to learn those skills, otherwise the whole thing falls apart. Uh, so that might be required depending on the company. Another thing we usually recommend is the help of product coaches. Product coaches are independent coaches. We don't have any financial ties with any of them. But some companies, the leaders have never done this before. So that you need a product leadership coach. Many companies have never done product discovery before. We might recommend the product discovery coach. Sometimes the senior executives have never done, worked in this way before and they need a transformation coach. There are, uh, sometimes the engineers have never actually done real continuous deployment. They need a delivery coach. Um, there are different scenarios that come up in the assessment and in some of those cases we will recommend a product coach.

Speaker B: Interesting. So, you know, like, I just put my, my head into the position of, you know, a product leader listening, and I asked myself, okay, executive briefing. Um, it sounds easy, but actually, you know, like, we want to transform, but we might have in our backhead. Okay. It's easier to start with a, uh, pilot, uh, team. Right. So how do you, how do you structure that? Like, do you really sell? Okay, we need to change something and let's transform. Or do you, do you frame it? Okay, let's, let's have a pilot, uh, if we can do better, you know, get better outcomes with a, um, with different, um, project, um, product M model. Or like, how do you, you know, how do you structure something like that?

Speaker C: This is what I meant when I said there's a lot of different scenarios here. Let me just give you the two. Two common, extreme scenarios. One is that the CEO is the one that reaches out to us, us or to whoever, uh, they. But when they reach out to us, the CEO is often, because now they're scared. They have a big competitive threat. They're like, okay, you've been messing around with Agile. We haven't got anywhere. We need to get serious about this. And they're like, what do we do? All right, that's one scenario, right? Because there's, from the top, it's the easiest, but it's also the one that's under the most time pressure. So it's in one way it's the hardest, but it's. That's one scenario. Another scenario is the CEO doesn't know anything about this stuff, but one of the product leaders calls us and says we want to do an experiment and try to show the company what we can do. Both of those are very common ways this, these transformations can start. One is coming more bottom up, the other one is coming more top down. Uh, and then there's the most common is probably in between. It's the Chief Product Officer who already has some level of support from the CEO. The CEO has probably said something like the goals for the year include transformation. And so the CEPO is assigned that responsibility. And now they don't know what that really means, but they want to learn. All of these are possible scenarios. Um, that's why it's hard to give just one answer there.

Speaker B: M. Okay, I want to read out a short section in your book. Uh, um, 329. If somebody want to read uh, later on the role of the CEO because we just discussed that, uh, while theoretically not impossible, it's extremely difficult to transform successfully without the active support of the system CEO. The other items in this list will make uh, obvious why this is the case. And to be clear, when the CEO decides just to designate some leader as being responsible for digital transformation, that is not what we are talking about. This common mistake makes it all too easy for the rest of the company. Continue business as usual. I found this really important in the whole book. It's at the very end, but it actually says, okay, if you don't have the CEO on board, you don't need to start. Or do I misinterpret it there?

Speaker C: You'll also find in the introductory chapters, uh, a breakout on exactly this topic. So you'll see it at the front of the book and you'll see it at the end of the book as well. It is a very important point and this is why we tell people this is not an IT thing. Transformation is not just your technology organization. It impacts the whole company. It's not hard to see. It impacts hr. It impacts finance like we just talked about. It impacts sales and marketing like we just talked about. So unless you have the support of the senior leader, you are going to run into roadblocks with those other parts of the company. Now that said, even if you have that high level support, you need to earn the trust. So most of the work is on the teams to show that they are, they, they have earned that trust and earn that ability to get these experiments run and adopt it. Mhm.

Speaker B: What do you do? I mean it's not easy to have the CEO on board and if it's such a crucial position and I totally understand. Right. So you know, like what do you do if you, if you don't have the support of the CEO yet?

Speaker C: That's the scenario I was describing where we strongly recommend position it as an experiment, uh, and just say, and by the way, if it's a big company, it's an experiment within one business unit of the company. So you are, uh, and let the leaders, you know, share this experiment with the CEO, uh, when the time is right. But what you're really doing is showing the company in a very safe, responsible way that we can do this experiment and if it works, you know, I, I have never met a CEO that didn't want better outcomes. It's just they all exist.

Speaker B: They do.

Speaker C: They might not understand all the stuff we're talking about because they come from a different part of the company, but they can appreciate outcomes.

Speaker B: So now we talked a lot about, you know, a product leader, what he or she, um, can do to influence, uh, the company. Let's make the challenge a little bit harder. Say you're a product manager or you know, you just started off as a product owner or something like that, right. What do you, what would you tell them how they can influence or can they influence the organization?

Speaker C: Yeah, well, there are, this is the most common really. Uh, and I, I probably share this advice more than really anything else I can think of. Uh, somebody is, let's say, you know, your audience is primarily in Europe and unfortunately product owners are very prevalent there. Uh, and I tell product owners that I'm very nervous for your job. Uh, I don't think it's the real job. I think what you want to do to protect yourself is up level your skills to a product manager. And I have never seen a company where any manager or any leader prevents somebody from up leveling their skills. They, you know, they might not pay for it, they might not understand it, but if somebody goes to the effort of raising their skills from a product owner to a product manager, at the least they'll be appreciated. Uh, in my experience, those are people that, okay, all of a sudden there's somebody who really understands our customers. There's somebody who really understands the data, there's somebody who actually understands the business. We should promote that person because this that's who the stakeholders want to work with. At the very least, they'll probably get a promotion. Now, does that mean they can do everything we're talking about? Not yet. Probably not yet. Probably not for a while. Uh, an individual can influence their team and their team can start to show the rest of the company what's possible. But there is limitations. For example, are, uh, you going to get the head of marketing and the head of legal onboard stuff? Probably not. But can you show what you're capable of? Can you show what you can do to deliver outcomes? Can you show with prototypes? It's amazing what a prototype in discovery could do to get the rest of the company excited about what you're doing. So the point is, even an individual contributor can start to win hearts and minds. And I strongly encourage everybody to do that. Honestly, I was encouraging that even before the rise of generative AI. And now I tell people if they don't, you know, they could be in trouble. There's not a lot that's safe in a product owner role. A product manager is, uh, is a much higher value, higher, higher conceptual role because a product editor is worried about value and viability and those are the heart of every product company.

Speaker B: And I mean, I mean, same. We see that as well. Right. If you, if you have a product manager and um, they, you know, go through a training or something like that, their environment will feel and understand. They, they, they sense it. Right. And if you better, you get more.

Speaker C: The key is they have to actually, because there's a lot of different training out there. M. Uh, and what I, you know, the key is you have to be more than a project manager. Yeah, you have to be more than a product owner. You have to really build these new skills. Now do I, I believe, and I have coached a lot of people on this and I was coached myself, that you can generally raise your skills to a real product manager in on the order of three months of work. I don't think that's that long. We're not talking about a four year, you know, internship. We're talking about three months. If the person is, you know, hopefully being coached by somebody that been there, done that, or, you know, and I should say, uh, the person is willing to put in the effort.

Speaker B: Hearts and minds. You know, he said win hearts and minds. And actually it sounds like not not only the task for the project product manager, but also for the product leader. Right. Win hearts and minds on, primarily on

Speaker C: the product leader, their hearts and minds.

Speaker B: Well, what are the crucial skills one must acquire in order to, you know, um, transform the company. Because you know, like we spoke a lot about, you know, outcome and here experimentation and stuff like that. But actually it sounds more like a soft skill job, you know, to emphasize of the person, um, and you know, win their hearts and minds.

Speaker C: Let's talk about that. So I was just saying for an individual product owner to become a product manager, I believe we can normally do that on the order of three months. For a product leader in a feature team company to become a product leader in a real product company in the product model is a much bigger. That's not three months, not bigger. Uh, the book Empowered is really written for those people to learn what they need to do. And in that book really talks about two big categories of work. The first is learning how to coach your people. Because that is the primary job of a manager in product line or engineering is to coach their people. So they have to start doing that. They are responsible for the skills of their people. That's a big change and a big job. The second half of what they do is strategic context, which are again totally new skills for most of these product leaders. Product vision, product strategy, team topology, team objectives. Uh, these are new skills for these product leaders. Most of that a little bit they've been doing some uh, team topology. But in a feature team company they don't do most of this work. So big pressure is on those product leaders. And so I hold, I push harder on the product leaders. They are the ones and by the way, they're the ones. If a product transformation does not happen, that's really who we hold accountable. That's really, those are the people right at the center of this. And the way they win those hearts and minds is by doing their job, which builds trust, which then lets you win over the rest of the people in the company. Mhm. It starts with raising your game as a product leader. Mhm.

Speaker B: Marty AI is everywhere these days. What is the implication for the product managers? And especially you know, under uh, transformed. Like how transform, uh, the transformation of the company. What is the influence uh, of the technology, um, uh, on that process?

Speaker C: I mean the, the first of all, we're still very, very early. So we're all sort of figuring this out. But one thing we know for sure, um, there's sort of two elements to this. One is a lot of companies, the reason they want to transform is to take advantage of this technology in their products. In other words, they know they need a new generation of products and those products are powered by generative AI. Uh, and so that's, they need new skills in order to be doing this. That's one of the motivations for um, for a lot of the companies right now that are transforming they feel like if they don't they will be disrupted by competitors that do. The other category is how does generative AI impact the roles of or how we build products themselves and that way like how does it impact the product owner, how does it impact the product managers, how does it impact the designer? It's much easier to talk about how it impacts engineers and designers because that's already happening in, I mean it's happening everywhere but mostly just with toys, you know what I mean? Little things that people are doing opportunistically with engineers. It's in many companies it's real. It's real. The tools are significantly better and really helping developers and there's got lots of short term and long term implications of that. Designers. It's already happening. Like you wouldn't want to be just a graphic designer today if you uh, are just in university. That is not a good career job because most of that I think is going to be replaced. Now my prediction, and I could be wrong is product designers which are operating here, service design interactions, they will be more valuable, not less valuable but visual design and graphic design will be more automated than ever before. So you would want to focus on where you can provide real value. Of course I think in principle the same things exist in product management but there it's fuzzier. Um, I could think, you know, when I look at a product owner responsibilities and there are already tools coming out that will basically recommend prioritization of your backlog and interact with Jira and you know, it's like okay, what's, do you really want to be a product owner? Uh, I don't think puts a good long term careers prospects especially since so much of that is even better done by the engineers themselves and many of the engineers would prefer to do it. So there's a lot of reasons that's a dangerous uh, long term role. On the other hand when you talk about real product management then you're making real decisions about value and viability. And generative AI tools are turned tools to help you with that if they're used. Well that's uh, that's another conversation because right now a lot of teams are struggling to figure out how to use it helpfully versus make worse decisions faster.

Speaker B: Yeah, I mean how I uh, how I look at that and, and you know that better. I mean you're 40 years in in product management. Right. But in the 80s 90s, you know like we did different product management and like digital shifted everything. Right. It's a different type of product management. Right.

Speaker C: I mean I've been doing digital for 40 plus years so it hasn't really changed much actually for those that were building tech powered products. But it's a completely different thing for those that were developing say a new, new beer. Right. If you're doing a new beer, that's consumer packaged goods, that's uh, that has, you know, I don't, I, I don't never actually worked with that kind of product. So I don't know. But, but in tech powered companies the principles are remarkably consistent. Mhm, mhm.

Speaker B: Um, Marty, we're in Europe. You have a lot of, you're born out, you know, like out of the Silicon Valley. Much of the thinking comes from Silicon Valley. You say okay, there is a lot of examples, um, you know, in America and also from, you know, um, Southeast Asia and also from England is in the book. But still I think product management and the mindset is different in America and in Europe. Yeah. Do you have like, you know, for transformation? Is there an implication you uh, see how you treat European versus American companies?

Speaker C: I mean uh, the truth is some of the best companies in the world are European based, uh, and the best product model companies in the world are European based. I mean look at how I love Spotify and I think people were confused about what Spotify was really about. But they're a beautiful example of a company doing just the same principles uh, as the best product companies anywhere else. San Francisco, Seattle, New York, doesn't matter. Um, there are amazing companies in Israel, there's amazing companies in India, there's amazing companies in Germany. Uh, so I don't think, um, and the other thing I should point out is we have the same problems in most of the us. Honestly, you don't have to leave San Francisco to find terrible product. There are right across the street from each other. You could have a great one and a terrible one. Uh, that's another discussion. But I do think because my lens is kind of different, it's not like Germany, uk, us. My lens is the people I know better product people in France, in Germany, in Sweden, in Norway, in the uk. To me I see those people and I say there is no reason they can't build some of the best products in the world. Uh, it is true that in some countries management is less open to this. Right? Less open to this. Uh, this is especially clear in places like Japan. Korea, um, to a lesser extent, France, where there are views of leadership that are less friendly to this idea of empowering people to know what they could do. And so we have more work to do in those places. But even in those places there are, you know, there's some amazing teams in Japan today, there's some amazing teams in Korea today. They're more on the, um, early stage of the curves right now because those are cultural things that kind of get in the way. So, for example, one of the principles that you'll see is this necessary friction in a product team. But as you probably know, in some parts of the world, the pressure to, uh, not disagree is so high that it makes it very hard to have the necessary, uh, flow, friction and real collaboration that we need to innovate. So there are sometimes cultural things that get in the way. But my view is there is no reason, uh, you know, as long as you have the raw talent and you know Europe better than I do. But the raw talent there is amazing. The universities are amazing, the people with the skills are amazing. It's just I, I encourage them to show what their own people can do, learn what their own people can do.

Speaker B: Well, that's really good news for Europe. Yeah, that's really good. Well, Marty, um, I really hope that this is a huge success. I think, you know, like, I started like 15 years ago, I was, Got um, into context with Lean Startup and for me it made immediately click because I thought, okay, if we can, you know, just, you know, leverage that knowledge and be 5, 10% more efficient in building new startups. And in your case, in this book, it's just, you know, products. It's not startups, but it's products. If we can be more efficient, that will, you know, be a huge, um, contribution and um, wealth creation for, um. Yeah, for all the people who work in the companies, the company itself, but also society. So I'm really, yeah, enthusiastic. Um, I hope, um, more people work the way you describe and more people are able with this book. Um, yeah. To go in the right direction. Um, thank you. Have a great day. Enjoy the day. Uh, it's not every day you can release the, uh, book. So, um, really enjoy the day. Have a good day. Marty, thank you for being here.

Speaker C: Thank you. Bye everybody.

Speaker A: Thanks for tuning into the Product masterclass podcast. If you enjoyed today's episode, make sure to subscribe and leave us a review. It really helps us reach more product people like you. If you have questions or topics you'd love to hear about, reach out to us on LinkedIn, YouTube, or visit productmasterclass.com.