Marty Cagan on Product Management Theater in the Age of AI

(Intro Narrator at 00:00:00) Today, we're talking to product management expert and author Marty Cagan about product management theater and what it means to build products in the age of AI. You're listening to Joel Beasley, Modern CTO.

(Joel Beasley at 00:00:18) Hey, Marty. How are you doing?

(Marty Cagan at 00:00:20) Well, you're rocking quite the beard since the last time we've talked.

(Joel Beasley at 00:00:24) I've been growing it since our last conversation.

(Marty Cagan at 00:00:27) Looks good.

(Joel Beasley at 00:00:28) Thank you. It's been a while. You were episode nine. This is episode, like, 950. That's crazy. And I haven't learned much. No kidding. We'll just go ahead and jump right in.

(Marty Cagan at 00:00:41) Sounds good. I have said that there is a problem called product management theater where people have the title, but they're really doing a very different job. I think AI is shining a light on why it's so important not to do that model, but it's also at the same time making it easier to do that model than ever before.

(Joel Beasley at 00:01:12) Yeah. AI's been something that's definitely come up since the last time we've chatted. How is that directly affecting product managers? Like, what are product managers doing with AI right now?

(Marty Cagan at 00:01:22) Well, so that sort of leads back to the first question. There are multiple forms of multiple ways of building products. This is not news to anybody. Multiple ways to build products. In general, we would put them into sort of three buckets. Not so much in the U.S., but in a lot of the world, especially Europe, they have this idea of an Agile product owner and a bunch of developers. That's never been good at creating products. It's a software factory model. And AI, especially with the new tools like Claude Code, are just making that model irrelevant. So good riddance is what I say to that because that was never a good model. That was people misunderstanding what Agile was really about.

(Marty Cagan at 00:02:24) And so the other two models—and these are very—this, the second one, is very prevalent in the world, especially in the U.S. I hate saying that, but it's true. And that is called the feature team model. This is actually what most tech organizations do. And what that is, it's known as the project model. The idea is a bunch of executives come up with a roadmap, which is a prioritized list of features and projects. Those items on a roadmap get assigned to product teams of some sort. We call them feature teams that work this way. And their job is to knock out as many of those items on the roadmap as they can. And so they have somebody called the product manager. It used to be called a business analyst. Better, more accurate definition of it, where their job would be to gather the requirements of what that feature is. And then they usually pass it off to a designer to do a design and user experience and then pass it off to a bunch of engineers to build. Then sprint planning would happen, basically, and they would build it some number of sprints, and they would ship it. That's called the feature team model or the project model because at the end you have a shipment, which is great, but it doesn't actually necessarily achieve any kind of business outcome. In fact, the vast majority of features that are shipped don't move the needle at all. So the project model is very predictable. It's pretty straightforward and easy to do, but it's not very effective when it comes to business results. That has been well known for a long time, but the truth is, up until Gen AI, if you talk to a typical CTO or even CEO, they would tell you, "Look, our bottleneck is it just takes a long time to build anything." And so the focus was really on the developers building. Now, of course, in a lot of companies, that is dramatically changing. And the bottleneck is no longer the engineers taking time to build something and get it out. The bottleneck is now much more appropriately recognized as, what do you want these people to build? And that's the product management role in a nutshell. It's figuring out something worth building. And Gen AI is shining a light on how important that is.

(Marty Cagan at 00:05:08) But at the same time—and I'll talk about the product model in a minute here—but at the same time, I need to point out because I thought as soon as Gen AI came out and we saw how amazing it was for this, people would finally abandon the project model, but they didn't. So many people look at the project model and say, "With Gen AI, I don't even have to talk to my customers. I can just send it to my customer service stuff and I'll read all the requests and build a roadmap, and I can press a button and have a prompt create a PRD for me, and then I can actually create—you know, everything I need Gen AI can speed up." So all that's done, and you see that more than ever. We have more garbage being shipped than I ever remember. And I do not blame AI for that. That's really not AI. That's the model people are using. You know, AI is a tool. You can use it to do whatever, including speed up a bad process. So I wish I could say that Gen AI represented the end of bad stuff, but we're nowhere near there yet. However, for teams that actually care about creating real results, meaningful impact for your customers, for your business, that's the product model. In the product model, you're not given a roadmap of features to build. You're given problems to solve. And those problems have to be solved in a way that your customers love, but also work for your business. And that's the art of product. In order to do that, this is what it means to be an empowered product team. The team actually has to figure out a solution that genuinely works. It might take them a dozen tries in order to do that, but they're not done until they actually move that needle. They solve that problem. Typically, the way it works is you're given a problem to solve and an outcome to achieve that says, "Yeah, this worked." That might be related to growth. It might be related to retention. It might be fixing how long it takes to onboard a customer. It could be anything. But it's measured not by, "Oh, we shipped." It's measured by, "Yes, that worked." And to do that, it requires new skills on the team. For the designers and the engineers, it's actually more like finally letting them use the skills they have. So it's really not that big a difference for them. But for the product manager, it is a dramatically different job. So, for example, Agile product owner training doesn't cover any of what's required for a product manager. A product manager needs to be not only an expert in your users and your customers and how they buy, how they find products, but they also have to understand your business. How do you market? How do you sell? How do you fund? How do you monetize? What are the legal issues? What are the compliance issues? All of these, because that's how, if you're trying to solve for the customer and for your business in your product team, your engineers and your designers can cover the technology and what's possible and the user experience, but the product manager has to bring this knowledge of the customers and the business. And that is very obvious when it's missing.

(Joel Beasley at 00:08:54) When you work with companies, do you find that they're aware of these different models and they've consciously chosen one, or have they just kind of fallen into some behavior?

(Marty Cagan at 00:09:03) The vast majority of companies are just doing what they've learned. Yeah. That's kind of been the problem is that we've always had these three kinds of companies. And as far as absolute numbers, the third model I described, the product model, is clearly the minority. But if you look at the outperforming companies now, not the least of which are the Anthropics of the world, then you will see that there you can see their founders, they came from places that were working in this model, so that's where they learned it generally. And, unfortunately, there's also thousands and thousands of companies out there, usually bigger companies, older legacy companies, that came—their leaders learn from companies that work the same way, like a big bank or something. And so they, it sort of propagates that way. What causes companies to change is—I mean, there's a few reasons. The biggest reason is the board says, "We're not valued as a tech-powered company. We need to become valued like a tech-powered company." And so they bring in a leader from Amazon or from somewhere that really knows how to work this way. Because of that, they're trying to change and really get the valuation you get when you can prove consistent innovation. Sometimes they change, though, because their CFO just says, "This is ridiculous. We have wasted so much money over the last ten years and we get nothing in response, you know, so there must be a better way." So they reach out. They start looking around. So these are sort of the main ways that people find out about it. Obviously, I do everything I can to try to spread it. I've written books to talk about it. But, you know, it's a small percentage of the world that actually sees those things, and a company has to be in the right place to really adopt that. They have to have some pain usually or some really strong motivation to make these cultural changes.

(Joel Beasley at 00:11:20) And you just had a book come out in 2024. Is that your most recent one?

(Marty Cagan at 00:11:25) Yeah. That's "Transformed." That talks about what it means to move to the product model.

(Joel Beasley at 00:11:34) Now, a question for you. Is there ever an industry or a situation where the product model is not the most ideal model?

(Marty Cagan at 00:11:44) Absolutely. Oh, there is. Okay. If—in fact, I think this is one of the problems that happened with Agile is they oversold it. They started selling it, and of course it's for developers. But people started trying to tell marketing teams to use it, finance. Of course. Yeah. It's like, what are you doing? But, no, the product model—and I tell this to people all the time—if you're not building with developers, if you're not building, it's not for you. You need to be building because it's all about achieving outcomes. And if you don't have control of the machine that is building the, you know, generating those outcomes, it's just theater. So it's for people that build. Now, you know, as today, you don't need a lot of developers to be building something. Yeah. But you do need to consciously be building. If, for example, if all you're doing is buying Salesforce.com and all you need to do is tailor it a little bit to, you know, your favorite fields to track, you don't need developers for that. You know? So the product model's not for that. But if you're building Salesforce.com, it's absolutely appropriate.

(Joel Beasley at 00:13:01) Okay. Yeah. That makes sense. So as far as, like, anyone who's building—like, if I'm building a Neuralink-type device, I want the product model.

(Marty Cagan at 00:13:10) I would argue you do. Okay. If it's, especially the harder it is, the riskier it is. I mean, you just picked a pretty tough one. Right? Yeah. So first of all, it's hardware and not just software. And also it's, you know, neuroscience. It's literally brain science. So this is hard. The riskier it is, the more important it is. In fact, the companies that I think really have no choice are the Apples of the world, that are doing devices, because in a device, if you mess up that device, these are often multimillion, if not billion dollar mistakes.

(Joel Beasley at 00:13:50) Now, I'm sure there's at least one person out there listening that is learning about these three. This is kind of, like, might be news to them. And they might realize that, "Hey, we are in the project model or we're in the feature team model at my company." It seems like, obviously, it would be a massive mountain to get the behavior change to happen throughout the organization, but you would have to take a first step or learn more. Like, have you ever seen someone successfully change their organization to these models?

(Marty Cagan at 00:14:22) In fact, most of the time it's just the way you describe. Somebody sort of, you see—maybe the most often scenario I see is they hire some dev manager that comes from a good company, and they come there and they go, "What the hell? What did I just land in?" And so they go to their management and said, "You know, we got a lot more done and made much more revenue in my last place. What do you think about us doing a simple experiment? What do you think about us just running in this different way for a few months? And you see if it works here just as well as it works at Netflix or works at Amazon or works at Apple or works at Google. And if so, great. If not, no, you know, no problem. But maybe we can iterate or maybe it's just not for us." And that's such a low-risk, low-cost way of a company. And what, ironically, what it is, is it's using the product model to move to the product model. Because the product model says when you have something risky, you don't build it, you prototype it. And what you're doing in this hypothetical we're talking about is prototyping what it would be like. And everybody, by the way, gets to watch and see like, "Okay. Wow. That's a very different job description of these people called engineering tech leads or these people called product designers or, especially, these people called product managers." So what does that mean? We probably need to rescope these jobs. We need to, like, have all new training for them or whatever. And they never really understood that until they saw it in action in a pilot team. So we call these little experiments a pilot team.

(Joel Beasley at 00:16:15) Nice. And this is something that you do? Like, I know you write a lot. I know you from your books. Right? And the—I shared this with you, I think, when we first met years ago, but I was at my friend's house, and he was the engineer that I respected the most because he was both a fantastic engineer and designer. And your book was on his shelf, and I was like, "What's this?" He's like, "Oh, you should read that." And I read it, and it just opened my mind to all of these new ideas. And so—

(Marty Cagan at 00:16:43) But, you know, to the point, nothing in there was my idea. It was all sharing—

(Joel Beasley at 00:16:49) But you communicated it so well. And you're right.

(Marty Cagan at 00:16:51) You're right. Yeah. It—I hope that— Right. But it—there's sort of two things. Is what is the message, and then how do you communicate that message? The message was just sharing what these other companies, what I was taught, and these other companies do. So it's just amazing how, because, you know, the first book was written like twenty years ago. And I had been doing it for twenty years before that. So, I mean, it's not like this stuff is new. It's just that it's not evenly distributed around the world, the tech world.

(Joel Beasley at 00:17:25) Well, you did it in a very kind way. I specifically remember, at the time, most of my learning was reading docs, getting yelled at on Stack Overflow, and that was pretty much it. I hadn't figured out books in this space, and yours is one of the very first books. And when I did it, like, the tone—you do it in a very kind way, in a very clear way. You explain the concepts, and it was just, you know, really, really well done. And so if I remember correctly, I remember you from your writing the most, but you also have a company where you consult and do training. Is that correct or no?

(Marty Cagan at 00:18:03) We do some training in it, yes. My partners do, especially. But mostly what we're doing is just everything we do is trying to find a way to share these techniques and principles. And, for example, when—the most common thing is a CEO will reach out to us and say, "All right. We realize we're going in circles. We need to get serious about this, and we've realized that we don't actually work the way these good companies work. And so can you sort of help us understand what that means?" Books help do that. Articles help do that.

(Marty Kagan at 00:18:40) We do briefings with the executives to help do that. When we get a pilot team together, we'll train the pilot team because most of them have never worked this way before. You know, the truth is the developers, and really especially developers, they're rarely the problem. They kind of know intuitively that they've been wasting, you know, that they've been just building a bunch of useless stuff, so they know that. And when you explain it to them, their sort of consistent answer is, well, of course.

(Marty Kagan at 00:19:11) Of course. But, you know, they know every roadmap they're working on, they rarely had any say on that roadmap. And of course, in a good company, it's the opposite. Best ideas are coming from the developers. So it's a very, you know, none of that really surprises them, but it's always sort of a happy day for them.

(Marty Kagan at 00:19:34) For some of the other people, it's more of a bigger change.

(Joel Beasley at 00:19:38) Well, yeah. And the best ideas will — I've been on both sides of it, right? Starting as a developer and then moving up. But I've also seen, you said the best ideas can come from developers, and that's true.

(Joel Beasley at 00:19:51) But I think that the big asterisk there is if it's presented in the right way. So sometimes I've seen business people present it to developers in some basic ways and, let's say, some less good ways. The better ways I've seen them presented to developers are like, hey, here's the outcome that we're looking for. Here's the problem the customer is experiencing.

(Joel Beasley at 00:20:14) And if they can communicate it clearly and effectively to the developers, then the developers can be creative onto — it's like the GEICO thing, right? If the developers are getting kind of garbage or ambiguity and just saying, you know, build this, versus we're building this because, or, you know, we're thinking about building this or we're gonna prototype this because — so I think that's a huge part of it too.

(Marty Kagan at 00:20:36) It is. But we, I mean, we call that how you frame it. If I come to you and just say, give me this damn feature that this competitor has, alright, pretty much my job is just build that feature. That's — I'm not being asked.

(Marty Kagan at 00:20:50) And that's what a feature team does, is knock out those features. If I go to you and say, our customers have this problem, you can talk to them or you can look at this video I made or whatever and you can see the customers have this problem or our own company has this problem. Costs us way too much, takes too long. But this is the problem. I don't know the best way to fix it, but I'm hoping you do.

(Marty Kagan at 00:21:17) And the reason that's so powerful is because the people that know what's just now possible are the engineers more than anyone else consistently. Because the engineers are working with the enabling technology every single day. So if you explain the problem to solve to an engineer that is working with the enabling technology, that is where innovation literally comes from. And more often than not, almost all the time actually, that innovation, that great solution that your customers didn't even know was possible came because the developer was given the problem to solve instead of the feature to build.

(Marty Kagan at 00:22:06) That's why most famous coach in the world, the guy named Bill Campbell, used to say the single most important thing in a product company is our empowered engineers. These are engineers that are there not just to build what you're told, but to figure out the right solution.

(Joel Beasley at 00:22:24) That's a fun one. Sometimes people just say, my team's empowered.

(Marty Kagan at 00:22:29) Yeah.

(Joel Beasley at 00:22:31) That's — you said earlier something that caught my attention. You said AI can speed up a bad process really well. And that makes sense based off the models and how you describe them. Are you seeing anyone use the AI to improve the product model to speed up a good process?

(Marty Kagan at 00:22:48) Absolutely. I mean, that's what we're all so excited about. So the good company, and by the way, you don't have to look further than the AI companies are basically doing that. So there was a wonderful — because I know you like design too.

(Marty Kagan at 00:23:03) I remember that from our first talk. The head of design at Anthropic gave a talk about how the tools are used to change how product discovery is done so much better today. But the bottom line is, I mean, AI can help in everything in the product model, virtually everything. There's sort of three big areas. The first area is product strategy.

(Marty Kagan at 00:23:29) The second is product discovery, and the third is delivery. Everybody knows how it helps in delivery because that's the thing on the news every day, right? So we know that. The interesting thing to me is actually how it helps in product discovery.

(Marty Kagan at 00:23:44) Now we have been — even if you read the first edition of Inspired, we talked about how good teams would do 10, 20, 50 iterations of prototypes in a week. And people thought we were crazy, but of course we would just say, no, that's what Figma does. Check out Figma. It's not hard.

(Marty Kagan at 00:24:02) And teams have been doing it for years. But still, that took a designer. Figma was designed for designers. Today, with the amazing prototyping tools that are available, whether they're Lovable or you can use the developer's tools for it too. But I'm really focused on those tools that are designed not for the developers, but for the non-developers to be able to essentially vibe code a prototype.

(Marty Kagan at 00:24:34) And now we're able to create — I mean, we can create 50 prototypes in a week without even breathing hard. And that has totally brought the — what it's done is let even not very sophisticated product teams have the kind of pace of learning that it previously was reserved for very strong product teams.

(Joel Beasley at 00:25:00) Oh, absolutely. By the way, I'm a customer of Lovable. I saw it come out, and I said, yeah, I'm gonna play with this. And I built a, you know, fairly basic website, and then I had an internal application I wanted to build.

(Joel Beasley at 00:25:13) And so I started trying to build it in Lovable, and I realized really quickly, oh, it's not great for this, but I can prototype it. And then once I figure out the relationships between all the data and how I kind of wanted the interfaces to look, I actually took screenshots of that, opened up a Rails project, and got Cursor going, and then just built out all my stuff. And I realized, oh, okay. Visually, this is great for me to move through things really quickly and to prototype some ideas. Then I can take that knowledge and actually go build the application with AI but in a more stable way.

(Marty Kagan at 00:25:45) So you figured out very quickly what so many in the product community are figuring out, because for a while — see, you were able to figure that out quickly because you actually knew both sides. Most people only know one side. So they know, I know how to engineer a scalable, fault-tolerant application, or I know how to prototype a user experience. And those are two different things.

(Marty Kagan at 00:26:15) One of the things that we shared recently that really resonated with people, and I don't take credit for the phrase. It came from a friend of mine, Jeff Patton, you may have heard of. But that is the distinction between building to learn and building to earn. Those were the two different kinds of building that you did. And you used Lovable to build to learn and you used Cursor to build to earn.

(Marty Kagan at 00:26:43) That makes total sense. Now, you were able to do both and I love that more people can, but it's important to realize you don't need to. So, for example, let's say you only wanted to do the Cursor work. Great. You focus on build to earn and somebody else might focus on the build to learn.

(Marty Kagan at 00:27:04) Because these are very different purposes. So we're using different tools to create them. We don't have to, but we're usually are because of the reasons you observe. And we're testing them very differently. You test a prototype to learn very differently than you test a product to earn.

(Marty Kagan at 00:27:28) The whole notion of testing is completely different. You know, with a real product, it's more quality assurance, making sure it works as advertised. That's not what we're doing in build to learn. We're trying to figure out if actually the finance person says it's okay or legal says it's okay or what the cost would be for this or whether our users could figure it out, right, or whether our customers would buy it. These are totally different questions than does this work as advertised.

(Joel Beasley at 00:28:03) Well, absolutely. In the prototyping phase after, you know, reading your books and getting more experience and all of that, I realized, like, wow, there's so much more involved with, like you said, the finance guy, like your business model. Like, yes, you're prototyping the interface and trying to figure out what the product is. At the same time, you're trying to understand what the business model could be because people will pay for different things based off of context or how it's presented to them.

(Joel Beasley at 00:28:28) So to summarize the AI speeding up the good process, the best way that you have seen people using the AI and the product model is what?

(Marty Kagan at 00:28:40) So it's hard to pick one, but I would say they're using the appropriate tools to accelerate build to learn. In other words, product discovery, which is about understanding the problem but, most importantly, coming up with a solution that your customers would consider valuable, your users would consider usable, your engineers would consider feasible and your stakeholders in your business would consider viable. Those are the risks. That's the risk taxonomy we use. Once we feel confident about all four of those risks, then the product is built to earn.

(Marty Kagan at 00:29:27) And that is, you know, our engineers know how to do that better than ever.

(Joel Beasley at 00:29:33) I want to talk about the coaching gap using AI and dealing with coaching. Let's, when we start talking about, like, as we get into this part of the conversation, what is the product coaching that you're referring to?

(Marty Kagan at 00:29:49) Yeah. And by the way, I realized as we've been talking, I have used the term model ambiguously. There's two kinds of models that we're discussing here at the same time. One is the model of product development, and the two major models I've referred to are the project model and the product model. The other kind of model, which is actually the main kind of model for most of the world today, is a large language model.

(Marty Kagan at 00:30:20) And so the reason that's important and they share the term model, but we're talking apples and oranges, of course. The reason this is relevant is, to me, the best thing to happen — I mean, there's so many, the impact of GenAI is pretty amazing at this point and it's just really getting started. But I would argue, yes, the prototyping has been awesome. The building production code has been awesome. But maybe even the more profound difference is that we today can use a large language model to learn the product model.

(Marty Kagan at 00:31:08) So we refer to this as AI as product coach. And I would consider that for people ranging from a founder at a startup to a product manager. Really it applies to other roles as well, but especially those, it's a game changer. Because up until a year ago, if you wanted to consistently do good work, you better find somebody to coach you, somebody who can help you learn this stuff. That's what helped me.

(Marty Kagan at 00:31:51) I was able to benefit from coaches teaching me. That's what most of the experienced product people I know that have really done great things benefited from at least one very strong product coach. Most people are at companies where their manager has never worked this way. And even if they have, like at a company like Amazon, you might have read Amazon has been increasing the span of control of their managers, which means basically their managers have a whole lot more number of reports. And so even when they do know how to coach, they often don't have the time.

(Marty Kagan at 00:32:30) So this has been the big problem is that it has really hindered companies and people from learning this stuff. We never had a great answer to that. We do have a network of coaches we recommend, but it's literally like 100 coaches around the world, and we're talking millions of people that need help. Millions. So about, well, I mean, it's been clear that for a couple years that this was the hope.

(Marty Kagan at 00:32:59) We just nobody knew if and when it was really gonna happen. But a few months ago, roughly six months ago now, the language models got so much better. And our knowledge of how to instruct the language models got so much better that today, for no cost other than access to your language model, you can set up a 7x24 personal product coach to teach you how to do product. And that is a game changer because even if you were lucky enough before, you know, most of us had a one-on-one once a week for an hour. And that's how we learned.

(Marty Kagan at 00:33:50) And then we practice in between. Now, you know, I've got a coach in the pocket, and it's there anytime I want.

(Joel Beasley at 00:34:02) Do you have articles on how to do this, or do you make your own?

(Marty Kagan at 00:34:05) It's one of our most popular articles. It's called AI Product Coach, I think.

(Joel Beasley at 00:34:12) Okay. We'll put a link to it in the show notes. But I would imagine you just say read all of Marty's books. Be Marty. You are Marty Kagan. Coach me. That's all you gotta tell us.

(Marty Kagan at 00:34:22) But in truth, one of the reasons, you know, at first when the language models were starting to be used, we would ask these questions and people would send us answers too that they got and they were just so much nonsense. And partly it's because, you know, the models weren't so great early on, but we realized that the models have of course trained on not just our content but everybody's content. And there are many different views out there including diametrically opposed views. Everything I'm telling you, I could point you to people that think just the opposite. So is it any wonder that a language model would say X one day and Y the next day?

(Marty Kagan at 00:35:11) You know, it'd be completely different. And so we realized that, no, you need to tell the model, you need to tell the language model which product model you want to learn. So we said, you know, and obviously, we have opinions on who to listen to, but we would say things like, you know, you are my product coach. I am trying to learn the product operating model as described in, like, the book Transformed or whatever. And we want you to prioritize the content of Shreyas Doshi and Teresa Torres and Marty Kagan.

(Marty Kagan at 00:35:56) You know, we'll say that so that the models can give advice that is really relevant and consistent. So if you say that, you don't have to go say, oh, ignore this person because they're clueless. Ignore this person. You don't have to say that. And but that's what was getting in the way.

(Marty Kagan at 00:36:19) The models were trained on so much contradictory stuff. And so now, you can clarify that. And the result is that today, the coaching is really good. It ranges from as good as a typical manager at a good company to very good. I wouldn't say it's as good as, you know, if I could tell you a name of a product coach as a real human that would just be specific to you, you know, that would be the best.

(Marty Kagan at 00:36:52) But, you know, you're talking a lot of money for that, and it's not scalable.

(Joel Beasley at 00:36:57) And it's not instant. No. Like, we could do this this afternoon. You can go and do this.

(Marty Kagan at 00:37:01) That's right.

(Joel Beasley at 00:37:02) That's awesome. I like how you put that asterisk in there of grabbing the people with similar views. Because over almost a thousand episodes, I've taken so much advice. I've tried stuff. I've experimented.

(Joel Beasley at 00:37:14) And the trend that I have found to be true, and I want you to tell me if you found this to be true in your professional life, is the scariest place to be is the place where you're listening to everyone, where you're reading everyone, you're trying, like, all the stuff. What I have found is that the people that tend to have success or myself, we'll just use myself, is picking one way of doing things and, like, really learning it deeply, like, very, very deeply. And then getting all the way to the end where, like, you learn what the experts argue about at the top. And then stepping back and looking at it. Because I made the mistake earlier of trying to do too many things at once, trying to learn — it's like in programming.

(Joel Beasley at 00:37:57) I mean, you're around engineers all the time. It's like I'm trying to learn 20 different languages at the same time. It's like master one. You'll understand these principles and these concepts. And even if that language isn't the best language for you, even if it's not the right one or the one you're going to use long term, at least you've mastered one and you understand these principles that emerge.

(Marty Cagan at 00:38:15) Well, you hit the key to me because I'm 100% with you on this. But I try to coach people to focus on the principles because the principles endure. I've been, you know, we've never had a bigger test to that than GenAI. But so far, we have 20 product model principles that we documented in the book Transformed. And they, again, came from these observations of the top companies.

(Marty Cagan at 00:38:50) We didn't invent any of them. And every six months or so, I look at all 20 principles and I say, is there anything that the new technology has changed there? And, of course, I've already talked, we've talked for the last hour about the massive changes in the tools and the techniques, but the principles have never been more relevant. So that's why if you focus on the principles, I think you get a lot more value. You also start to realize, okay, this person is not really going to be helpful to me or this person is really helpful to me because if you have that foundation of the principles, so much of this is all about learning to think, and that's really ultimately what the coaching is for.

(Joel Beasley at 00:39:47) So you've been writing a lot about the shape. What is the future shape of product teams?

(Marty Cagan at 00:39:53) So yes, we talked about how the technologies and the tools can really help your activities of a product team, discovery and delivery. But the other big thing, and I think this is very good overall. We'll talk about the pros and cons. I'm hedging a little bit there. Is how does GenAI impact the shape of product teams, also referred to as the team topology?

(Marty Cagan at 00:40:25) So a few things going on. One is already clear. The average number of developers per team is going down. And I actually consider that a good thing because as everybody knows, and companies have found this out involuntarily when they lay off, you know, 20%. A lot of times they'll say, I really miss my friends, but, wow, things are so much easier in our team because instead of having seven engineers, now we only have four.

(Marty Cagan at 00:40:56) And, you know, four is really easy to communicate and everybody knows what's going on. So there are real benefits to smaller teams. The other thing that isn't talked about as much, but I think is equally profound, is that the scope of product teams is increasing. So in other words, the span of what a team is responsible for is now increasing. The reason that's a good thing though is one of the most common complaints from even really good companies, by the way, in an empowered product team is they feel like, you know, we're just a cog in a giant wheel.

(Marty Cagan at 00:41:43) And for us to make a change, it requires coordinating with a dozen other teams. And they'll say, you know, it doesn't really feel that empowered because we're so dependent on all these other teams and they're not wrong. And those dependencies, you know, some of them are unavoidable for sure, but they are a pain. And so one, and the reason for that is because the scope is narrower than they wish they had. Most teams tell me they wish they had end to end control.

(Marty Cagan at 00:42:20) Like, we could add a feature top to bottom. We can do whatever we need to do. And that's increasingly doable because, as you know, the GenAI tools basically increase the cognitive capacity of the engineers on a team. They can grok a much bigger code base with the assistance of Cursor and Claude Code and stuff than they could ever before. So I love that.

(Marty Cagan at 00:42:54) So the average team size going down, the average scope going up. Now, of course, the reason I was hedging before is because the big unknown question is, okay, so we now need less people to do a given charter or a given thing. What about all those other people? In some companies, they probably are just laying them off because they don't need as many people to do whatever they wanted to do. In other companies, they're like, no.

(Marty Cagan at 00:43:30) We want to do more things. Now we can finally do more things. We can do our vision. Instead of seven years, we can do it in two years. This is what we want.

(Marty Cagan at 00:43:40) We have the funding. Let's do it faster. So, of course, what none of us know, we can only hope, is like, where will this balance out in our industry? Will we do more things on average, or will we do the same number of things with less number of people? It just depends on what actually, how it plays out.

(Marty Cagan at 00:44:04) There's no question I'm hoping and I'm increasingly optimistic that more companies will take advantage of the new opportunities, but I know some companies will use any excuse to reduce their workforce.

(Joel Beasley at 00:44:21) Yeah. Well, I mean yeah. I like the smaller teams, bigger vision. I like that trend. And I think a lot of people who are in the space like the trend.

(Joel Beasley at 00:44:34) I think what makes it unpopular to say that is when you start pulling that out to the economy and, like, people's jobs and, like, what the macro would look like. But...

(Marty Cagan at 00:44:44) Well, that's what I mean by if they end up laying off all these people, that will be, I think, very unfortunate. So I'm hoping that isn't what happens. I'm hoping, on average, more companies will do more. I also do, though, believe that it's never even. Right?

(Marty Cagan at 00:45:03) It's not like every company does the same thing. We've always had a lot of turmoil and churn around companies. I also believe it's easier than ever to start a new company.

(Joel Beasley at 00:45:14) Oh, it is. Yeah.

(Marty Cagan at 00:45:15) So I would love to see more of these talented people I know move from these big companies that are doing very little to a company where they can do something amazing.

(Joel Beasley at 00:45:28) The one thing you want to leave the CTOs, VPs of engineering, technology leaders with, what's the parting thought for them?

(Marty Cagan at 00:45:38) Well, yeah, there is big changes obviously for the engineers just like for the product managers, and what I care about is actually both, the whole product team, because products come from the teams. I would say, you know, there is a real misconception out there in a lot of engineers and engineering leaders because they have actually never seen product done well. And their very natural conclusion there is like, we don't need them. We don't need them. You hear that a lot.

(Marty Cagan at 00:46:13) And I'm like, you don't need what you have now, but you do need what you have been missing and that's becoming increasingly clear. So they're not wrong, they're just not seeing the big picture. And what I encourage, because engineers are smart people, they can figure this out if you show them. There is a lot of knowledge that's needed on your teams that is not in the heads of the engineers. They don't know, or even the senior leads, they don't know all the business constraints.

(Marty Cagan at 00:46:47) They don't know the compliance issues, the legal issues, the security issues. They don't know how the customer, how your sales organization works or how your product makes it to market. They don't know the different channels. They don't know the different costs. They don't know the different monetization strategies.

(Marty Cagan at 00:47:06) And they need to, on the product team, have this knowledge. So you could send all your engineers to a long bit of training, but it's not likely going to happen. What you really need is somebody with these skills, and that's what a real product manager brings to the team.

(Joel Beasley at 00:47:25) Thank you so much for listening. And if you found this episode useful, please share it with a friend or colleague who you think would get value from it. And if you have topics that you would like to hear discussed on the podcast, either add me on LinkedIn or send me an email [email protected]. Every time I get an email or LinkedIn message, it absolutely makes my day and inspires me to keep going.