Marty Cagan's Ten Regrets: Revisiting the Advice in Inspired
Lenny's Podcast
At Lenny and Friends Summit, Marty Cagan, whose book Inspired many product people own in dog-eared copies, gave a talk about what he regrets in his own product advice. He had put off the exercise for a long time because, as he said, he has spent decades arguing certain positions. AI prompted him to re-examine everything, including principles he had been taught were sacred. What follows are the ten regrets he chose, and his reasons for still being optimistic about the profession.
Two Kinds of Product, and Why He Cares About Principles
Cagan opened with something he noticed while listening to the day's talks. He said the speakers fell roughly half and half into two worlds, which he has long called the project model and the product model. The two groups described the product job in dramatically different ways. He admitted he is biased toward the product model. He said he had wanted to correct some of what he heard, but that Robbie from Google and another speaker had already said what he would have said.
He then explained his position. He has little interest in the latest process, framework, or agent someone built to automate a task. Those may be useful tools, but in his view they are not the job. The job of product is to solve problems for customers and achieve outcomes for the business. Because he focuses on principles rather than tools, he considers his content fairly durable. With every new technology wave he has asked whether it invalidates those principles. With AI, he felt he had to look at all of them again.
He treats his content as a product and says he does discovery on it every week by working with product teams. He described his day at the summit as more of that discovery. His brainstormed list of regrets was long, which he called "kind of depressing," so he limited it to the top ten things he genuinely regrets. He drew the line at the first edition of Inspired in 2008. He noted that he had already worked in product for about 25 years by then, as an engineer, product manager, and product leader at what he called "the Anthropics of the day." Some of the regrets, though, are less than six months old.
1. Understating Business Viability
Cagan called this the most embarrassing regret. In the product model, he said, the product manager's job is to make sure a solution works for customers and also works for the business. That means the company can afford to market, sell, and service it, and that it is legal, compliant, and respects privacy, safety, and ethics. He said this was a large area even before AI and is harder for people building AI products.
The first edition of Inspired did not treat viability as a risk at all. It listed three risks: value, usability, and feasibility. Viability was "buried in there." He fixed this in the second edition, ten years later.
He said he spent a lot of time asking how he had carried such a blind spot for so long, and he believes he knows why. Almost his entire career was in developer tools and platforms, a space he still loves; he cited Claude Code as an example. He described this as one of the few areas where a product manager can get away with fairly weak skills in viability, because it is a much simpler space in that respect. He framed this as an advantage of those products rather than a criticism. Most products, and AI products especially, are not like this. He used to regard his engineering background as his superpower. Now he argues that business viability, approached from a holistic systems-thinking perspective, is what people need to succeed at every level.
2. Letting Problem Discovery Crowd Out Solution Discovery
Cagan has always divided product discovery into two parts. Problem discovery is figuring out which problem to solve. Solution discovery is figuring out how to solve it. His mistake, he said, was not anticipating how strongly people would be drawn to the problem side. Many product managers see themselves as gatekeepers whose role is to decide whether something is a problem worth solving.
He agreed you need to understand the problem, who you are solving it for, and what success looks like. But he said that part is "not very hard." If you spend much time on it, you won't do the work you are actually paid for, which is solution discovery. He also challenged a common explanation for failure. Teams often conclude a product failed because demand was too small or too few people had the problem. He said this is almost always wrong. When a competitor ships a better solution, it becomes clear that demand was never the issue. His revised emphasis is to spend a little time on problem discovery and save the time for solution discovery, which he called "where innovation happens."
3. Asking the Wrong "Why"
Cagan has argued for years that teams need to understand why they are working on a given problem. He borrowed John Doerr's phrase about needing teams of missionaries, not mercenaries. He still thinks this matters but now calls it easy. If a company has a product strategy, the reasons for working on each problem are already visible to the whole organization.
He said the more important "why" is why people are not using your product. He credited Robbie from Google for raising this earlier in the day and said it was somewhat surprising coming from Google, which for a while believed data alone would answer such questions. He argued you have to talk to customers to find out.
He gave his own experience as an example. Product people are early adopters and try products constantly, and he said most of those products are bad, so he churns. Almost nobody follows up with a survey, an email, or anything else to ask why. He called the question of why people are or aren't using a product probably the single most important one, and the key to unlocking a lot of innovation. Yet, he said, most teams never ask it.
4. Humility
The longer he works, Cagan said, the more he believes humility and a truly open mind matter for product people at every level. He defined humility as knowing what you can't know and admitting what you don't know. The message many readers took from his books was the opposite: that the product manager should be "CEO of the product." He argued humility is not just a personality trait. In his view, its absence contributes directly to the root cause of many failed products, which led him to his biggest regret.
5. Underestimating the Desire for Predictability
Cagan called this possibly his single biggest regret. He did not appreciate how powerful and deeply rooted the desire for predictability is, among both product people and senior executives, or how much it conflicts with humility, innovation, and outcomes.
Acknowledging he was "opening a can of worms," he pointed to the two main artifacts of product work. Roadmaps are prioritized lists of features and when to build them. PRDs describe the requirements for those features. He asked the audience to consider how much these artifacts help people believe they know more than they do.
He said people keep asking whether PRDs and roadmaps are still needed. He had not heard the question about roadmaps until that morning, and, referring to Claire's optimism on that point, he said he guaranteed roadmaps are not going away. For him, the question has never been whether these artifacts exist but what they are used for. If a PRD reflects the assumption that you already know the answer and hands requirements to engineers, that is the project model, which he called the root cause of many failed products. If you have learned, tested, and gathered enough evidence that what gets built will achieve the outcome, the PRD is simply a communication device. Used that way, he said, it is harmless and even useful.
He applied the same reasoning to roadmaps. Listing features that are someone's guess at what might work, and attaching dates, wastes most of the team's time and most of the engineering capacity. He acknowledged that engineering time has dropped sharply, but said the capacity is still being wasted, and "the tokens aren't free." He concluded that predictability has some value, but not enough to justify trading away outcomes or trust.
6. Politics
Cagan said he always knew politics mattered but naively believed good product work would carry the day. He now sees politics as part of the fabric of every company. He noted that over the last three years, about half his content has been about dealing with politics and the other half about the impact of AI.
7. Barely Addressing Product Leadership
He described this as probably the regret that caused the most damage. His early work focused on product teams and the craft of product discovery. That was a deliberate choice: he loves the craft, and he saw most people building and shipping to see what sticks, which he said is still common. As a result, he barely mentioned product leadership and did not foresee the consequences.
Because Inspired still sells strongly, he said, many companies read it and conclude they only need to set up empowered product teams with strong product managers. What many have learned is that empowered teams need not less management but better management. He referred to an earlier speaker's point about context and said providing it is the critical role of product leadership. At a minimum, that means a product strategy, which he described as a prioritized list of problems to be solved.
8. Corporate Governance
Cagan was clear that he did not mean process governance such as a PMO, but oversight of the company itself. He had long recognized it as a problem but considered it outside what product could influence. One of his most painful lessons, he said, is helping companies get much better at shipping great products, only to see them become targets for people with very different motives who pull the product in another direction. He recommended Eric Ries's new book, Incorruptible.
9. Product Is a Full-Contact Sport
Cagan said his books make product sound gentler, even almost academic, than it is. Saying the job is to solve problems in ways customers love and that work for the business is accurate but incomplete. To get people to switch, you have to solve problems dramatically better than competitors. In a competitive open market, he called product "a full contact blood sport." He said readers of his content would not get that impression, and many teams are not prepared for it.
10. Not Emphasizing Thinking Enough
His last regret was that he did not stress enough that good product work is fundamentally about thinking, a point he was glad to hear other speakers raise. His mistake was not appreciating how far people will go to avoid thinking, which he said he wished were a joke. In his view, this shows up as a craving for process, frameworks, and predictability.
He called it a big mistake to structure Inspired around people, process, and product. He said he worries large language models will be used as a substitute for thinking, but noted this has already happened with process. He agreed with Elon Musk that in many companies, process substitutes for thinking. He said he should have called out thinking, and product sense as its foundation, much more loudly and clearly.
Why He Is Still Optimistic
Despite the list, Cagan said he feels good about his content overall and, more importantly, about the future of product people. For about 20 years, the main criticism he has heard is that people wish they could work the way Inspired describes but face two obstacles. Their companies are addicted to output and its predictability, and working this way seems hard.
He argued that both obstacles are shrinking, largely because of AI. More organizations than ever understand the need for outcomes rather than output, and the work is dramatically easier. He asked the audience to leave understanding that there are two kinds of building: building to learn and building to earn, terms he attributed to Jeff Patton. This is the difference between product discovery and product delivery. If a product person wants to spend their time submitting front-end pull requests, he said, that's fine, but perhaps they should be a developer. The product person's job is to build to learn, so that when engineers build what goes to customers, it achieves the needed outcome.
He closed by saying that thanks to AI, the principles of the product model, the craft of product strategy, and product discovery have never been more important. He thanked Shreyas Doshi and Teresa Torres for feedback on early versions of the talk, and Lenny for hosting the event.
Thank you. 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 lost track of the people that came up to me and thanked me for content, for books. People have tattered copies of Inspired and they ask 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, 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 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 comes — 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 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, 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: 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 — 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, if I knew then what I know now.
Now, I decided to draw the line with the publication of the first edition of Inspired, which was in 2008 — some of you weren't even born then — but that's where 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, 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. A product manager's job, at least in the product model, is to make sure that the solutions are both something the customer will buy and that 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 Inspired, 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 where 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, 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 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 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, it's business viability, especially from a holistic systems thinking perspective.
Second, problem discovery. Now, you know, I've always talked about product discovery as having 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 know, there 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 is important, but spend a little bit of time and 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 loved seeing that. And honestly, that's kind of a surprise for Google. For a while they thought it was all based on data and they weren't going to talk to customers. 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, it's not good, so I churn. Almost nobody follows up. Nothing. Not a survey, not an email, nothing to ask me why I churned. 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 I realize that humility and a truly open mind are so important to product people at every level. What does humility really mean? It means knowing what you can't know and admitting what you don't know. Many of you know this, but instead, the message most people took away from my books was that 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. Roadmaps, of course, are the prioritized lists of features we think we need to build and when, and the PRDs are how we describe the requirements 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 till 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 of — 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 gathered the evidence you need to know that 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 down 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, but 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 as, or worth trading off, outcomes or trust.
Politics. The truth is we all know politics is important, but I thought good product work would carry the day. That was, of course, naive. And the truth is politics are everywhere. They're in the fabric of every company. And 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 most long-term damage created from, like, the book Inspired. My initial work was all about product teams and product discovery, because what I really love is the craft of product, and I wanted to write about the craft of product because there are 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. I hardly mention product leadership, but what I didn't appreciate was the consequences of that choice. And the result is so many companies — and I'm sad to say this is still true today, because 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, with a strong product manager, and you can be awesome. 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 prioritized list of problems to be solved.
Another one that's just 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 them become a target for people with very different motivations who are going to pull the product in a different direction. So that's sad. I would encourage everybody to read Eric Ries'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 that 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, is a full-contact blood sport. And from my content, most people 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 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. 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 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 people wish they could work like is 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. 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 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.
All right, I really hope this was useful to everybody. I do want to thank Shreyas Doshi 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.
Article published · Updated