Marty Cagan: Strong Opinions, loosely held

Thank you. Um, also thank you to Lenny for running this and for inviting me actually to be a speaker. Um, I don't actually go to a lot of conferences. Uh, but when I do, um, I really enjoy them and I will tell you I can't I lost track of the people that came up to me and thanked me for content for books. People ask me to they have tattered copies of inspired and they ask for signatures and it's you know hugely uh flattering and humbling to see that. I did warn several of them that my talk was actually all about my regrets uh of which there are uh quite a few.

So that is what I wanted to talk about. But I have been here with you all day listening to every one of the talks. And um I learned something really interesting from every single one of them. I observed and I'm sharing this for a reason, but I observed that there are two kinds of product in the world. Two kinds. I've always called them the project model and the product model. About half the speakers were from each. Obviously, I'm highly biased, but my world is both of them. And so, it's super interesting for me to hear, but hopefully you all can think back on the day and you saw dramatically different definitions of the job.

Now, the truth is, as I was listening, I was like, "Oh, I got to talk about this and I got to talk about that. I don't want them to leave thinking this." But then Robbie from Google and Ki basically said what I would have said. loved it. Again, I'm biased, but loved them. What I want to talk about here is a little different. Honestly, it's uh something I've known I've needed to do for a long time, but I kept sort of procrastinating on it because uh this is a really hard question, especially for me. I have spent decades arguing certain points. Now, for those that don't know my work, I am actually one of those people. I'm not interested in the latest process. I'm not interested in the latest framework. I don't really care what you created an agent to automate.

I don't care because that's not actually the job of product. That might give you some tooling to help you do the job, but that's not the job. The job of product is to solve problems for our customers and achieve outcomes for our business. That's what this is about. So that's what I'm interested in. And because I focus on principles, the truth is they're pretty durable. In fact, every time a new technology wave, you heard a very polite way of saying I must be very old to have seen all of these waves. But yeah, every wave you're like, will this invalidate those principles?

You don't really know until you look at it. And of course, as as you know, all those waves were actually a lot of fun. I am one of those. I mean, the reason I'm a product person is because I love the fact that what's just now possible is changing all the time. That's what makes it cool. Otherwise, I would not be doing this this area. I wouldn't have chosen this as a career. But with AI, I feel like I had to look at everything.

Even the things that honestly I was taught are sacred. It's like you don't mess with this principle. I wanted to look at everything. That's what I did. Now, the first thing I had to figure out was where do I start? Because the truth is I treat my content as my product and I am literally doing product discovery every single week with product teams. In fact, a lot of many of you have been with me to know that's what I'm doing.

I'm learning. That's what I've been doing here today is really discovery on product content. And it was very good for me to hear these other views, all of the other views. But anyway, the truth is I have a lot of things I've learned. Now most of the time I just write articles and publish stuff on more minor learnings. But what I wanted to do was to identify what I thought that I mean honestly I started brainstorming a list and it's a big list. It's kind of depressing but there's a big list. I wanted to pick the top 10 things that I genuinely regret. I genuinely if I knew then what I knew now now I decided to draw the line with the publication of the first edition of inspired which was in 2008 which I some of you weren't even born then but that's when I'm drawing the line but you have to realize I had been doing product for 25 years when I wrote that. So I had been a product manager. I went through the whole

engineering side and I was a product leader for two and a half decades. So I had learned a lot from amazing people at some, you know, honestly the anthropics of the day, really good companies. So I decided let's draw the line there. Even though some of the things I'm going to talk about are regrets that are less than six months old. Let's do that. Let's talk about it. 10 big things. The first one I want to start with is business viability because that's honestly the most embarrassing of them.

There is no way for me to get around this. I completely understated the importance of business viability. Just so that everybody knows what I'm talking about here. Business viability. This is a product manager's job is to make sure at least in the product model is to make sure that the solutions are both the customer will buy it and it works for the business. That means you can afford to market it, you can sell it, you can service it, it's legal, it's compliant, it respects privacy, safety, ethics.

This is a big thing even before AI. It's big. Those of you working on AI products, you know it's even harder. Business viability is a really big area. But the embarrassing truth is in the first edition of Inspire. I didn't even talk about it as a risk. Value, usability, feasibility. There were three risks that we talked about. Viability was buried in there. I'm embarrassed to say that. Now, I fixed it in the second edition, but that was 10 years later. This is one of those I had a lot of introspection because the truth is I kept asking how could I have gone so long with such a huge blind spot around products and I believe I know the answer to that and I want to share it with you because it's very relevant even today maybe even especially today because in my career for those that might know I almost all of my career I was working on developer tools and platforms which I still absolutely love that

space. Who doesn't love claude code? I mean I love that space. However, you need to understand this. It's one of the few areas where a product manager can get away with pretty weak skills. Now, that's not the only one, but it's one of them. Now, that's not a a criticism. It's kind of a an advantage for those kinds of products. It's a much simpler space for viability. But for most products, especially for AI products, that is not true. And in fact, I used to be very excited about my um knowledge of engineering because I felt like it helped me learn new technologies. I came from an engineering background. That's what I studied. And it was like big advantage. I felt like that was my my sort of superpower. But today I would argue going forward and for all of you to succeed at every level, business viability, especially from a holistic systems thinking perspective. Second, problem discovery. Now the tr you know, I've

always talked about product discovery has got problem discovery, figuring out what problem you're going to solve and solution discovery, solving that problem. The truth is the mistake I made was I just did not understand how strongly people would be drawn to the problem discovery side of that equation. In fact, a lot of people view themselves as the gatekeeper. That's their job as product managers to make sure they agree this is a problem to solve. Yes, you obviously need to make sure you understand the problem, who you're solving it for, and what the definition of success is. But honestly, that's not very hard. It's not very hard. And if you spend a lot of time on that, you're not going to do the real part you're paid for, which is solution discovery. You might think when a product fails, it's because you didn't um you know, it wasn't a big enough demand, not enough people had that problem. you're almost always wrong

because what's going on is as soon as somebody else comes out with a better solution all of a sudden we know that that was never the issue. So problem discovery I should have emphasized yes problem discovery important little bit of time save time for solution discovery that's the essence that's where innovation happens the next big issue um and this is another one all of these kind of have uh you know good and bad sides but um I spent a lot of time talking about how important it is to understand the reason why we're working on whatever we're working on, whatever problem we're working on. I didn't make this phrase up. John Door did, but we need teams of missionaries, not teams of mercenaries. If you want missionaries, you have to make sure they understand the reason. And yeah, that is important, but that's so easy. And in fact, if you have a product strategy, which you should, we'll talk about that in a

little bit. the reasons you're working on these problems is spelled out for the whole organization to see. So there's no big mystery. So what I want to talk about and I was really happy to see that Robbie called this out. There is a much more important why than why are we working on this problem and that is why are people not using our product. He called that out. I would love seeing that. And honestly that's kind of a surprise for Google. for for a while they thought it was all based on data and we're not going to talk to No, we need to actually talk to our customers to figure out why. I try products constantly. I bet most of you do too.

That's what product people do. We're early adopters. We try it out. Most of them are crap products. You know this, right? We try it. We're not good. So, I churn. Almost nobody follows up anyway. Nothing. Not a survey, not a email, nothing to ask me why I churn. Probably the single most important question is why are people using our product or not using our product? And the part that really gets me is that's the key to unlocking so much innovation. And yet most teams never ask that question. The next one, humility. You know, the longer I go, the more important I realize that humility and a a truly open mind is so important to product people at every level. What does that really mean?

Humility. It means knowing what you can't know and admitting what you don't know. Many of you know this, but instead most people the message they took away from my books was the C the product manager should be CEO of the product, which is kind of the opposite of a humility message. And yeah, this might sound like a personality trait to you, but it's not. I would argue this contributes directly to the root cause of so many failed products, which really leads me to maybe my single biggest regret.

I honestly had no idea and I just didn't appreciate how powerful and deeply rooted the desire for predictability was. And that's from both product people and senior executives and how at odds that desire for predictability is with not just humility but innovation and outcomes. Consider for a second I'm opening a can of worms here. I probably shouldn't but consider for a second the two big artifacts in the product world maps and PRDS. So road maps of course the prioritized lists of features we think we need to build and when and the PRDS which is how we describe the requirement of those features. Now for a second consider how much of an enabler those artifacts are for thinking that we know more than we really do. This is such an important point and so many people misunderstand this. You know, people keep asking the question, do you still need PRDs? Do we still need road maps? I I never heard that one posed

till this morning. Uh despite Claire's optimism, I guarantee your road maps are not going away. We all know that the issue is not whether they are there. And it's never been whether they are there. The issue is what are you using that PRD for? If you're using it because you're forgive me arrogance and you think you know the answer so you're putting it in terms of requirements for your engineers to build that's the project model that's the root cause of so many failed products. If however you have learned and tested and and gathered the evidence you need to know what's going to be built is going to achieve the outcome then the PRD is just your communication device. It's not only harmless, it's actually useful. The same is true with road maps. If you put a bunch of features that are somebody's idea of what might work and you put dates there, you're going to waste most of your time. you're going to end up

wasting most of the engineering capacity. And yes, the engineering time has gone way down. You're still wasting it. And the tokens aren't free. So predictability is at the root of this. And predictability is important, but it's not as important or worth uh trading off outcomes or trust. Politics. The truth is I I we all know politics is important, but I thought good product work will carry the day. That was of course naive.

And the truth is politics are everywhere. They're in the fabric of every company. And I now if you look at the last three years of my content, half of it is with dealing with politics and the other half is dealing with the impact of AI. It is a big topic. This is probably the one with the long long most damage created from uh like the book inspired. My initial work was all about product teams and product discovery because to me I what I really love is the craft of products and I wanted to write about the craft of product because there's a lot of principles and a lot of techniques and most people were just building stuff and shipping it and seeing what sticks and that's still true today. And that was an intentional choice to focus on the on the teams and the craft of product discovery. What I didn't appreciate was I I almost hardly mention product leadership, but I didn't realize the consequences of that choice.

And the result is so many companies and I'm I'm sad to say this, this is still true today because by far somehow all these years later, Inspired is still selling like crazy. A lot of teams just read inspired and they think all they need to do is set up product teams, empowered product teams, a strong product manager, you can be awesome, and they think that's all they need to do and they'll be good. And of course, what so many companies have learned is that in empowered product teams, you don't just need less management, you need better management. And the role of product leadership is so critical. You just heard from Kyrie the point about context. That is what's so critical. At a minimum, it's the product strategy, which is your your prioritized list of problems to be solved. Another one that just um it's tough corporate governance.

I I'm not talking about PMO, which is process governance governance. I'm talking about corporate governance here. Oversight of the company. I I we've own all known that's a problem, but um I said this isn't something product can do anything about. And uh one of the most painful lessons over the years is helping so many companies actually get better at shipping great products only to see they become a target for people with very different motivations that are pro going to pull the product in a different direction. So that's sad.

If you've I would encourage everybody to read Eric Reese's new book incorruptible. You know that this is a funny one. product is just not as gental as I made it sound in my books. It almost sounds academic, right? Where okay, your job is to solve problems in ways your customers love but work for your business. Yes, that's true. But it kind of hides the fact that it's not enough. You actually have to solve problems in ways that are dramatically better than your competition if you're going to get people to switch. And the truth is that product today a comp in the competitive open market product is a full contact blood sport and most people from my content you would not get that and a lot of teams aren't prepared. And the last point uh and you know I uh this is a point a few people have brought up which I'm thrilled to see but fundamentally good product work is about thinking.

It's about thinking and I here's what's the the mistake. I did not appreciate the lengths that people would go to in order to avoid thinking. Uh, I wish I was joking. Uh, what does it show up as? It shows up as a craving for process, frameworks, and predictability. I structured inspired as people, process, and product. Big mistake. And I am worried that large language models will be used as an alternative to thinking, but the truth is that's already happened with process. And the truth is Elon Musk was right about this. In many companies, process is used as a substitute for thinking. So, please don't fall. I should have called that out. Called out thinking, called out the necessary foundation of product sense much more loudly and clearly. All right, those are the 10 big things that um I really genuinely regret.

However, I will tell you, funny enough, ironically, I am feeling really good about the content overall, but more importantly, about all of our future as products. And I want to try to explain why. The main criticism that I've received on my content, honestly, over the last 20 years is that um people wish they could work like is described in Inspire. They wish they could. And they tell me there are two problems. One, their company is addicted to output and the predictability of that output.

And two, it's hard. They think it's going to be hard to work that way. But look, in no small part, thanks to AI today, more places than ever understand the need for outcomes and not just output. And also, it is dramatically easier. You know, we talk about product discovery is build to learn. Everybody in this room, I hope you don't leave this session without an understanding that there's two kinds of building. Building to learn and building to earn.

I that comes from many of you know a guy named Jeff Patton as a term, but we have lots of terms for this. But it's the difference between product discovery and product delivery. If you want to spend your time doing some pull requests on the front end, fine. Maybe you should just go be a developer. But if you want to make sure that what your engineers do build and provide to your customers, you should be building the learned, it's a totally different approach, totally different job. Your job is to make sure that when they do build that thing, you achieve the outcome you need. So here's the thing.

Thanks to AI, the principles of the product model, the craft of product strategy and product discovery have never been more important. All right, I really hope this was useful to everybody. I do want to thank Shri Doshi and Teresa Torres who gave me feedback on early versions of this. And I again I want to thank Lenny for putting this party together. I hope this was useful. Thank you very much.