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.

I don't actually go to a lot of conferences, but when I do, 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 asked me— they have tattered copies of Inspired, and they asked for signatures, and it's, you know, hugely flattering and humbling to see that. I did warn several of them that my talk was actually all about

my regrets,

of which there are 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 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 Kari 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 something I've known I've needed to do for a long time, but I kept sort of procrastinating on it. Because 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 you know, all those waves were actually a lot of fun. I'm 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 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 it'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. Ten 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 ten 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 product?

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 business skills. Now, that's not the only one, but it's one of them.

Now, that's not a criticism. It's kind of 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 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 a big advantage. I felt like that was 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 truth, 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, you know, it wasn't 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.

A little bit of time, save time for solution discovery. That's the essence. That's where innovation happens. The next big issue, and this is another one, all of these kind of have, you know, good and bad sides, but 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 Doerr 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 are 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 a while, they thought it was all based on data and we're not going to talk to it. 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 an 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 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 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: roadmaps and PRDs. So roadmaps, 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 roadmaps? I never heard that one posed until this morning. Despite Claire's optimism, I guarantee your roadmaps 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, arrogant, 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 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 roadmaps. 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 trading off outcomes or trust.

Politics. The truth is, 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 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, most damage created from, like the book Inspired. My initial work was all about product teams and product discovery. Because to me, 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 teams and the craft of product discovery. What I didn't appreciate was I almost hardly mentioned product leadership, but I didn't realize the consequences of that choice. And the result is so many companies, and 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 Kari the point about context.

That is what's so critical. At a minimum, it's the product strategy, which is your prioritized lists of problems to be solved. Another one that just is tough, corporate governance. I'm not talking about PMO, which is process governance. I'm talking about corporate governance here, oversight of the company.

We've all known that's a problem, but I said this isn't something product can do anything about. And 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 going to pull the product in a different direction.

So that's sad. I would encourage everybody to read Eric Reese's new book, Incorruptible. You know, this is a funny one. Product is just not as genteel 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, 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, and you know, 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 here's what's the mistake. I did not appreciate the lengths that people would go to in order to avoid thinking. I wish I was joking. 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. The truth is, Elon Musk wasright about this.

In many companies, process is used as a substitute for thinking. So please don't follow. I should have called that out, called out thinking, called out the necessary foundation of product sense much more loudly and clearly. Allright, those are the 10 big things that 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 product. 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 people wish they could work like it's described in Inspired.

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 as 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. It 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 to learn. 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. Allright, I really hope this was useful to everybody. I do want to thank Shreyas Joshi and Teresa Torres, who gave me feedback on early versions of this.

And again, I want to thank Lenny for putting this party together. I hope this was useful. Thank you very much.