Product management theater | Marty Cagan (Silicon Valley Product Group)

Marty Cagan (00:00:00):
There is no question that a lot of companies overhired during the pandemic. I go into some companies and honestly I can't believe all the ridiculous roles that they have, agile coaches and product owners and product ops and business analysts.

Lenny (00:00:13):
And this is essentially the theater you're describing, people that aren't real product managers.

Marty Cagan (00:00:18):
They're dramatically overpaid for the value they provide. Because it's a project management role. It is a lot easier to deliver output than it is to deliver outcomes.

Lenny (00:00:27):
What made you decide to write another book and what is it about?

Marty Cagan (00:00:31):
Too many people in our industry view themselves as a victim of their company, like they're stuck in a feature team and there's nothing they can do about it other than quit. I think that's not true. There is so much they can do.

Lenny (00:00:46):
Today my guest is Marty Cagan. Marty has been helping product teams and product managers improve their craft, processes and careers for over 20 years. He's worked with more product teams and more product managers than any human alive. He's also written two of the most popular books in the field of product management, INSPIRED and EMPOWERED, and this week he's releasing his newest book, TRANSFORMED. In our conversation, we cover some spicy and important topics. Where the product management field is going, the over hiring of product managers and adjacent functions, a trend he's noticed called product management theater. Also, why most product management advice you find online is giving you the wrong advice and why that's the case. Why many product managers are simply project managers and how to avoid becoming that person. Also, how to avoid hiring that person. What skills you need to work on and build to be an incredible product manager, especially with AI.

(00:01:43):
How to shift your team and company to be more empowered. Signs that you're working on a feature team and why you probably don't want to be there and so much more. If you care about the field of product management and where it's going, you'll absolutely love this episode. With that, I bring you Marty Cagan after a short word from our sponsors. And if you enjoy this podcast, don't forget to subscribe and follow it in your favorite podcasting app or YouTube. It's the best way to avoid missing future episodes and it helps the podcast tremendously. Let me tell you about a product called Sprig. Next gen product teams like Figma and Notion rely on sprig to build products that people love. Sprig is an AI powered platform that enables you to collect relevant product experience insights from the right users so you can make product decisions quickly and confidently.

(00:02:34):
Here's how it works. It all starts with Sprig's precise targeting, which allows you to trigger in-app studies based on user's characteristics and actions taken in product. Then Sprigs AI is layered on top of all studies to instantly surface your product's biggest learnings. Sprig Surveys enables you to target specific users to get relevant and timely feedback. Sprig Replays enables you to capture targeted session clips to see your product experience firsthand. Sprig's AI is a game changer for product teams. They're the only platform with product level AI, meaning it analyzes data across all of your studies to centralize the most important product opportunities, trends, and correlations in one real time feed. Visit sprig.com/lenny to learn more and get 10% off. That's S-P-R-I-G.com/lenny. This episode is brought to you by Eppo. Eppo is a next generation AB testing and feature management platform built by alums of Airbnb and Snowflake for modern growth teams.

(00:03:36):
Companies like Twitch, Miro, ClickUp and DraftKings rely on Eppo to power their experiments. Experimentation is increasingly essential for driving growth and for understanding the performance of new features, and Eppo helps you increase experimentation velocity while unlocking rigorous deep analysis in a way that no other commercial tool does. When I was at Airbnb, one of the things that I loved most was our experimentation platform where I could set up experiments easily, troubleshoot issues, and analyze performance all on my own. Eppo does all that and more with advanced statistical methods that can help you shave weeks off experiment time, an accessible UI for diving deeper into performance and out of the box reporting that helps you avoid annoying prolonged analytic cycles.

(00:04:19):
Eppo also makes it easy for you to share experiment insights with your team, sparking new ideas for the AB testing flywheel. Eppo powers experimentation across every use case, including product growth, machine learning, monetization and email marketing. Check out Eppo at geteppo.com/lenny and 10X your experiment velocity. That's getE-P-P-O.com/lenny. Marty Cagan, welcome back to the podcast.

Marty Cagan (00:04:49):
Thanks very much Lenny. Thanks for inviting me back.

Lenny (00:04:52):
Thank you for coming back. So our first episode together is still one of the top five most popular episodes of my entire podcast, which is wild because the podcast was much smaller back then. You've also got a book coming out. We're going to talk about that. You've also been getting a lot more spicy in your writing as of late. You've been writing about product management theater and product leadership theater and all these sorts of things. So I'm excited to dig into a lot of these things. I thought I'd start with just asking what is driving this recent spiciness in your writing?

Marty Cagan (00:05:23):
It's conscious. I find myself, I'm aware of myself dialing up the rhetoric around this stuff. I've actually been saying these things for a long time, honestly, and it's on the record. You can read the blog articles from 10 years ago, 20 years ago, but things are changing. And first of all, I should acknowledge, I don't know if you're this way Lenny, but most product people I know like me are paranoid. So we're always worried that things are going to come and just take our customers away and disrupt our products. And so I know that there's a degree of that. I'm always looking at what are the things that could really shake things up in a good way but also in a bad way? And there's been a number of things I've been very worried about for a long time and I think that there's a convergence of factors that are going on and one of the challenges is it's simultaneous.

(00:06:22):
So there are a number of things happening in parallel, which is a recipe for some chaos and a lot of fear. And in the product community, in the design community, in the engineering community, it's there. You can see it. And like you, I talk to people pretty much every day. So I do have a lot of theories about why this is going on and what people can do to best protect themselves, their career, their companies. And so I'm happy to share that, but it's not small. It's not a small set. Maybe before I get into it though, I realize that people should understand where I'm coming from and how it's different than where you're coming from because this perspective... Just to be clear, I think we're both trying to help the product community, but we're trying to do it in very different ways.

(00:07:18):
And I want to be clear, I love the way you do it. In fact, if people don't know, I'm a paid subscriber to yours because I find it incredibly useful for what I want to do. So let's talk about that. You obviously could describe what you do better than anyone, but my take is that you are, and this is what I find valuable, you're sharing a broad range, increasingly broad range of perspectives, people, ways of working, ways of doing products, experiments with the product model, experiments in leadership. I love that. It actually helps me a lot. That's why I subscribe. And I'll be honest, the main reason I took some prodding for me to... I know there's something about actually paying for a subscription when there's a hundred different product related newsletters and stuff, but what happened was you have a lot of subscribers and people that I know would see something and they'd email me and they'd say, "Did you see what Lenny was talking about with Lenny or with whoever? And how do you explain that? What do you think is going on?"

(00:08:29):
And it made me want to watch a lot of these. Some of companies I know, but other ones you've introduced me to that I don't know anybody at. So to me that's incredibly valuable. It's a whole lot easier than the way it used to be, which is a whole lot of traveling to a lot of companies. So I love that. You are helping so many people to get a broader understanding of product. My goal is different, the SVPG. We are also trying to help the product community, but it's interesting when I watch your interviews, you're trying to pry out of people what's special about what they do, which is what I want to hear. But interestingly, what I'm looking for is not what's different, it's what's the same. What we are all about is sharing the principles and the practices that are used consistently by the best product companies. In fact, we have a heuristic, we've never made a secret of this.

(00:09:27):
We are always asked about new techniques and new methods, new processes and we're like, "Look, we need to see it being used by at least several of the companies that have proven they can consistently innovate." If those companies can use it productively, we're all about evangelizing that. We make this clear in every one of the books. We don't invent any of these things. We just, if they work, we like to talk about them. So we are looking for the commonality and mostly we're looking to help a company, whether it's a startup or a large company to have the best possible chance of success. That's the goal for us. It's a different goal. You can see that. So all these data points become interesting as data points, but we're looking for those things that last and you never know. You have to see.

(00:10:25):
For one, I love working with startups, but as you know, a lot of startups are dominated by the founder and the early people and it almost doesn't matter what techniques they use. If they're good, it's amazing what they do. That's just amazing. And so that's probably important to get out of the way.

Lenny (00:10:44):
Yeah, I love this.

Marty Cagan (00:10:45):
Bringing that perspective.

Lenny (00:10:46):
I agree with everything you said. I think we are very different in what we're providing to the product community. And it's interesting being on this side of the microphone is I built a lot of empathy for journalists. I know the Brian Chesky episode is a good example where there's a lot of things there that might sound problematic and you disagreed with. And as me interviewing him, the challenge I have is I have an hour with him and I have to always decide, do I go and push back and try to, hey, is this actually working the way you're describing? Is this actually the right way to approach stuff? Here's why maybe you would not. Versus there's so many things I want to get to and ask him about this stuff. I'm like, oh, which way do I go? And then if I'm pushing back too hard, people are like, "I'm not going to go on this podcast where he is just questioning everything I think." So it's a really interesting role.

Marty Cagan (00:11:27):
I think that's totally fair. And also, I don't think you want to scare off your guests. This is really the platform they have to share what they think is important. I do always find it entertaining because a number of the companies you profile I already know, and it's always fun to hear them describe it versus what I see at their company because of course they're not always same, but that's just human nature. We all do that. And so anyway, I hope you continue doing what you're doing, Lenny, and I'll keep following.

Lenny (00:12:05):
Amazing. I appreciate it. And same to you.

Marty Cagan (00:12:07):
All right.

Lenny (00:12:08):
So with the writing, I think an implication with the way you're describing is basically you're telling people things they don't want to hear but they need to hear. That's the way you think about it, right?

Marty Cagan (00:12:18):
I do. In fact, I've got some very uncomfortable things to talk about, which I know the more intelligent part of me is like, "Don't bring that up." But also the other side of me is like, "But people need to hear it."

Lenny (00:12:36):
So let's talk about it if people need to hear it, which I agree. So you've been talking about this concept of product management theater and product leadership theater. Let's get into it. What does that look like? What is the sign that you're in this theater versus doing it the way you should be doing it?

Marty Cagan (00:12:48):
There is no question that a lot of companies overhired during the pandemic. That was easy to see even while it was going on. And it's not just that they overhired, a lot of them lowered the bar. But at the same time, of course we have a change in the financial world that has really increased the cost of funds. And that's another thing going on simultaneously. And probably one of the biggest things of all, and this is the hardest because it's not happened yet, is the predicted impact of generative AI, right? I don't know if you saw, literally the CEO of NVIDIA the other day was saying don't learn programming.

(00:13:34):
First of all, I'm not even sure that's good advice, but the fact that the CEO of one of the most amazing companies in the world is saying don't learn programming, that's disruptive. And so at a minimum it creates uncertainty among the leaders in the companies, at a minimum. But honestly, I think there's very real impact. I'm convinced of that. I just don't know the real time horizon. I've got a long history of being overly optimistic. I think things are going to happen sooner than they really do. So I don't know when they'll really happen, but that's a big one. Here's another one that I think is not talked nearly enough about, and that is in a lot of companies, especially outside of Silicon Valley, team size has just gotten out of hand. I go into some companies and honestly I can't believe all the ridiculous roles that they have. And I'll go into that more if you want later, but no question that people realize that smaller teams can often produce more and better results.

(00:14:44):
How many of your guests have said as much? I've heard it from many of them. It's reducing the size of the organization ironically can get you a lot more in terms of results. So there's this general appreciation that maybe we overdid it here with all of these roles. And of course I'm talking about agile coaches and product owners and product ops and business analysts and all these assistant product manager types. So we'll go into that if you want, but it's gotten out of hand at a lot of companies. And then the one that I really probably shouldn't bring up just because it's become a religious topic almost. I know it's a super sensitive topic for people, but the reality is with remote employees, both velocity and innovation have taken a real hit. Now we can talk about, don't get me wrong, I don't think we're ever going to go back to the days of big companies having almost all co-located teams.

(00:15:49):
But there is no question, I work with a lot of them, they are all struggling with innovation and velocity. Things go slower and they don't really do that level of innovation that they used to do. And these are big factors, these are macro factors that are going on. And then on top of that, if you get outside of the Silicon Valley bubble, it's even worse because they have been investing at these companies, especially the big companies in all these extra roles. I mentioned agile coaches, but scrum masters and every flavor of project manager you could dream up, they're everywhere and every kind of assistant to product people. I think it's gotten crazy. In fact, I wrote an article a long time ago, something like a decade ago that was very popular at the time called Epic Waste, and I was pointing this out and saying this is crazy. The ironic thing is that the better companies do way more with a lot less.

(00:16:55):
So anyway, the roles. And then what about all the years that have been going on where they think these big companies think the answer lies in processes, especially things like safe, which outside of the Silicon Valley world is depressingly popular? And even though scrum, a lot of people don't even understand simple processes like scrum and they miss the point. So what's going on in so much of the world is they have so little in the way of outcomes to show for all this cost. And we talked about the sheer number of people becomes a problem and the amount of that cost can be shocking and the amount of waste is basically embarrassing. So it is not a surprise to me that companies are reacting to that. The bigger surprise honestly is it's taken so long for so many companies to realize what is going on.

(00:17:51):
And bottom line is today I think everybody, especially outside in those big process and role heavy companies, they need to take a hard look at how they build products and how they serve their customers. And they need to look harder at how the best companies do this with so much less proportional spend and so much more real return and really take a fresh look at how to best meet the needs of their customers. That's what transformation is about, is moving to work like that. And the ones that do that well I think are the ones with the best chance to survive.

Lenny (00:18:33):
I think there's just this broader trend of people just really dislike PMs in a lot of places. There's this just trend of I don't want PMs at my company, I don't want PMs at my startup. For a long time, we're going to have no PMs. It's like this general idea, and I think you're saying a lot of this comes from many people who were hired as product managers that are not good at the job and people's experience with PMs is those sorts of people.

Marty Cagan (00:18:56):
I think it's a different really answer. And I haven't gone into this, but you probably. Those examples, with very few exceptions, and I hear it all the time, almost every day, what you're describing, they're feature teams. And the truth is, and I've been saying this for a long time, the truth is they don't need PMs in a feature team. They don't because it's a project management role, Lenny, and they already have plenty of people who can cover that. And furthermore, a lot of times the engineers or the designers say, "We'd rather do it ourselves than deal with this person that's got this complex and trying to be the boss of everybody and they really don't contribute anything." So that's what's really going on in my view. They are either a delivery team or a feature team, usually a feature team in this model.

(00:19:49):
And I don't blame those people for not finding value in the product manager. They are just not bringing that value. They do bring a little value, in fairness, but, and this is very brutal, but they're dramatically overpaid for the value they provide. Now on the other hand, in a real product team, that's a very different job and I don't see that. In fact, I consider that complaint you're raising as the biggest clue that they're probably our feature team. And then I'll go ask them how they're working and what that person... And then of course the first thing I ask the product manager is how do you define your job? And I bet you've heard a hundred variations of the mealy mouth, squishy, I facilitate this and I do some communication and I herd the cats and I'm listening to that going, man, I would not want to try to defend that job to the CEO.

Lenny (00:20:46):
I know you talk about teams and product teams a lot. I imagine people still aren't 100% sure of exactly what you mean when you say that. So let's spend a little time on just what does it look like when you're on a feature team, feature factory versus an empowered product team?

Marty Cagan (00:21:01):
Well, there's a lot of clues for sure. Some of the easiest is on a feature team, you're basically given a roadmap of output. That's the key, is output. In other words, their features are projects that usually it could have come from an executive, could have come from a big pocket customer, could have come from wherever. But it's a bunch of features and literally you're being asked to design, build, test, deploy that feature. You're usually given dates and timeframes as well, but that's a feature team. You deliver. And don't get me wrong, that's still work, but that's output. It is a lot easier to deliver output than it is to deliver outcomes. And a product team, an empowered product team, instead of being given that roadmap of features, they're given problems to solve. Now they're customer problems or they're business problems or both, but they're given a problem to solve.

(00:21:57):
Usually one or two a quarter on top of of course the keep the lights on kind of work that everybody does, but they're given hard problems to solve and the measure is not ship the thing. The measure is it solves the problem. And that's why really the biggest difference between a strong product company and the rest is strong product companies understand it's all about outcomes. You just don't get points for shipping, you get points for delivering the value. A lot of the CEOs and CFOs I talk to, they resonate best when I frame it as it's about time to money more than time to market. We know how to do time to market. If you insist on time to market, we know how to do that. The techniques are well-known. The harder part is time to money and I know that's what they care about and that's harder and that's what a product team really does.

(00:22:51):
It's only when you sign up for an outcome that you have the needs for a product manager. I would say in the Silicon Valley sense, that's when you need a product manager. Because if you've been asked to solve these problems, that means you have to come up with a solution that's not only usable and feasible, which is what a feature team does, but is also valuable and viable. And that means you need a different set of skills that your engineers and your designers almost never have. That's not a knock on them. Those are very different skillsets. So now you need this person who understands the customers and understands the business deeply. That's where the product manager role came from. That's what they still at a good product company are responsible for. So that's a very different job. It's also if you have a person playing that kind of product manager, it is very unlikely they've got time on their hands to get in the face of the designer and start wire framing for them or start irritating the developers. They've got their own work to do.

Lenny (00:24:00):
And this is essentially the theater you're describing, that people that aren't real product managers doing product management activities, can you just talk about what that looks like?

Marty Cagan (00:24:09):
The biggest example of that is that they carry this title product manager because the whole world largely, thanks to you, knows it's cool, but they're not doing any of the role and they don't have any of the skills. Now of course, what really bothers me is it's not that hard if they are motivated. It's not that hard for them to develop the skills, and that's what I talk to people about. You can raise your game so that you actually can contribute at this level. That's what you should do for your own career, but by the way, and not accidentally, that's what your company needs you to do.

Lenny (00:24:48):
And for people that are listening to this wondering, what are these skills that I need to build to be a real product manager? I think you often say it's mostly focused on value and viability, and that's where a lot of this-

Marty Cagan (00:24:58):
Value and viability is what you are responsible for as a product manager, just like an engineer is responsible for feasibility, it has to be a solution that can be built and delivered. But a product manager is responsible for value and viability. Another way I like to frame this is on a real empowered product team, product manager is a creator, not a facilitator. I always cringe when somebody tells me, oh, my job is to say why? And I'm like, "Well, what do you do for the rest of the week besides the 10 minutes it takes you to say why?" It's ridiculous. People think that. But you know what? On a feature team, when you're scrounging around for some justification of your job, it's not that big a surprise. But no, the why actually comes from the product strategy anyway. You don't even do the why.

(00:25:45):
A product manager is a creator and so there's this side-by-side creation with design and engineering to come up with these solutions. Now, in order to do your job and represent value and viability, there are some real skills that are involved. First of all, you have to really become an expert on your users and customers. I know that I was not allowed to take the product manager role until I had visited 30 customers in person, 15 in the US, 15 in Europe. That was just the person who was coaching me. That was their rule. And all I know is those 30 customers changed my life because I thought I knew our customers and I really didn't. Another is you're supposed to be the expert on the data. How is our product being used? How is that usage changing over time? How is it being purchased? So that's big. Another big one is you are the person on the team that represents the compliance issues, the sales issues, the marketing issues, the financial cost issues, the monetization issues, go to market in general.

(00:26:51):
This is all legal constraints. This is all the product manager. Just think if you don't have this person on the team and you want to empower this team to make decisions, what are you going to do? You're just going to make it up? Or what they usually do is they call meetings with 20 stakeholders all in a room to try to decide these things, and now you've reverted to design by committee. So no, the product manager needs to bring this knowledge. They also need to bring deep understanding of the market. So when I describe these things to a typical product owner, they're like, "We're on different planets." What they learned in a CSPO or a PSPO class was how to manage a backlog in Jira, which to me is very analogous to learning how to operate Google Docs. Of course, that's not the job. That's something we do every day, but it's not the job just any more than...

(00:27:50):
Developers are in Jira every day. Does that mean that's their job? Of course not. Their job is to build. So this is what a product manager contributes. And really the distinction, if you want to think about it on a spectrum, a product owner is one extreme. And honestly, that is a role in a delivery process. That has no business being a dedicated person, really doesn't. And most teams I know, the senior engineer could do it better anyway. Second on the other side of the spectrum is what we're talking about, an empowered product manager. And then a feature team product manager is somewhere in between there. They do more than administer the backlog. They do a lot of project management. And don't get me wrong, project management is important, but it is not product management. And furthermore, in almost every company I see with feature team product managers, they have a boatload of project managers anyway.

(00:28:51):
So you could hear there's some exasperation in my voice because I feel like this has been quite clear for a long time, but most companies are deaf to this. They don't care. And I have theories about why, but that's kind of depressing. But for whatever reason, I feel like now I'm raising the volume because people are now seeing this the hard way because a lot of companies are cutting and these are easily among the most vulnerable people in a company.

Lenny (00:29:27):
Let me actually read a quote from you where you talk about this exact point. You wrote, "I have been warning for several years that delivery team, product owners and feature team product managers are likely to be facing a reckoning as companies realize that these roles are not what they thought they were. From what I can tell, that reckoning has begun and I'm expecting GenAI will only compound this."

Marty Cagan (00:29:48):
That's the pessimistic version of the world. Either I might be overreacting. Might be. I'm not really known for being alarmist, but maybe. It's possible. I hope so, but I doubt it. I think these trends are real. Now, does that mean people are... It's hopeless? They should all start retraining to be, I don't know what, housing construction, something that GenAI won't replace maybe? No. I think what really this does is you need to raise your skills. Enough with the silly facades of delivery teams and feature teams. You should raise your skills. And a lot of product managers, they reach out and they're like, "I know I'm in a feature team and I don't like it." I often use the phrase they're trapped in a feature team and they're like, "This isn't what I signed up for. The New York Times article about product management wasn't this. This was different." And they're like, "What should I do? Should I just leave my company and go to one of these other companies?"

(00:31:01):
And I try to explain that they actually have a lot more agency than they realize. There is a lot an individual contributor... Of course, there's way more than a product leader could do. And that's the biggest shame in all this, is they're not doing this. Most product leaders are not doing this 'cause they of course have a lot of agency, a lot of ability to change a company. But an individual can do it as well. They can raise their game. They can literally do a self-assessment and raise the skills from a product owner or a feature team product manager to a real product manager. At a minimum, I tell people, and I've seen this countless times, at a minimum, your company will appreciate it and probably promote you because you will be one of the few that actually understands these things. Hopefully even more than that, they'll say, hey, why don't we try running a set of teams this way and see how we do? So it can happen from the ground up too.

Lenny (00:32:05):
I imagine many people are wondering, how do I do this? I know you've written books, I guess there's courses, there's all kinds of things. If you could give people a couple tips of how to get better at this and what skills to focus on, what's a quick piece of advice you could share there?

Marty Cagan (00:32:19):
Well, this is maybe the most frustrating thing to me of all. And in fact, I should have answered when you asked me what motivated me to get spicy, what pushed me over the edge. Maybe I was in a bad mood that day, I don't know. But it was this article that made the rounds online by probably the biggest certification institution for product managers. And they had this big article saying, "This is what a product manager does." And it was a big graphic, and I'm looking at it and I was thinking, I cannot believe they said this out loud. This is 100% project manager, 100%. They didn't even pretend to put a little of the product, which most people of course are more creative than that. They bend over a little bit to make it look like a product manager, but not even close.

(00:33:11):
And what I realized is what's so frustrating here is you have all these people that realize things aren't good yet most places they turn are just propagating that same model. So these certifications, which in my opinion are bogus, but most people don't know. And just imagine you're a brand new product manager. You look online probably what, 90% of the content out there is from the feature team world or worst. And so unless they get really lucky or they happen to be really lucky and have a manager that is guiding them in a good direction, it just propagates. And you see this all over, articles, books, conference speakers, and a lot of times I can't even bear to watch. And it's not like there aren't great people out there who can speak. It's just that proportionally they're in the minority. So it's not as easy as it should be. Like you're saying, why can't people just go and learn?

(00:34:14):
They can if they're lucky enough to know where to go. Obviously I'm biased. You're biased too. We're biased on this, but people need to take more control of their career and really use their judgment, try to figure out what do you want to be if you want to be in the product world? What do you want to be? What kind of a product manager do you want to be? And if you want to stay, fine, but if you want to do this, then there are good resources for sure. There are good resources out there. And of course, I'm hoping more and more people do that.

Lenny (00:34:59):
I think that's such a powerful insight you just shared, that most of the content you find online about product management is, I think you called it 90%, or it's just from companies that are not doing it the right way, feature teams is the way you described it. Can you talk a bit more about that? Why is that the case? Why don't we hear more from great companies?

Marty Cagan (00:35:18):
In fact, one of the most frustrating things for me is community. One of the things that's great about community... You have one of the biggest communities today, but there's a lot of these communities out there in the product world, product sub communities. And the one I love about them is pretty much everybody you meet genuinely wants to help. Really everybody. The problem is somebody posts a question, happens many times every day, and the majority of the well-meaning people jump in with what they learn at their crappy company. And I'm looking at that and the person is, oh, thank you very much, now I know what to do. And I'm going, "Oh no, there goes another one." It becomes self-propagating. And what are you going to do? Is somebody going to try to police these boards, thousands and thousands of them, like a Lenny endorsed person or a Marty endorsed person? I don't want to do that. You probably don't want to do that.

Lenny (00:35:18):
No.

Marty Cagan (00:36:21):
It's a recipe for disaster. So there are so many reasons it propagates. Most of the books I see, I'm asked to review a lot of the books. I love it when it's an exception and it's like, wow, that's a good book. Teresa Torres's book, Continuous Discovery Habits, good book. Try to get everybody to read that. But that's the exception. And most of the time people are earnestly describing what they learn, not really what good companies do. So it's very difficult because these are not bad people. They're well-meaning.

Lenny (00:37:03):
Do you have any advice for somebody asking questions, getting answers, and having a sense of, should I listen to these people?

Marty Cagan (00:37:10):
It's very much this exists in the whole world, right? Buyer beware. You have to use your judgment. You have to think. Probably the most important skill for product people, and I know this sounds awful, but is really learning how to think critically. And that involves literally evaluating. I know I talk to people all the time when I help them for their interviewing. I say, "Look, the most important thing, you need to do some research on the manager that will be your direct manager. Do some background research. Go look at where they worked. It's all on LinkedIn. Check out those companies, check out that product. Make sure you are prepared there because that's what really matters. Not so much the company, but who's going to coach you." So there's a lot that people can do to prepare themselves, arm themselves, take more ownership of their career.

Lenny (00:38:04):
What's interesting, I'm sure you'll run into this and I'll just share something that I thought of. So while I was at Airbnb, I was reading your stuff and I was like, "Who works like this? He's talking about all these companies that are working in this strange way of just being given a roadmap." I'm like, "No way. This is not a thing. What is he writing about?" And it's because I was working at a company that does things well, and I know you disagree with where things have gotten. But anyway, so I imagine many people listening to this are like, I don't believe this is how a lot of companies work. What are you talking about? And then I also imagine there's a large percentage of people that work at a feature factory and they're just like, no, it's fine. It's not actually the way you're describing. So I bet this is quite frustrating for you.

Marty Cagan (00:38:48):
Yeah, I've experienced that 'cause I spent most of my career in that same bubble, and I was so surprised to find that people didn't work the way we did. I remember when it was too, because I was a developer at the time for developer tools, and I was building tools assuming that people were building like we built. And then I was sent out, I remember because one of the most eye-opening visits was my very first visit to Walmart's headquarters. And they were doing things so differently. They had just very different way of working, very different equipment, just everything. And it was a wake-up call. It was like, you know what? I'm living in a bubble. Silicon Valley is not like most of the world here. And of course I realized that why not? Why don't companies in Arkansas and India and everywhere else have the access to the same methods and tools and techniques? And so that became the inspiration for Silicon Valley Product Group, was to spread those things.

(00:39:56):
But I've had that exact conversation. I remember as you're saying it, the first time Shreyas Doshi told me the same thing. He was asking me, 'cause he had known me, and I'm like, "I know you write about this stuff, but I really can't believe people are doing this." And I'm like, "Shreyas, I wish it wasn't true." But he doesn't doubt it today.

Lenny (00:40:18):
Yeah, 'cause he is doing a lot of that work now too. I'm curious if it's okay for people to be on a feature team and just stick with it and be happy. There's actually this LinkedIn post today by this PM, [inaudible 00:40:31] Ben Erez who talks about how if there's a B2B sales driven company, maybe it's okay for it to be feature factory where people know exactly what you need to build. You build these things, it's fine. We don't need you to inform our outcomes. Thoughts on that? Is it ever okay to just be like, it's fine?

Marty Cagan (00:40:48):
Well, my first answer is this is not an accident why most B2B software is such crap. It is horrible. And of course, the ones that really stand out, they usually are not this way. So sales driven product, don't get me wrong. There's companies like Oracle that are massively valuable, driven with sales driven product, but do you really want to be Oracle or do you want to be SAP? Does anybody like those products out there? I don't know. I'm not sure I've ever met anybody that didn't hate those products. So no, I'd say that's just bad product. Now, I would argue that some of my favorite examples... In fact, in the new book we highlighted a classic sales driven financial services company moving to the product model and how it dramatically improved things for the sales organization.

(00:41:48):
So there's a bigger reason I think so many sales driven companies exist, is that most of the time in those companies, the CEOs are not product people and that's why they run that way. And until and unless the CEO decides this is not very good, usually because some good product company comes along and takes away their customers, that's probably not going to change.

Lenny (00:42:13):
Got it. So your feedback there essentially is sure you can operate this way. You're not actually going to build a great product and long term you're going to run into competition [inaudible 00:42:21]?

Marty Cagan (00:42:20):
The other thing I'd argue, Lenny, is an empowered product team can do everything a feature team can do and more. And once in a while I do hear somebody say, why isn't it good enough to be a feature team? How do you answer that really? To me, it is like, why are you in this business? Do you really not care what your customers think about your product? Seriously? I know I would never hire you if I had any say because that's one of the first things we want. We want people to genuinely care about our customers and about our business and making lives better for them. So I don't have a lot of sympathy for those people. I do know that there's plenty of resources for them, so they're fine. It's the people that really want to do better than that.

Lenny (00:43:16):
Reminds me of something your colleague Christian said on our podcast episode of how lucky are we to get to solve people's problems and help them?

Marty Cagan (00:43:24):
Christian is a living example of what we're talking about. Absolutely. He lives for these opportunities.

Lenny (00:43:31):
This episode is brought to you by Vanta. When it comes to ensuring your company has top-notch security practices, things get complicated fast. Now you can assess risk, secure the trust of your customers and automate compliance for SOC 2, ISO 27001, HIPAA and more with a single platform, Vanta. Vanta's market leading trust management platform helps you continuously monitor compliance alongside reporting and tracking risks. Plus you can save hours by completing security questionnaires with Vanta AI. Join thousands of global companies that use Vanta to automate evidence collection, unify risk management, and streamline security reviews. Get $1,000 off Vanta when you go to vanta.com/lenny. That's V-A-N-T-A.com/lenny.

(00:44:22):
I want to touch on something. So I interviewed the CTO of Meta, and you made this really interesting point. So when I think of Meta/Facebook, I always imagine them as a very bottom-up culture. People on teams build experiments, run things. There's not a lot of do this, do that, but the way that he framed it is it's actually very top-down at Meta. Zuck and the execs come up with here's what we're working on, here's our strategy, here's our big bets. And so he sees it actually as a much more top-down than a bottom-up team, but it seems it comes across as bottom-up, I guess. I know there's a difference between bottom-up versus top-down versus featured factory and empowered product team. But I guess thoughts on that?

Marty Cagan (00:45:03):
So first of all, I would argue what he described is exactly what I see in good product companies, exactly. But we don't frame it as top-down. Top-down is really means something very different. In fact, handing a team a roadmap of features, that's very top-down. Another very common misunderstanding, which comes, again, a lot of the agile coaches, they have misguided so many organizations, but product teams don't do product strategy. Product leaders do product strategy. They need to do the product strategy. And look, I'm not the biggest fan of Meta, but Zuck is very good at product, very good. That's the problem in the world. He's so good at it. But that is the job, is to make these strategic decisions, the focus decisions, the bets you're going to place. But then in a good organization, you give those bets to the teams and you really do give them latitude to figure it out.

(00:46:08):
And honestly, it's been a while since I worked with Facebook at the time, but they had very good teams, very good product teams, serious cross-functional, serious engineers, serious product managers and designers, and they could solve very hard problems and that is what made them good. So I don't frame that as top-down. I frame that as product leaders doing their job and product teams doing their job. It's a very common misunderstanding that many people have about what empowerment even means. Empowerment does not mean you set up this product team and they go decide what to work on. No, that would just be anarchy, right? You'd have 50 teams doing 50 things. Instead, empowerment means the leaders do their job, come up with the bets, and then the teams are able to figure out the best way to solve those problems.

Lenny (00:47:06):
Awesome. That's a great clarification. I think a lot of people don't totally get that. So this is actually really helpful, I think, for a lot of people. Speaking of Meta, there's another product leader at Meta. He was actually one of the former guests and actually also one of the most popular episodes, Nikhyl Singhal. And he works with a lot of CPOs and heads of product at companies. The way he described it, he's noticed there's this reboot in what the PM role has been over the past couple of years because of the end of the [inaudible 00:47:31] era. So the way he sees it is for the past decade, PMs are mostly responsible as growth people. They're growing existing products, they have product market fit or they think they do and they're just optimizing, scaling. And now that the money has gone away, there's a return to building, finding product-market fit validation and discovery. I'm curious if you see that. Do you see a shift in what PMs should be doing in the last couple of years post [inaudible 00:47:58]?

Marty Cagan (00:47:57):
So yes and no. I think he's right in general, but there's a really important nuance. Many teams that aren't very good yet, they do exactly what he described. He describes as a gross hacking, I describe it as optimization. All they're doing is these low risk simple experiments. They live behind the AB test of just doing like, we're going to change the call to action here and maybe more people will register, that kind of test. Should they do that? Absolutely. Is that product really? Not really. That's not discovery, that's optimization. Now, in many companies they do that because they're given a roadmap of all the features. So all they can really fit in are these little optimization tests. But in others, they're scared to do anything else. They literally don't want to break it. And so I find that situation that he described in many companies that need to transform.

(00:48:58):
So I would argue what he's probably seeing mostly is a team that's learning how to go from a feature team to a product team. Now, has that happened more in the last two years? I would like to believe so, but I don't know. Some days I feel like yes, he's right. Some days I feel like I don't know who he's talking to because these people are still stuck doing optimization work. And so there's probably a lot of nuance there. In general, I think yes, but I don't think it's tied to interest rates. I don't think it's tied to that. I think it's more tied to the quality of the leadership and the need of the business to do more than optimization.

Lenny (00:49:44):
I know people ask you this all the time, but I'm curious, is there anything big you're seeing change in the PM role broadly?

Marty Cagan (00:49:51):
We've talked about quite a few big dynamics that are changing. Interestingly, what we're really been talking about is the different definitions of the PM role. And so if we hold one of those definitions constant, let's say we are focused now on the empowered product manager, the one you and I grew up with, and those are the ones that are responsible for value and viability. In general, I think the principles are stable and I think they will remain stable. However, the techniques are undergoing some radical changes, especially with generative AI. Don't get me wrong, I've been living this every day as most of us have. I don't have it figured out. In fact, I recently changed my advice because I used to say, start with ChatGPT, go from there and I'll help you make that great. We'll go from there.

(00:50:48):
And what I kept seeing was people taking what they get too literally, too seriously, too much value, and they were heading off in a wrong direction and then they were optimizing that. There's a lot going on right now. It's a moving target. Depends which system you're using and the day of the week now on what you're at, but whatever. Now I've been recommending to people that they think through the answer first. Really get them to think, put something down, then use ChatGPT to see if you can't improve on that, to see if you can't challenge that, to see if you can't make your argument tighter. So I've reversed and I did that because people are trusting the results too much.

Lenny (00:51:43):
And when you talk about what they start with, is it like, here's a strategy I'm thinking for this product, or is it like a PRD [inaudible 00:51:48]

Marty Cagan (00:51:47):
Yeah, certainly you can use it for a spec, a PRD. You can certainly use it for strategy. You can certainly use it for even things like triaging bugs. It's hard to think of something you can't use it for. The harder question is what is it good for?

Lenny (00:52:07):
Something along those lines I wanted to chat about. Something I've been thinking about. I want to write a post about this, is which skills of a product manager will be most disrupted by AI? So I think short term, there's communication is getting improved. You can improve your writing strategy. Maybe like here's my strategy, give me some feedback. So I think things are being optimized a bit through ChatGPT and tools like that. But in the five or 10 years, are there any skills that will potentially go away or 95% of it will be done by AI? And if so, where do you see most of that change happening in the skillsets?

Marty Cagan (00:52:38):
Absolutely. And I think that is happening more on the engineering side right now and also on the design side, but I fully expect it will happen. Like I said at the beginning, I don't know when really because that timing is hard question, but this is another one of my arguments to people of why you need to uplevel your skills. If you are fundamentally a backlog administrator, good luck protecting that because already people are doing that. It's only a matter of time before that becomes pretty well-supported. That is not a good job prospect. Now, then we can talk about a feature team, project manager. There's very little that's going on in there that is truly value add. Most of these are administrative kinds of things that can be done at least significantly with help. So I wouldn't feel confident if I was a feature team product manager that I could keep doing this for any amount of years at least.

(00:53:45):
Now, for an empowered product manager, if your responsibility is value and viability, if you boil it down, that's the real challenge left with ChatGPT or GenAI, is viability becomes even more the important question. There's some very hard things left. So designers, I think the real product designers at the top of the chain, they're going to be incredibly important and of course tech leads are going to be incredibly important more than ever. But for a product manager, especially with viability, I've been on so many of these calls where we've been talking about the implications of probabilistic software versus deterministic software and what is okay? The lawyers are weighing in already with the legal perspective, but also ethical perspective and just if this is mission critical, is this something that we could be okay with having a probabilistic answer?

(00:54:49):
We don't know, trying to figure that out. So what is that really? That's a viability and a value question. So a lot more is landing squarely on the product manager than I think in general in the past.

Lenny (00:55:04):
Can you talk about viability, just so people know what you mean when you say that? What's the one sentence definition of what viability means?

Marty Cagan (00:55:09):
So value means for the customer, viability means for your business. So that means it works for your business. You can sell it, market it. It's legal, you can service it. It's compliance. All of these constraints. Remember Airbnb, it wasn't so hard to get people to sign up. It was hard to make listings legal in San Francisco. That's the hard part, is the compliance side.

Lenny (00:55:38):
I want to talk about your book. Is there anything else along these lines before we get into your book that you thought would be interesting to touch on or share?

Marty Cagan (00:55:45):
I think that's good. We covered a lot. We covered a lot.

Lenny (00:55:48):
We did. I imagine we covered some of the elements of your book, but let's talk about the book. So this is your third book, is that right?

Marty Cagan (00:55:55):
Yes.

Lenny (00:55:56):
Okay. What made you decide to write another book and add an addition to the Marty Cagan cannon and what is it about?

Marty Cagan (00:56:05):
This is a different one though. It's different kind because INSPIRED, hopefully you know, is for product teams and product managers. It's really a book about product discovery. And then EMPOWER is really about product leadership, vision strategy, team topology, coaching. It's all about that. And that was the original idea. We would share those techniques 'cause that's what we share. But the single most common question we got honestly from the first edition of INSPIRED was that people would read the book and they would say, I love this, I want to do this. But have you ever seen our company? We are so far away from that. We are like night and day. And in fact, a lot of people would tell me point blank, there's no way their company's going to go along with this. And so what they were asking was, how in the world do you transform to work like this?

(00:57:01):
And we've been getting that question for years now. That's really what my partners, Christian, Jonathan, Christopher, Leah, that's what they do is they help companies to transform. That's what we've been doing. But we do that on a one-off basis. There's only five of us. How many companies could we possibly work with? So we realized that this question was a global question. And if we've written books that explain, maybe you want to work this way, but we don't address how to change to work this way, that's leaving people without that hard part. So the goal of TRANSFORMED, unlike the other books, was to share how to actually change. There are techniques in TRANSFORMED as well, but there are transformation techniques. There are change techniques like the use of pilot teams or spreading things out to divide and conquer on some of the transformation work.

(00:58:01):
So the other thing we wanted to do, in fact, we made a rule for ourselves. We knew we needed lots of examples, case studies, but we said it's too easy to include Silicon Valley companies because Airbnb was born in this model. They were designers, but still they were a Silicon Valley company. It was a big advantage for Airbnb over say your favorite bank or whatever that was not born in this way of working. So we said all our examples are going to be from outside Silicon Valley world. They're all companies, most of them pre-internet, that had to change dramatically to work this way. And not only were we going to show how they changed, but we were going to show what they were able to do when they changed, which to me is the coolest part, seeing the innovation. Some of these innovations, honestly, Lenny, are as impressive as anything I've seen Amazon do and that's saying a lot.

(00:58:59):
Amazon in my opinion is the top of the pack and so that's impressive, what Trainline in the UK was able to do. A company I had never known before a few years ago in Saudi Arabia called Almosafer, a travel agency. They own, I forget what it is, 80 plus percent of the market over Expedia, over the big guys in the US because they actually learned this stuff and were able to do it. And we have a dozen examples from all over the world, Brazil, Virginia, everywhere, not Silicon Valley. In healthcare and car sales and fitness, all over the place. Honestly there was a few reasons. One is we wanted them to understand what it really means to move to this way of working. No fluff, just what does it really mean? Otherwise, how are they going to get there if they don't even know where there is? Then we wanted them to believe it's possible to transform. We're the first ones to say it's not easy, but we wanted them to believe it's possible.

(01:00:10):
And the third thing is we wanted to get them excited about what they'd be able to do after they transformed. And those were the three things we were trying to do in the book. And so that's different than our other books, but hopefully it makes the other books more accessible. They'll be able to apply more of them.

Lenny (01:00:28):
Who would you say this is most suited for? Is it leaders at companies? Is it ICPMs, everybody? Who do you think would get the most out of this?

Marty Cagan (01:00:36):
We wrote it intentionally, again, unlike the other books. The other books are written for people like us and your audience and my audience. They're product people. These are written for non-product people too. And so the idea is a CEO, a CFO, a head of sale. Anybody who cares about their company changing how they build and wants to help is written for them. So that was one of the hardest parts really, including those kinds of reviewers and making sure all this stuff made sense to them.

Lenny (01:01:08):
So basically if you're listening to this and you're like, I'm working on these teams Marty's describing, I don't think this is optimal. We can do a lot better. We can get a lot more on out feature team, hand this book to your CEO essentially?

Marty Cagan (01:01:22):
And I'd suggest they read it themselves so they know. Because I know I'm going to be talking more about this going forward because I know I need to. Too many people in our industry view themselves as a victim of their company. They're stuck in a feature team and there's nothing they can do about it other than quit. But really they have a family, they're not going to quit. So I think that's not true. I think there is so much they can do and hopefully they can see that in the book. It's like they can see what they individually can do to push their company in this direction, and at a minimum it'll help their career.

Lenny (01:02:05):
I always love just the message of empowerment and giving people motivation to you can actually make change. You're not stuck in this way of working, and I know you do that a lot. The official title of the book, so it's TRANSFORMED: Moving to the Product Operating Model. What do you mean when you... There it is. I don't have my copy yet 'cause that hasn't come out in the US yet, otherwise, I'd have it here on my side as well. There it is. It's a beautiful green color by the way. It goes nicely with the other colors. Amazing. Beautiful design, whoever did that. Okay, so the part of the title is Moving to the Product Operating Model. What does that mean?

Marty Cagan (01:02:40):
That was the biggest pain for the book was... 'Cause honestly, I had dodged that question for 20 years. If you look at any of my writing before starting on this book, I just said, "Look, do you want to work like the best or do you want to work like the rest?" That's how we referred to it, the best versus the rest because there is no word, there is no name that talks about the common principles with all the best companies. So we would just say, do you want to work like the best or not? But when I started to write the book, I'm like, okay, I can't just say work like the best. We have to have some name for this, but I don't know if you've come across this Lenny, but you don't want to coin a new term if you can avoid it.

(01:03:27):
It is really painful to try to develop a new term. Some of the companies we worked with use the term product operating model and don't get me wrong, that's not the only term. Some people use the term product led company or product driven company, but those two we just don't like because it gives all the wrong message and the rest of the company thinks it's a power grab. So we wanted to avoid those words. We like product operating model for a couple reasons. One is it's a model, it's a conceptual model. It's not a process. It's not really a thing, it's more of a set of principles and also it's non-threatening to a lot of people. It's just saying, "Look, this is how these companies operate. You can look at it and decide if you think it's good for you too." So we adopted that term, we call it product model for short. And all it really is it boils down to a set of 20 principles and those 20 principles are what we find.

(01:04:36):
Remember we started with this. I was explaining, when I listen to your guests, I'm listening for what's special about each of their companies, but what I'm looking for is the commonality. 'Cause most of the time when I see a successful company, they are living these principles. Principles like you have to experiment. You have to embrace experimentation. If you don't do that, most of this is not possible. Or you have to make sure that everything you release is instrumented so that we can prove the outcome. Stuff like that, that there's a million different methodologies and frameworks and tools and processes, but matters is those principles. And so that's what we mean by that product operating model. There's at a high level we talk about it, is how you decide what you're going to work on? How you decide which problems to solve?

(01:05:33):
That's what most companies do in annual planning, but it's basically the product strategy. That's what your Meta friend was describing that the leaders do. That's their job. The second is how do they solve problems? Do they have the skills to do product discovery like we're talking about? How to actually come up with good solutions that work for the customer and work for the business. That's the second big dimension of the product model. And the third big dimension is how do they actually build, test and deploy product to their customers? Do they do it in a way that is reliable, that is demonstrable where you can show that this generates the outcomes that you need? Those are the three big areas. And then there's a number of competencies. There's four new competencies that most companies don't have, but what makes it tricky is they have people with those titles, but they don't have people with those jobs. The one we've been talking about is product manager.

Lenny (01:06:40):
What would be most interesting to share? You said there's 20 attributes of a power product team.

Marty Cagan (01:06:46):
20 principles.

Lenny (01:06:48):
20 principles. I'm so curious what these are, but I know we don't have time to go through them all. Can you either share a few of those? You shared experimentation as one, or these four what you just mentioned. I'm just curious what these [inaudible 01:06:58]

Marty Cagan (01:06:58):
Well, I could share as much as you want, but the four competencies are product manager. Again, we're talking a serious product manager here, not a product owner, not a feature team product manager. Product manager, real product designer, service design, interaction design, visual design, user research, real product designer, a real tech lead, and then a real product leader, a manager of product design engineering that knows how to coach their people and knows how to do a real product strategy, which is what we were talking about. So those are the four new competencies. For most companies, those are new, meaning they might have people with those names, but they don't have those roles institutionalized.

Lenny (01:07:43):
It's interesting, you're building on the classic triad with this leader above. It's like the stool with something on the stool or something or filling up the stool.

Marty Cagan (01:07:51):
And that is the triad. That's where it came from. The word triad came from those three. We didn't invent that.

Lenny (01:07:58):
Right. But I think the product leader is a really interesting addition there. You can't just have this team off to the side without a product leader overseeing that work.

Marty Cagan (01:08:04):
That's so true because one of the things I really learned with INSPIRED was that it wasn't enough to have the teams do their job. They needed leadership to do their job. So it is both. And that's why I was saying we don't frame it as top-down, bottom-up for that. We frame it as each group doing their job. And when that happens, it's actually a beautiful thing.

Lenny (01:08:28):
We're going to link to a post that you wrote, Product Leadership Theater, which talks about how people do this actually badly and what it looks like when it's just pretend versus actually doing it right.

Marty Cagan (01:08:37):
Good.

Lenny (01:08:38):
Okay. And then what are some of these principles, just to touch on a couple and a few-

Marty Cagan (01:08:42):
Just stop me, but there's a set of principles around the more cultural things, like innovation is more important than predictability. That's a principle. That learning is more important than failure. The principles are more important than process. Some examples of that. In terms of teams, empowered with problems to solve. That's one of your foundational principles. We talked about that, this idea of real ownership, real sense of ownership so that it's theirs. Well, of course in discovery you'd recognize all the principles, but it's about addressing product risks. It's about embracing quick experimentation. It's about testing ideas responsibly. These are principles. And then I did mention a couple of the delivery principles, things like small frequent uncoupled releases. For most companies that's CI/CD, instrumentation of everything, monitoring of everything. These are delivery principles. So none of these should surprise you 'cause they are what's consistent in the good companies that we know, but these are the things that we think matter.

Lenny (01:09:58):
That's awesome. And I imagine people listening to this, if they're in that 10% or 20% of companies that you describe as doing this well are just like, of course. And then the rest are just like, no, there's no way we're going to be able to do that.

Marty Cagan (01:10:09):
You have to realize in most of the rest of the world, they release monthly or mostly quarterly. Think about that. Quarterly releases. Think about it. You cannot take care of your customers. You cannot learn at the pace you need to. By the way, quality is going to be terrible in that model.

Lenny (01:10:30):
I don't want to go on this tangent necessarily, but I know in some cases, like a quarterly release, like Shopify as an example, they have seasonal releases like the winter launch and the summer launch.

Marty Cagan (01:10:40):
And salesforce.com has a big... But don't confuse the actual releasing by the teams with the marketing releases. So it's very normal and I think wise to batch. Because look, most product teams are releasing on the order of 20 times per day. You're going to do a marketing release 20 times a day? That would be useless. So it makes sense to have messaging on a periodic basis, but good companies, by the time they message it, it's live. It's been coming out. We may have released some things dark as you know, but we've got it in production solid. We've proven each thing probably with an AB test.

Lenny (01:11:25):
Airbnb is actually in that same model. Most of the stuff they announced every couple times a year is already out or an experiment to most people. One thing I wanted to clarify, so you call this the product operating model. There's also this role product ops, which you touched on a little bit. Any thoughts on product ops? We've had a few guests here talk about it.

Marty Cagan (01:11:43):
It's tricky. First of all, some people have asked me, is product ops the same as product operating model? No. That was just a very unfortunate name conflict, but product ops is more analogous to DevOps and design ops, that's all. Now, can you use product ops in the product operating model? Absolutely, if you're using one of the definitions that are part of the model. So for example, the heart of product ops in the good companies I know is user research and data analysts. And the only difference is they're now brought together under one product ops leader. That's all. That that is the same. How long has that been with us, Lenny? More than 20 years. Companies have had user research teams and have had data analyst teams to help you make decisions qualitatively and help you make teams quantitatively. So that's not new at all, but it is good. And I think there is some amount of value about bringing that in.

(01:12:52):
Some companies, of course, they interpret and define product ops very differently. A lot of them unfortunately think of it, they focus on the whole phrase of process in governance. That's a huge red flag and I try to tell people, if that's what you see, run. Don't walk away from that. The other thing that's going on in a lot of companies, it is amazing to me how creative companies can be to try to find a way to justify giving product managers assistance because the product manager says too much work, which is really ironic to me 'cause they're usually feature teams that are saying this and I'm like, "It's not even enough for your job." But anyway, they're like, "Too much work." And so they're like, "Well, we need help." And so for a while, they would all have these little associate product managers. And then a lot of companies they have, oh, we also have product owners.

(01:13:51):
Product manager and product owner makes no sense. Huge anti-pattern. Today a lot of companies use the same excuse, but its product manager has product ops people to do the dirty work. No. And honestly, I would not want to be one of those people because I think they're very vulnerable right now.

Lenny (01:14:12):
I've changed my mind on product ops. One reason is because I also was like, "I don't need another person in the loop on everything I'm doing. I just want to have..." I don't know why I would do that even though I have endless work and I have working crazy hours. But I think one of the great things about product ops people that I talk to is there's not many of them. You need one often to do a ton and to help a lot of different teams, so it's not like a team that just grows like crazy.

Marty Cagan (01:14:37):
That's what I like. Same with user research, by the way, and you had a very good guest on that I think tried to make that point as well, a small high leverage group. So it works for data analysts and it works for user research where they are helping the teams do the work they need to do, but that's where it really depends what they're doing. I will tell you I've seen too many companies where the product leaders are not doing their job, so what they do is they hire product ops to try to do their job. They're the ones now responsible for educating the product managers. That's just not good.

Lenny (01:15:13):
I have just a few more questions before we get to our very exciting lightning round. Actually, maybe just one more question. We'll see where this goes. So I've mentioned this earlier that a lot of startup founders are just like, "I do not need product managers. I'm not going to hire them ever. Or maybe I'll wait until I have hundreds of engineers." But then I find many of them change their mind, bring in a PM and they're like, "Oh wow, this is amazing. Why didn't I do this earlier? This person, it's exactly what I needed." And these are guests I've had on the podcast that were like, "We don't need PMs." And then they get one and they're like, "Okay, I see. This is great." Do you have any advice for founders that are in this boat of just like, I don't want product managers, they're going to screw us up, they're going to slow us down? Any advice for this?

Marty Cagan (01:15:53):
Yeah. Well, first of all, I'm one of the people that tries to discourage them from hiring product managers too soon because a lot of them make the mistake of hiring them too soon. Now, realize what we're talking about here, again, the whole discussion we've had, this is other layer to, I'm talking about a real product manager. If they're using them as project manager, which a lot of times they are, well, I would tell them they're overpaying, but okay, you can get some help for project management. That's not a good use of the CEO's time. But if they're a real product manager and they're worried about value and viability, that is the founder's job. So the founder should be doing that and needs to be doing that, and it usually causes conflict if they bring in a real product manager too soon. It's too many cooks in the kitchen.

(01:16:45):
You need to reach a certain scale before it helps you to have other people responsible for value and viability. That all assumes that they understand real product management, otherwise it's going to lead to very different symptoms.

Lenny (01:17:01):
So I think one piece of advice here is after product-market fit is a better time to hire a product manager. Otherwise, they're just between you and the product and it slows everything down, right?

Marty Cagan (01:17:10):
Yeah. Remember, usually as soon as you get product-market fit, you're working on it for other products and other markets, and so it's an ongoing thing, but while it's small, it usually is most useful just to look at the number of engineers. At a certain number of engineers, usually 20 to 25, it's a lot better if the co-founder is the product person for that.

Lenny (01:17:35):
Awesome. I was going to ask you if you have a heuristic for engineers and so thank you for preempting that. That's essentially all I had to chat about, Marty. Do you have anything else that you think would be interesting to share or touch on or leave listeners with before we get to a very exciting lightning round?

Marty Cagan (01:17:51):
Honestly, Lenny, we talked about so many big topics. I'm worried that may have overwhelmed people, I hope not. Because you asked all the hardest topics.

Lenny (01:18:03):
Well, good job me. Good job you. With that, we've reached our very exciting lightning round. Are you ready?

Marty Cagan (01:18:09):
Sure.

Lenny (01:18:10):
What are two or three books that you've recommended most to other people?

Marty Cagan (01:18:15):
I love the new book from Tony Fadell called Build. It's a wonderful book and he's describing the product model, but for hardware devices and his perspective was fabulous. He had a front row seat to some of the most iconic products in the world, the iPod, the iPhone, the Nest devices. Love it. So I loved his book and I've been recommending it to all kinds of people. Another one I really liked is, do you know Tim Urban, the guy behind Wait But Why?

Lenny (01:18:45):
Absolutely.

Marty Cagan (01:18:46):
I just love the way this guy thinks. And he wrote a book called What's Our Problem? that I found really provocative. Challenged me in a hundred different ways, so love that.

Lenny (01:18:56):
I've been reading about his book writing process as he was writing it over the many years and it was just quite a journey he went on to make that book happen. Do you have a favorite recent movie or TV show that you really enjoyed?

Marty Cagan (01:19:09):
Lenny, you couldn't ask that to a worst person 'cause I watch almost nothing, so not a good one for that.

Lenny (01:19:16):
Great. I think that's often for the best. Do you have a favorite interview question that you either use yourself or find useful when interviewing folks, product managers especially?

Marty Cagan (01:19:26):
Well, given how much interviewing I do, I stopped giving out my real favorite questions because they became online. But I do have a go-to question that I pretty much start with everybody and I want to know if they can even define the job of a product manager.

Lenny (01:19:41):
What do you find in the answer and what do you look for? Is it just how close they are to your version of a product manager?

Marty Cagan (01:19:49):
I can tell where they learned from their answer, that's all. They don't have to give my answer. They just shouldn't give the old feature team answer, that's all.

Lenny (01:20:00):
Do you have a favorite product that you recently discovered that you really love, whether it's software or something physical, something around the house?

Marty Cagan (01:20:06):
I recently got a Rivian, which is amazing that they did an absolutely beautiful job. They're the Airbnb of car companies because the founder's a designer and imagine if a designer designed the next generation car. It's a phenomenally good job.

Lenny (01:20:27):
Wow. I was imagining you could rent people's cars and that sounds pretty cool, but you mean it in a different way. Interestingly, both you and [inaudible 01:20:38] from Meta both had cars as your favorite recent product discovery. He had a Mercedes-Benz. And I made the joke that I hope to give away these products someday and the budget is blowing up with all these cars in the mix.

Marty Cagan (01:20:52):
Well, my favorite thing to do is ride motorcycles and there is a new generation of product that who knows, might save my life one day, but these are literally wireless airbag vests that you wear and it uses AI technology and sensors to decide if it should deploy. Luckily, mine has never had to go off, but I know for a lot of people it saved their lives. That's an example of technology where without the technology, it's a very vulnerable... Even with it, it's vulnerable.

Lenny (01:21:28):
Wait, do you ride motorcycles?

Marty Cagan (01:21:29):
I do.

Lenny (01:21:30):
I had no idea. What bike do you ride?

Marty Cagan (01:21:33):
I have two and they're both BMWs.

Lenny (01:21:36):
Wow. We need to see a picture of this somewhere. That's amazing. I had no idea. Two final questions. Do you have a favorite life motto that you often come back to, share with friends or family and find useful either in work or in life?

Marty Cagan (01:21:49):
I don't really have a life motto, but I do have one I share a lot with people because as you might imagine, I think writing really helps me think and I encourage other people to develop their thinking skills and there's a great quote from Leslie Lamport, the guy who... You're not old enough to know this, but he invented one of the first word processors called LaTeX, which I used to use back in the day. But if you're thinking without writing, you just think you're thinking.

Lenny (01:22:21):
There's a version of this that I love and it's the same idea that I don't know what I think until I've written it down. I think Joan Didion said that.

Marty Cagan (01:22:29):
Same idea.

Lenny (01:22:30):
And I so agree. That's why I started writing. I just want to figure this out that I have in my head. Crystallizing something that makes sense. Last question. You've been doing this work for many, many years now. How many years have you been at this?

Marty Cagan (01:22:43):
43.

Lenny (01:22:45):
43 years. What else would you have been doing right now if not having gone down this track?

Marty Cagan (01:22:53):
Oh, well, honestly, I would've been really happy just staying in engineering. I've always loved design too. I think I would've been really happy as a designer. I think no matter what though, I would have been still building something, whether if it was houses or cars or whatever. I like building things.

Lenny (01:23:13):
I love that. You're essentially a one man triad team in this dream. Marty, this was incredible. It was everything I was hoping it'd be. We covered so much stuff. I think we're going to help a lot of people transform. Two final questions, where can folks find your book? When is it available? Where can they reach out if they want to follow up on stuff? And how can listeners be useful to you?

Marty Cagan (01:23:34):
The book should be available worldwide in electronic Kindle audio and hardback on March 12th. We'll see, but that's what the publishers promise. And you can find about all of the things I talk about and all our stuff is for free on the website, svpg.com, Silicon Valley Product Group. And if you don't know at least one of the partners, you should try to meet one. We all love meeting the community and I think you'll enjoy it. So hopefully that's useful.

Lenny (01:24:12):
We've had two partners so far. We'll work our way through the rest over time. And I want to make sure you answer the last question, how can listeners be useful to you?

Marty Cagan (01:24:20):
To be honest, a lot of the inspiration for what we write comes from questions from people, and so we love it when people read something and if it works, great, and they tell us, we love that too. But if they have follow-up questions, one of the nice things about the online archive is we'll just go update the article to address the question. So we love that.

Lenny (01:24:40):
You do the same thing.

Marty Cagan (01:24:41):
So feel free.

Lenny (01:24:42):
All right. Amazing. Marty, thank you so much for making time to do this and for being here.

Marty Cagan (01:24:47):
Thank you, Lenny.

Lenny (01:24:48):
Bye everyone. Thank you so much for listening. If you found this valuable, you can subscribe to the show on Apple Podcasts, Spotify, or your favorite podcast app. Also, please consider giving us a rating or leaving a review as that really helps other listeners find the podcast. You can find all past episodes or learn more about the show at lennyspodcast.com. See you in the next episode.