Skip to content

By playing, you agree to uListen's Terms and Privacy Policy and YouTube's Terms of Service.

Aakash GuptaAakash Gupta

Godfather of Product Management: Do THIS!

In my 16 years of product management, I’ve yet to meet a PM who wasn’t influenced by Marty Cagan’s work.

Marty CaganguestAakash GuptahostPawel Hurynhost
Feb 21, 20251h 1mWatch on YouTube

Summaries, chapters, transcripts, and FAQs on this page are made by uListen, not YouTube.

Great conversations run long. Their best ideas don't have to.

uListen is free on iPhone, iPad, Android, Chrome, and Claude.

See how

Transcript

  1. 0:00 – 0:44

    Quarterly releases as a red flag: output vs. outcome mindset

    1. MC

      If the first thing they tell me is they release every quarter, I'm like, "Don't bother me. You're not agile in any sense at all."

    2. AG

      [instrumental music] What are the principles that you've seen in the best companies?

    3. MC

      Starting at the highest level, the very highest level, it's really about all about moving from output to outcomes. Outcomes is hard, output is easy. [laughs] What does it mean to be an agile coach today? Almost nothing. If that same thing happens to product coach, we lose.

    4. AG

      If that product leader hasn't lived it, then they can't influence it.

    5. MC

      Well, in fact, I would argue that the real key to successful transformation, there's a lot of things that have to go right, a lot of things that are hard, but the real key are-

    6. AG

      [instrumental music]

  2. 0:44 – 3:20

    Why product resources exploded—and why the noise is now the problem

    1. AG

      This is a really special episode of the "Product Growth Podcast." Marty Cagan is the author of the best-selling books Inspired, Empowered and Transformed, and now as a partner at Silicon Valley Product Group, he is transforming how many millions of product managers work. Pawel Huryn and I recorded this episode last year, but it's as relevant as ever. If you want to move to the product operating model, if you're a fan of Marty Cagan, or if you're facing challenges as a product manager, we ask Marty all the hot questions of how to overcome key obstacles. Really quickly, I think a crazy stat is that more than 50% of you listening are not subscribed. If you can subscribe on YouTube, follow on Apple or Spotify Podcasts, my commitment to you is that we'll continue to make this content better and better. And now on to today's episode. Marty has played a very formative role in my product career, and I'm curious, uh, Pawel I'm sure has a very similar story. [laughs]

    2. PH

      Yeah, I have a very similar story because after reading Inspired, I got interested in product management, uh, seriously, and I started reading more and, uh, writing at the conference. So this was transformative for me.

    3. AG

      Yeah, and I think every product manager probably has a similar tale, so thank you for what you've done for the product career.

    4. MC

      Oh, well, yeah, I mean, I remember when I started, um... I mean, I started product a long time ago, literally in the 1980s, so it's a long time ago, but there wasn't really any books. I mean, good or bad, there wasn't really any books. There were some books from the old, what we call product marketing, but there wasn't on product management. And I remember the person who was coaching me saying, you know, "There's no books on this. It's... The tech industry is not that big. There aren't that many of us that do this. The main way you learn it is from other people that have [laughs] done it and learned it before." And so I, um, and I realized, of course, after I left the bubble of Silicon Valley and kind of went to more companies around the industry and around the world, that there was so few resources for people who wanted to learn product. Um, and of course, today it's very different. Today there are so many resources. But today we kind of have a different problem, um, 'cause there are many different views on, on how to do product, and so, um, it's hard to, uh, it's hard to get heard above the noise.

    5. AG

      What are the principles that you've seen in the best companies?

  3. 3:20 – 6:48

    Three dimensions of transforming to outcomes: strategy, discovery, and delivery

    1. MC

      But we kind of define this starting at the highest level. Starting at the highest level, the very highest level, it's really about all about moving from output to outcomes. So if you had to say in one phrase what it's about, it's about changing to delivering outcomes, which as everybody knows who has even ever tried, that is very hard. [laughs] Uh, outcomes is hard, output is easy. [laughs] So at the highest level, it's about outcomes. But what does that really mean? 'Cause that's, that's just a, a phrase. That doesn't really mean much. So if you double-click on that, there are three dimensions that we see in every good product company, and it, it talks about when you transform three dimensions. The first dimension is changing how you decide what problems you need to solve. In other words, making your decisions on strategy. What is most important work to do? The way the best companies do that is very different than how most companies do with their big annual roadmaps and planning meetings and stuff like that. So the first topic is changing how you decide which problems are important to solve. That's really product strategy.

    2. AG

      This episode is brought to you by WorkOS. If you're building a SaaS app, at some point your customers will start asking for enterprise features like SAML authentication and SCIM provisioning. That's where WorkOS comes in, making it fast and painless to add enterprise features to your app. Their APIs are easy to understand so that you can ship quickly and get back to building other features. Today, hundreds of companies are already powered by WorkOS, including ones you probably know, like Vercel, Webflow and Loom. WorkOS also recently acquired Warrant, the fine-grained authorization service. Warrant's product is based on a groundbreaking authorization system called Zanzibar, which was originally designed for Google to power Google Docs and YouTube. This enables fast authorization checks at enormous scale while maintaining a flexible model that can be adapted to even the most complex use cases. If you're currently looking to build role-based access control or other enterprise features like single sign-on, SCIM or user management, you should consider WorkOS. It's a drop-in replacement for Auth0 and supports up to one million monthly active users for free. Check it out at workos.com/aakash to learn more. That's workos.com/aakash. Trust isn't just earned, it's demanded. Whether you're a startup founder navigating your first audit or a seasoned professional scaling your GRC program, proving your commitment to security has never been more critical or more complex. That's where Vanta comes in. Businesses use Vanta to establish trust by automating compliance needs across over 35 frameworks like SOC 2 and ISO 27001. Centralize security workflows, complete questionnaires up to five times faster, and proactively manage vendor risk. Vanta can help you start or scale your security program by connecting you with auditors and experts to conduct your audit and set up your security program quickly. Plus, with automation and AI throughout the platform, Vanta gives you time back so you can focus on building your company. Join over 9,000 global companies like Atlassian, Quora, and Factory who use Vanta to manage risk and improve security in real time. For a limited time, my listeners get $1,000 off Vanta at vanta.com/aakash. That's V-A-N-T-A.com/A-A-K-A-S-H for $1,000 off.

  4. 6:48 – 9:53

    Real agility vs. “doing agile”: continuous, uncoupled delivery

    1. MC

      The second dimension is changing how you solve those problems. In other words, the old... You know, one way, which is what's used still in most of the world, is the stakeholders define a bunch of features and projects that they prioritize onto roadmaps, and the team just knocks them out one after another. That's a feature team. And in good companies, they don't work that way. Those teams are given good problems to solve, and then they're empowered to come up with a solution that delivers the outcome that you need. So, and that's product discovery. So the second big dimension is product discovery, really changing how you solve problems. And the third big dimension, and I would argue all three of these are interrelated, but the third big dimension is changing how you build, test, and deploy your products. And this is, um, uh, if you want to prove outcomes, you need to make sure you have the data, which means you have to have e-everything instrumented. You have to have everything monitored. It means if you... Especially if you wanna take care of your customers and not hurt your customers, then, uh, which sounds obvious, but this is the difference between being agile and doing agile, right? So if you're being agile, you are actually releasing continuously. Now, as you both know, you don't have to be following any agile method to do that. All you have to do is truly be agile. You have to con... You know, small, frequent, uncoupled releases for, by each team. So that often means, uh, changing how you build. Um, that, 20 years ago, that's why companies moved to agile. Today, of course, you probably know a lot of the agile movement has been sort of taken over by, uh, what I would call fake agile or agile theater. And so if, if the first thing they tell me is they release every quarter, I'm like, "Don't bother me. You're not agile in any sense at all." So if you wanna take care of your customers, you're gonna have to change.

    2. PH

      Uh, I've been struggling with this a lot because I started my journey with Scrum, and, uh, later I discovered that Scrum says nothing about releasing your increments and also doesn't mention how you, uh, select what to build. So there is no discovery and no release, just, uh, verifying, uh, the results of your work with the stakeholders. [chuckles]

    3. MC

      Yeah, that, the, it's, it's... People try to think, you know, they think of it as a much different thing. They don't really know how to think of it, but it's really just a delivery process, and it's fine. There's nothing wrong with... If they do real Scrum, you know, releasing, say, at, at least once every two weeks, I'm usually... Okay. That's okay. That's not anything to brag about. [chuckles] That's not very impressive. Today, the best practice is continuous deployment, so it's not there obviously. But it's a whole lot better than

  5. 9:53 – 14:00

    Four competencies companies must actually have (and often don’t)

    1. MC

      releasing once a quarter or even once a month. So okay, you can be okay that way. All right, so back to Pawel's question. These are the three dimensions, changing how you decide which problems to solve, changing how you solve those problems, and changing how you deploy your solutions. That's, uh, at, again, at a high level. In order to do those things consistently, we argue there are four new competencies that you need in your organization, and there are five new product concepts you need in your organization. And these are tricky because you probably already use these words, but they don't mean the same thing. So, for example, this is where if I get too detailed... And I haven't even reached the level of the principles yet, Pawel. There are 20 principles that we outline in the book, but I will get to your, your direct answer in a minute. But in terms of the competencies, the first one is real product management. Uh, you know, and most companies don't have that. They have product owners, or they have feature team project manager types. They don't have real product managers. But if you're going to have empowered product teams that are responsible for achieving outcomes, I can promise you your... Very few designers can cover that outcome responsibility. Very few engineers can cover that. They cover other responsibilities that are critical, but that leaves a big hole if you don't have it filled on the team for somebody that can take responsibility for the value and the viability of the solution. So you need real product managers. You also need real designers, product designers, not just graphic designers, real product designers. And of course, you need real engineering tech leads. These are engineers that care just as much about what you build as how you build. And then hardest of all for most companies is that they need real product leaders, and most of them don't have that. They have managers that manage, you know, people with these titles, but they don't have people that have ever done this job in a product model company. So they have a big hole in product leadership. And product leadership is really two things. They're the ones responsible for coaching and developing the people- And they're the ones responsible for providing the strategic context, which is how teams make good decisions. So the product vision, the product strategy, the team topology, the objectives for each team. In other words, what is the work the team needs to do? Which problems do they need to solve? That comes from the strategic context. So the product leaders have ano- a very big role to play. So those are the four new product competencies and, and y- I will tell you this is where most transformation efforts fall down, is because the company thinks they have these people, but they don't.

    2. AG

      Can those companies transform at all?

    3. MC

      Absolutely. Yeah, I mean, that's what... You know, I, absolutely they can, but that does mean they have to introduce these competencies. And yes, that's hard. I mean, that is hard. But, uh, one of the things I knew we had to do in this book was to provide many examples of companies that have successfully transformed, and it was also clear that none of those examples should be Silicon Valley companies. Because the Silicon Valley companies have the advantage of being born in this model. They started in this model. It's much harder to be a company, say, based in London or based in anywhere that has never worked this way before to change. And so all the examples, uh, in the book, there are 11, if I remember right, 11 case studies. They all are from companies all around, all everywhere else in the world, uh, including places like Brazil, Saudi Arabia, uh, and of course,

  6. 14:00 – 17:33

    Five product model concepts and why principles matter more than frameworks

    1. MC

      uh, England and several other places. Okay, so those are the four competencies. I warned you to stop me if this gets too much. Um, there are five critical concepts that make up the product model, uh, starting with, uh, some of the ones we've talked about already. You need this concept of product strategy. It is a thing that is, uh, that spans the product teams. It's another common misconception. They think product teams are supposed to have their own product strategies and product visions, but they just have never worked in a product company, I think the people that say that. Okay, so, uh, product strategy is critical. The concept of a product team, a cross, you know, what Spotify calls a squad, but a cross-functional, truly cross-functional, empowered product team that is, uh, has the skills in order to come up with effective solutions that are valuable, usable, feasible, viable. That's why teams are really the center of all this. And then, of course, what do the teams do? They do product discovery and product delivery, so they need those concepts as well. And the final concept really underlies all of these, which we refer to as product culture, which are things that span all of them, and they're things like, um, what is the role of experimentation? What is the role of innovation? What is the role of predictability? These are critical cultural aspects. Okay, so those are the f- five product concepts. And then underlying all this is a set of, by our enumeration, 20 product principles, and that's what Pawel started with. But in order to get to those principles, I kind of needed to work my way down that stack. But the principles are a thing, like Pawel was asking for some examples of principles. Well, one is, for example, that you're gonna tackle all the risks up front. If you don't tackle all the risks up front, you're gonna spend all this time and money building the stuff that doesn't work. So you have to make sure you tackle those risks. Another one is that you have to embrace the concept of experiments. If you don't run experiments, you're never gonna be able to do the things you need to do. You'll be a very risk-averse company. Those are examples. Another one is what I was referring to before with deployment. If you don't have that principle of small, frequent, reliable, uncoupled releases, you won't be able to get these things live, measure the results, iterate like you need to. You also won't be able to prove outcome like you need to. So those are just a handful, but there are quite a few principles, and it's the principles I think that are most important because there's, as everybody knows, there's a lot of different cultures out there. There's a lot of different kinds of products. If you're building an iPhone, it's a different thing than if you're building, say, you know, Amazon Prime. It is a very different kind of product. One's a loyalty product, one's a device. But those principles you'll find in each of those and all of those, I should say. And that's why I think the principles are the most important. And I've always been much more interested in the principles than any process or any framework or any tool that might sometimes help you get there. Sorry for that very long answer to that question. [chuckles]

  7. 17:33 – 23:35

    Team frictions explained: feature teams vs. real product teams

    1. AG

      I want to double-click on right before we got to the principles, I think you emphasized, like, the five key requirements, and all of those were related to the team. So I actually want to double-click on some of the frictions I've encountered in teams that I've led or teams I've been a part of and curious how you try to, uh, tackle those. So I think the most common frictions I see are with PMs and engineering managers or tech leads and PMs and designers. So with the designers, I think that one of the things that was crazy was, you know, when Brian Chesky said he eliminated, of course, we all know he didn't eliminate the product management function, designers were so happy. [chuckles] And I find this universally is that designers carry a little bit of resentment almost towards their product manager kind of taking some decisions. So I'm curious about that component. And then with the engineering manager, it's a little bit different. It's where they're often tasked with the how to build something. Sometimes they're often tasked with the when, like give me this estimate of when we can also deliver it. And then they're wondering like, "How do I have more of a say in the why or what?" And so I'm curious for both of those tensions how, um, teams can s- work to overcome them.

    2. MC

      Well, the most important thing to realize is that, by the way, I see those tensions all the time, but not in real product teams. I see them in feature teams. In fact, they are clear symptoms of feature teams. Now why? It is worth really double-clicking on that. Why is that? Because in a feature team, the product manager is not doing what I've described before. They... Why- what does that mean to even do that? They're already handed a roadmap of output they have to deliver. So in a feature team, you have this person with a title, product manager, product owner, whatever they're called, yet they're not doing the job we talked about. What they're really doing, and I believe they're dramatically overpaid for this, but they're, uh, what they're really doing is project management. And that's why you see in these companies the people bend over backwards in order to try to defend the job. They're saying like, "Well, our job is to explain the why," or, "Our job is to herd the cats," or, "Our job is to communicate." And like the designers are listening to this and go, "Seriously? That's your job? I could do that job with a little bit more of what I already do." Or the engineers are looking at it and saying, "I could do that job with a little more than what I already do." You're not adding value. They're not. That's the truth. They're not really adding value. They're certainly not adding enough value to justify their existence if the company is in trouble. And as you know, a lot of companies today are in trouble, and they are worried about costs, and that is a tough job to defend, and I keep trying to warn people, like, if that's your job, if you're on a feature team, you are vulnerable. A lot of roles are vulnerable, but that one has got a huge target on its back. And so but you have to realize th- that's just a symptom of lack of role clarity because really, what is it that they're doing? I always tell anybody that tells me, "Oh, the job is the why," I'm like, "That's 10 minutes a week. 10 minutes a week. What are you doing the rest of the time? How hard is it to re-articulate the why? It comes from the product strategy anyway, so what are you... You're just really reiterating that to the team, and that's your job? Or, you know, herding the cats? Okay. Well, the truth is we've got a lot of project managers that are already in the engineering organization. They're probably doing most of that anyway." So it's, uh, you're, you're seeing a symptom of being in a different kind of team from what I'm talking about, and I, I see those symptoms all the time. It's a very strong clue about how they're really working. But if you talk to a product team, a real product team at a good product company, the designers are not saying, "Oh, well, the job is a noise job." The designers are like, "I'm glad we have this person because I don't, I wouldn't want to be doing that ra- job. That is a hard job." 'Cause fundamentally, the product manager, they're responsible for the value and the viability, and that's... They take ownership of the outcome. The designer is responsible, of course, for the usability. That's obvious. But they also more generally take responsibility for the customer experience, which is a huge responsibility. And the engineers, of course, are responsible for the technical feasibility, but more generally, they take responsibility for the delivery of the product. So we've got a very busy team. The designers have no time to play product manager, and the product manager has no time to play designer, and so, uh, you f- you don't see that muddied role that you see in feature teams. But I tell companies, "You know, if you're gonna do the feature team model, you really don't need the product manager. You need good designers, and you need good engineers, and I would rather cha- trade that product manager head for another designer."

    3. AG

      And if you are that product manager that's kind of in that position or even product leader, I would say even when I was a VP of product management and I was in some of these types of positions, can you realistically drive the transformation, or is it really like try to incept your leaders to buy a more into this type of thinking more? Like, how do we approach it as middle of the organization product folks who might be in that situation?

  8. 23:35 – 30:56

    How individuals can drive change: agency, skills, and winning the team

    1. MC

      I think that's mo- one of my favorite question and topics, uh, now, but the answer's gonna be different on whether you're an individual contributor or a leader 'cause you described, you know, both scenarios there. Um, as a, as a, as a leader, you actually have a lot of ability to influence change here. As an individual contributor, the main thing I'd say is you have a lot more ability than you probably realize. Uh, one of the things I've been talking about a lot lately is, uh, agency, sense of agency. Not enough people realize how much they can impact how their companies work because, you know, nothing's worse, and I feel so sorry for those people that feel like a victim. They feel like, you know, they can't do anything because their company sucks, and their leaders suck, and they can't, they just can't do anything. But really, there's a lot they can do. And I like them to take more ownership of what they can do. At a minimum, I promise it will help their career, at a minimum. At a maximum, it might actually change the course of their company. So there's a lot... There are factors outside of their control, but let's, let's... So let's answer that first for the individual contributor. So one of the most common questions I get is, uh, a product manager will say, "Okay, now I, I totally understand my situation. I'm a feature team product manager, and that's why I'm so unhappy." And so their question usually is, "Do I have to change companies if I want to have a real job, you know, be a real product manager?" And I, I, you know, I tell them, "Honestly, sometimes, but not usually." Usually, um, you can significantly incr- improve your role at your company, but it does take you taking some initiative to raise your skills. So, for example, the classic, especially in Europe, is to go from a product owner, which, as you probably know, has had almost no training in product, but they do know one or more delivery processes like Scrum or Kanban. So they're r- they're raising their skills from a role and a process to a real job. Now, that means they, they do some work, like you both have done, like I did, which is we go learn what a product manager really is. [chuckles] And what does that mean? And we have to go talk to a lot of customers. I remember the person who was coaching me wouldn't, as a new product manager, would not let me make a single decision until I visited in person 30 customers, 15 in the US, 15 in Europe, and, and it was the best thing I ever did. And, uh, and that, that was not the end of my customer visits, that was my start of my customer visits. But when you... You can't do the job of product manager if you don't deeply engage with your users and customers. Another big thing that I didn't... I just... I was an engineer that moved into product, so I had some skills, but not many. Um, so for example, I knew nothing about the go-to-market. I knew nothing about the marketing, the sales, the service, how our products actually made it into the hands of customers. I knew nothing about the financial analytics, the cost structure, or the monetization, and all that I had to learn. I was able to learn that and all, all of it in less than three months. Most people can't, but it does take a willingness. And I remember the person who was coaching me, the first question he asked me was, "Are you willing to put in the effort to do what I tell you you need to do?" 'Cause if I had said no, he was gonna say, "Well, I'm not interested." 'Cause he wasn't getting any extra money to coach me. It was just part of his... He was doing it as a good citizen, as a leader in the company. And, um, and I said, "Absolutely." I wanted to, genuinely wanted to learn this. I'm like, "You s- tell me what I need to learn, I will, I will do everything I can to learn it." It doesn't take that long, that's the ironic part. It really doesn't if you're sort of pointed in the right direction. Now, I was super lucky to have somebody who was amazing at product coach me on this. But today, there's a lot more. Now, this is separate from the issue of the noise we were talking about before because unfortunately, the vast majority of resources I see out there, and you know I'm not including you two in this, that's why we're doing this call, but the vast majority of the resources are just trying to help people become a better feature team product manager, which is not useful. So what I want to help them do is become a real product manager, defining real as how the best companies actually do this. And that means they have to do some work. They have to learn the customers. They have to learn the data. They have to learn the business dimensions. They have to learn the industry. But you can all do that, and what I tell individuals is once you've done that, at a minimum, your com- your leaders, your manager will recognize that all of a sudden, you know a lot more than you did before, and by the way, what the things you know are incredibly helpful. I've seen people get promoted just from that. [chuckles] And then, of course, now they're in a product leader position where they can now influence more than just this. But to your original question, what can an individual do? They can raise their skills. The next thing they can do is try to win the hearts and minds of their own team. So that means going to your designer, going to your engineers, and helping them, uh, see the advantage of working this way. Now, most designers and engineers, in my experience, are not the problem. They were trained to work this way. [chuckles] They're, they're frustrated they haven't been able to, but one way or another, you need to get, get on the same page with your team. So as an individual, you can do yourself, and you can do your team, and then you can start showing your company what you're capable of.

    2. AG

      Today's episode is brought to you by Gibson AI, the future of backend development. Imagine designing, deploying, and scaling your database as effortlessly as having a conversation. With Gibson AI, that's now a reality. Gibson AI is your AI-powered database engineer. In just minutes, you can chat with Gibson to create production-grade data models, deploy them on Gibson's cloud infrastructure, and instantly generate secure REST APIs. Connect to your front end directly to your Gibson-built database or drop the API specs into Cursor, v0, or Bolt to build a full stack application seamlessly. From idea stage to millions of users, Gibson scales with you. Gibson optimizes your database as you grow and enables easy schema updates and migrations. So head over to gibsonai.com/aakash. That's G-I-B-S-O-N-A-I.com/A-A-K-A-S-H to sign up for free and experience the future of automated data modeling.

  9. 30:56 – 34:34

    What product leaders must do: coach PMs, seek coaching, and build strategic context

    1. MC

      Now, you have to do that in a responsible way so you don't just ignore the roadmap. It's just that you start doing a lot better job delivering what's on that roadmap. So, um, once you... That's, that's what I recommend for the individual. Product leader, of course, has a much bigger span of impact there. They now can raise the skills of their... The f- their first responsibility, if you're a product leader, is to raise the skills of your product managers. In fact, I tell product leaders that they will be judged by their weakest product managers. So they need to take that personally, and that needs to be their job, their responsibility. Now, the biggest issue most of them have is they don't, they never worked this way. So they don't really... They, they know they need to get good at this, but they don't know how. That is literally why I wrote the book "Empowered," was to share... The biggest section in "Empowered" is on coaching, and it tries to share this. So I, I usually encourage those people just take one chapter a week, do one-on-ones with your people, raise their skills, and you're raising your own skills at the same time. The other thing that can help is an experienced product leadership coach. You may know that over the last couple years, uh, my partners have, uh, and I have been, uh, reaching out to meet a lot more product coaches out there because we get asked to introduce and refer product coaches almost every day. And we had a few that we've known for a long time. Teresa Torres is wonderful. Jeff Patton is wonderful. We've been recommending them for many, many years, but we overwhelmed them a long time ago, and so we needed a bigger network. Today, we have a network of about 50 product coaches around the world that we think are good. We don't have any money relationship with any of them. We don't want many money relationship. We just want to know which ones are good. When I say good, I'm talking about the people that I know have been there, done that at a good product company and can genuinely help another company get there. And today, there are good coaches in most parts of the world. I'm hoping to see that really grow and be more, uh, more like that. Um, because if you're a product leader that's got this responsibility but you've never done it before, then a product leadership coach is probably your best bet for quickly coming up to speed.

    2. PH

      I love the point about, uh, I can cut it. I ca- I, I love the point about, uh, taking the initiative as an individual because, uh, at the end of the day, mm, I think this is what leadership is about, that you do not necessarily need to influence other with having formal authority. And if you can do that just by, um, acquiring new skills and, uh, winning the minds and hearts of, of people around, that's even better.

    3. AG

      I like the concept you kind of talked about, which is basically like your inside world and your outside world. And like as the VP of product, I think you can be a little bit of a shit umbrella. There's still infinite company-wide planning processes, OKR processes, but you don't necessarily need to subject your company to those waterfall processes. You can actually fill all those forms for them and you can tell them, "Hey, you go be empowered. You go do continuous discovery." And so I think just identifying kind of your sphere of influence, the areas where you are able to make decisions and then the areas that you're able to cover them is a really effective way as you move up the ladder.

  10. 34:34 – 37:38

    Selling the transformation to the rest of the company—and why leadership alignment is key

    1. MC

      You know, it's, I don't mean to make this sound easier than it is because the product leaders especially, the, within the product organization, in my experience, it's not that hard. I mean, if you do your job, most of the people want to work the way we're talking about. There's some, but most don't. Most are very enthusiastic about this change. The bigger issue is the rest of the company. And, you know, the rest of the company has never worked this way before. They don't really understand. They're, they're worried about losing control. They're worried about losing, you know, what happens if I'm still accountable to the numbers but I don't have this inf- you know, this same influence I had before? So the real nuance comes to these product leaders to win over the hearts and minds of the rest of the company, especially the key stakeholders and the key executives, and that takes building trust and sort of being very smart about picking your battles. Um, what, you know, you can go in and say, "We're not gonna do any of this stuff anymore, and if you don't like it, tough luck." That doesn't go over well in most companies, uh, especially if the CEO is also nervous, which most of them are. So what we wanna do is work a lot more s- you know, gently with those leaders to understand, like, "Look, are you also frustrated that you keep funding all these features and they're not generating the results you want? So am I. How about we do some experiments together to see if we can't do this better for you, literally for you?" And they, you know, not many of them are gonna... Most of them are gonna be pretty excited about that possibility because this is a very different framing. In fact, that's why we chose the term product operating model. As you know, most, a lot of people like product-led company and product-driven company, but, you know, when you talk about the, to these stakeholders, they do not like those terms. And it's not hard to understand why.

    2. AG

      Yeah, I think that labeling it and being, having a, the truly, um, influential product leader, that's kind of the real rarity amongst those five requirements you mentioned that a lot of these companies are struggling with. If that product leader hasn't lived it, then they can't influence it. It's a very tough process for some teams.

    3. MC

      Well, in fact, I would argue that the real key to successful transformation, there's a lot of things that have to go right, a lot of things that are hard, but the real key are those product leaders, especially the head of product and the head of engineering. If those two leaders do what they need to do, the company has a real solid chance at succeeding on this. But if they don't, it's almost impossible.

  11. 37:38 – 42:20

    Pilot teams and a transformation story: Trainline’s turnaround

    1. AG

      Yeah. Could we maybe go into a specific example or a case study where you worked with, um, maybe like a head of product and head of engineering, and how did they, how did they approach it? How long did it take them, and how did they, um, did they... I've heard you talk about in previous interviews, like finding like maybe like a set of teams even where they, um, piloted in. Is that like the approach you recommend, or how do they go about that one to two year strategy of transforming their company?

    2. MC

      Yeah. And pilot teams are one of our core techniques that everybody, you know, it's a smart idea. Instead of rolling it out to a whole company, you know, it's just like an AB test, but on the organization instead of on your product. Uh, right? You, you're taking a small group, you're letting them run this, and even if everything goes perfect, and it never does, but if, uh, even if everything went perfect, the rest of the company is able to observe. And you know how people are. Some people hate change, some people need time for change. This is, uh, pilot teams really help companies, uh, get through that. But to your question, so, um, in, in, uh, one of my favorite examples in the book is, uh, the company in, based in London called Trainline. Trainline, uh, if you ride the trains and in fact, a little known fact, Monday through Friday, Trainline's app is higher rated than Uber. That's how popular it is. And Trainline a few years ago was, was nothing. It was, uh, it sold some tickets, although they didn't even have a mobile app. It was all, uh, you'd have to go to a laptop or something and, and buy a, a ticket, but it was nothing in the industry. And, uh, one of the big private equity firms decided that that's crazy. That should be an amazing tech-powered company. And so they bought the company, and the first thing they did, this is normal when, when it's a private equity firm, is they brought in a CEO that knew what she was doing. They brought in a woman named Claire Gilmartin. She had come from eBay, and they said, "Look, you turn this around. Uh, set it up like you would set up a product company." And, uh, the first thing she did was she brought in a head of product and a head of engineering. Now realize in that case, they had almost nothing. It was all outsourced. It was all obsolete tech stack. It was very small number of developers, and like I said, most of them weren't even employees. They were remote. It was, um, you know, not what we're talking about. So she brought in the two leaders, and the three of them got to work. Now, it normally takes somewhere between one and three years to transform, depending on the size of the organization. This was like a mid, mid-sized company. It was a real enterprise. It had been around several years, but it was, you know, it was not designed around, uh, the principles we're talking about, so these leaders had to introduce those principles. They started by looking at the staff they had and, uh, seeing which ones wanted to learn how to work this way. Um, and there was, uh, a few engineers that were on staff and wanted to. That was fine. There we- but they had to do a lot of hiring. And then same with product. There were more that Jonathan... The head of product was a guy named Jonathan Moore, who's, uh, uh, I've known for many years. He is, um, in fact, he's now a partner at SVPG, uh, Jonathan. But, um, Jonathan had led the transformation at The Guardian. Many of you know The Guardian. He, I first met him as a brand new product manager at the BBC, where he was responsible for one of the most famous properties today, uh, BBC News. So, um, it's, uh, Jonathan and, uh, his head of engineering, they got to work putting these things in place. You heard me say the, the two big responsibilities of these product leaders are developing their people, hiring, coaching, and then developing the strategic context. In this case, the product vision, the product strategy, the team topology, the architecture, and they got to work and they, uh, after about three years, they became the UK's biggest IPO to date at, as of that date. Uh, that's why you transform. And by the way, they went from nothing to literally one of the country... Now they're all over Northern Europe too. It's not just UK. But, um, to one of the favorite apps. You talk to people in London, ask them for their top three favorite apps, it usually includes Trainline.

  12. 42:20 – 49:33

    Coaching product leaders—and the anti-patterns of hiring the wrong coach

    1. AG

      I have a related question. [chuckles] 'Cause Marty, you mentioned that, uh, the CEO brought the head of product. So is it possible to coach a product leader that doesn't have a product experience as a individual contributor? So what would be your advice?

    2. MC

      And some of the... Yeah, no, that, that's a fair question because one answer is like, like Claire did, just go recruit somebody strong and let them do it again. That's one answer. The other answer is if your company has leaders that they think are good... In fact, another story we told in the book is a company called CarMax, uh, and CarMax is, uh, the biggest used car sales company in the US. They're based in the other side of the US on the East Coast, and not a technology center, and they're a car sales company. They're not, they weren't born a tech company in any way. But they had strong people that they believed could be coached, and that's exactly what they did. Uh, in fact, I was one of those people helping, but they had other people helping as well. Um, and these are people that had the right mindset and the right sort of motivation. They just didn't have the experience, and that's why I was saying that in many cases, a product leadership coach is very much what you need. By the way, there are also CTO coaches that do the same thing for engineering leaders. They, um, that's what they do. They are, you know, somebody who may have been an IT manager but now wants to become a technology, you know, head of engineering, and so those are different skills, and so they learn that. That's the main... Those are the two main ways I know. You either bring in people that have the experience or you, you have a leadership coach that helps them learn the experience on the job.

    3. AG

      How have people messed up hiring a coach, in your example? Like, what, what's the anti-pattern? What should they avoid?

    4. MC

      Well, by far, and I am worried about this, I'm always worried about this, by far the biggest problem is that they hire a coach because the person says they're a coach, [chuckles] but they don't actually have the experience. They've never actually done product, uh, at a serious company. The biggest example of this I know, the single biggest example, and I, this is very frustrating, is the vast majority of people teaching CSPO and PSPO classes. In other words, teaching product owners have never done product. They are just agile coaches that have been trained in a method like Scrum or worse, and, uh, they think they can train these people. [chuckles] And what they're really teaching them is like, "Okay, you have to use Jira to prioritize a backlog." That's not product. That's administration. That's why they're called, you know, these are backlog administrators. So what we need are people who actually know product to teach product, to coach product. And so I, you know, you, there's no way in a, in a relatively free market world, there's no way to, to, for anybody, I think, to stop someone from saying, "I'm a product coach." [chuckles] Uh, to me, the only thing we can do is try to educate the consumers, educate the, the people at a company that is hiring these coaches and try to help them understand what to look for. So I did something unusual in the new book, "Transformed." I was so worried about this. I am so worried about this because if, if... What does it mean to be an agile coach today? Almost nothing. If that same thing happens to product coach, we lose. So I was so worried about that, I decided to profile seven real product coaches in the book, and I do this because I want people who want to transform to be able to get a really good idea of what good looks like. And every one of them has serious experience doing product at a good product company, and they care about coaching. One of the problems we have, I probably shouldn't even mention this one, is just, uh, I know that, uh, you're bo- you're both based in Europe, right?

    5. AG

      I'm, uh-

    6. MC

      I think so

    7. AG

      ... I'm from-

    8. MC

      No? Akash, where are you?

    9. AG

      Pawel is in Poland, yeah.

    10. MC

      Poland? Yeah.

    11. AG

      I'm in North Carolina, and I spent 10 years in the Bay Area.

    12. MC

      Oh, North Carolina.

    13. AG

      Yes. [chuckles]

    14. MC

      Not exactly Europe, sorry. Um, but you are not that far from, uh, CarMax is in Virginia.

    15. AG

      Yes.

    16. MC

      But, uh-

    17. AG

      I have chatted with a couple PMs, they're readers, yes. [chuckles]

    18. MC

      But, um, in Europe, there is this whole, uh, there is a big, you know, there's a big movement around coaching, but for, for that movement, coaching is a different thing. It's, uh, it's some... And, and don't get me wrong, it's good, but it's not the kind of coaching that these people need. If, if they, they talk about, you know, sort of career coaching, life coaching, that's nice, but that's not what this is about. I have never met a coach like that that could actually help you do a good product strategy. Sorry. They can say all the nice things to you, and they can make you feel good, but that doesn't help you do a product strategy. [chuckles] So, um, there are some softer skills that those people could probably help you with indirectly, but I would much rather have a proven leader that has already worked with these kinds of stakeholders and can help you tangibly to do this. So this is an especially sensitive topic in Europe because there they have a very different definition of coaching, and I don't know what to do about that. You know, in the US, we have a very strong institution about coaching, the famous book, "Trillion Dollar Coach," about Bill Campbell, and really what differentiates a coach- And I think this is the part that surprised me about Europe. Europe loves football, as everybody knows, and a football coach is not a touchy-feely person. A football coach is there to help you be an amazing football team, help you develop your skills. If you go to a golf coach, you're expecting them to have deep knowledge about the mechanics of golf and could help you with that. They're not just about, you know, helping you have a good attitude or something. So anyway, we need people that know how to do things like coach other product managers, that know how to do things like a real product vision and a real product strategy. That is probably the key to successful transformations at scale.

  13. 49:33 – 52:52

    Are the principles optional? Why principles endure while methods change

    1. PH

      There are 20 principles, is that o- correct, in the book? So how should we-

    2. MC

      Right

    3. PH

      ... interpret those principles as best practices, as something that works or works in most cases? Or can we break some of those principles depending on the situation, or all are required to, to have a good product organization? So [laughs]

    4. MC

      No. No, it's a good question. It's a hard question. Um, I, I... You know, when you look at this, the craft of product over the last 10 years, 20 years, 40 years, I don't know how b- far back you wanna look, in some ways things have not changed much at all. In other ways, they've changed dramatically. I would argue the things that have not changed much at all are the principles, and I would argue that things that have changed dramatically are the tools and methods of applying those principles, dramatically. Product is so much... The tools to do product today are so much better than when I first learned. But interestingly, the principles have ver- barely changed. My belief is that the principles, if they're really true product-first principles, then they're probably very durable. And it's worth pointing out, a principle doesn't say how you do it, it just says that you need to do this. You need to find a way. For example, one of those principles I already mentioned was an experimentation culture. Well, as you know, the tools and techniques for doing experiments have gone from very primitive to very advanced. So w- but we still do experiments. They were harder before, but we still did them. But the point is not how to do those experiments. I have different advice with every company. When I'm working with a device company, it's very different on how to do an experiment than when I'm working with a pure software company. But they still need to do experiments. In fact, the, the counterintuitive thing is a device company has to do more of them because the co- the, the downside of messing up with a device is much worse than if we mess up in software. So it-- that's where the differences, I think, really are. Now, will new principles emerge? I don't know. Probably. Uh, but I don't think it will over the next couple years. I think those principles emerge very slowly, um, if they're really principles, they're, they're, they're lasting. When I look at the principles in the book, it's hard to, um... I mean, I, I'm... I would say they always have existed. They more s- principles speak more to the nature of technology-powered products and not about the particular frameworks or process or methods. Those change constantly and, um, and to me are much less important.

  14. 52:52 – 1:01:27

    Rapid-fire closing: books, cultures, products, and “product management theater”

    1. AG

      What's the f- your favorite book that you've read recently?

    2. MC

      Well, do you mean work-related or not work-related?

    3. AG

      That reflects a lot about you, which you choose. We're curious to see. [laughs]

    4. MC

      Well, I, I read a lot of work-related books. Um, but I love reading. But, um, I would say my favorite work-related book recently is "Build" by Tony Fadell. I actually have it here, um, 'cause I really enjoyed that book. Here it is. Um, so-

    5. PH

      Yeah

    6. MC

      ... "Build" is talking... Oh, yeah. Pawel's got it too.

    7. AG

      [laughs]

    8. MC

      I hope you liked it too. But it's talking, it's describing the product model. The difference is he worked in hardware companies, and I mostly worked in software companies. Uh, and, uh... But he has... You know, he was in the right place at the right time. He got to work on the original iPod. He got to work on the iPhone. He got to work... He started the company Nest. And I love device products, I really do. Um, I started my career at a hardware company, so I love those kinds of products. But it was really fun reading his, uh, first-person account of this. Uh, and he s- you know, came from a designer engineer to a CEO, so he's got great perspective. I thought that was a very good book, and it was interesting because he... The subtitle of the book is An, An Unorthodox Guide to Making Things Worth Making. But when you read it, the reason it's unorthodox is because it's not about any of the modern processes or anything like that. It's all about the principles.

    9. PH

      Yeah. Uh, so Marty, what's your favorite product culture?

    10. MC

      Favorite product culture? Oh, that's a hard one. Um, uh, I mean, I, uh, [laughs] I'm kind of a student of product culture, and I see... I've got pretty good at spotting the good and the bad in each culture. I'd have to say if I could, um, the closest to my dream culture is probably Netflix. Yeah. Netfl- Netflix sets the empowerment dial even higher than really any other company, and they set it even higher than I normally even recommend. They sort of set the dial to 12 on a scale of one to 10, you know, so high. But I also am so impressed with what they've done over the years. Um, but there are... Honestly, there's things I love about Apple's culture, about Google's culture, about Stripe's culture. Stripe is, maybe that's the best answer. I mean, you look, they kind of created their culture out of the best of several other companies. Um, I don't know. I think there's a lot of, you know, there's some very good cultures out there and there's some, uh... You know, culture is very personal. So for example, there are some people I tell, "Uh, you will hate working at Amazon." I tell them, "Either you'll quit in the first year or they'll fire you in the first year," [laughs] because of their culture. Other people I say, "You were born to work at Amazon. You will absolutely love it there." And most of the time I'm right, just because I understand Amazon's culture and I understand, you know, if I know the person. But it's so personal, right? Because certain people, if I send to Amazon, I know they're gonna hate it. Amazon acts more like a startup than 90% of the startups I know. And, and a lot of people do not want that. Other people, that's exactly what they want. So it's a tough question because it's so personal.

    11. AG

      Totally. Um, what is the best product you've used recently?

    12. MC

      Oh, geez. Uh, I mean, I work w- I, I get to try a lot of products, but of course I try them for a lot of s- startups, and a lot of them have a lot of work to do. What would be a great example of a great product? I mean, there's... I, uh, I love motorcycles. I ride motorcycles. I own a couple. And the state of the art in motorcycle technology today has never been better, and the just the, the full product of what they deliver is pretty outrageously good. Um, I will tell you, uh, uh, I don't know why I've, uh, you just got me thinking about motor, automotive. I don't wanna buy a Tesla because of Elon Musk, so I bought a Rivian, which is, um, which is a very, very good product. They have done an a, a very impressive job. Um, there's a lot of overlap with a Tesla. The difference is the head of Rivian is really a designer, a product designer, and you can tell that in the product. It is a beautifully designed product, uh, that works holistically remarkably well.

    13. AG

      Amazing. Um, we're way over time, but last question I guess. What is your least favorite, this is the spicy topic, so we left it for last, your least favorite product concept that has popped up?

    14. MC

      Oh my gosh. You know, this is, this is a sensitive one because there's so many that really, uh, make me frustrated. I think, though, the thing that bothers me more than anything else is this, you know, the, the prevalent definition of product management, because I think not only is it not helpful, but I think it's the root reason so many people in that job are not happy. So that really does bother me, and I think what push... You know, I wrote this article recently that was very controversial called "Product Management Theater," and what, you know, I... We've seen these issues forever. It's not like they were new. But what pushed me over the edge was there was this article that made the rounds online by one of the major product certification programs that sort of certify product managers, and they described their job of the product manager. They had this big graphic and they said, "This is the job of the product manager." [laughs] And I'm looking at it and saying, "I can't believe they think this. I can't believe they say this. I can't believe people believe them." It's terrible, because all it did was describe a project manager, pure project management. And I'm like, all right, this is... And this is the major group certifying product managers. Okay, this is a problem. So that probably drives me nuts more than anything.

    15. PH

      The matter where p- people can find you?

    16. MC

      Well, yes. Um, well, I hope this was interesting to people. Um, you can find more of my stuff at SVPG, siliconvalleyproductgroup.com.

    17. AG

      Amazing. Well, thank you so much for being here.

    18. MC

      Well, thanks for inviting me, and, uh, uh, yeah, appreciate the, uh, dialogue, and I hope, encourage you both to keep doing what you're doing.

    19. AG

      What an episode. I hope you enjoyed that as much as me. Marty Cagan is one of those people that's made a huge impact on product management and growth and tech more broadly, and I think that what he's saying really resonates in early 2025. We need to move to a way of working where product managers, it's obvious the impact that they're making and how positive that impact is. And we need to move to this product operating model and these 20 principles, because these 20 principles are what's shown to have really worked for high-performing product and growth teams. So we're gonna get into a bunch more content like this in the upcoming episodes on the podcast. As always, please like, comment, subscribe. All those things really help the podcast, and we're gonna continue to make the best possible product and growth career content for you. See you in the next episode.

Episode duration: 1:01:27

In the uListen app, the transcript lights up word by word as you listen. Get uListen

Transcript of episode J0FOFJFtOFw

Get more out of YouTube videos.

Read along on your phone, search it beside the video, or ask your favorite AI app what was said.