Lenny's Podcast

Marty Cagan: Strong Opinions, loosely held

1708 summary words 8 min summary Watch video

Start with the signal

8 min read

Summary

At-a-Glance

  • Verdict: Skim
  • Core thesis: AI makes product discovery faster and raises the stakes for product judgment, so teams must prioritize validated outcomes, business viability, customer learning, and leadership context over feature predictability and process.
  • Why it matters: For AI products especially, cheaper and faster implementation can magnify waste unless teams validate solutions, account for legal/safety/service economics, and resist treating roadmaps, PRDs, or LLMs as substitutes for judgment.
  • Best use: Use this as a strategic reset for product and AI-initiative operating principles, not as an implementation playbook.

Executive Summary

Marty Cagan revisits the ideas behind his product-management writing through ten regrets: places where his past emphasis was incomplete or was commonly misinterpreted. His central correction is that product work is not the management of feature output, processes, or automation; it is solving customer problems in ways that produce business outcomes.

His largest substantive correction is business viability. A viable solution must not only be valuable, usable, and technically feasible, but also marketable, sellable, serviceable, legal, compliant, private, safe, and ethical. Cagan says this dimension is especially difficult for AI products, and that his developer-tools background let him underappreciate it because viability was comparatively simpler in that category.

He argues teams spend too much energy validating that a problem exists and too little on solution discovery. Demand is often not the reason a product fails; a competitor can reveal latent demand simply by offering a dramatically better solution. The most valuable customer question is therefore not merely why a team chose a problem, but why people use, abandon, or never adopt the product.

Cagan also reframes roadmaps and PRDs: they are not inherently bad, but become destructive when they encode untested executive certainty into dated feature commitments. They are useful as communication artifacts after evidence has established that a solution is likely to achieve an outcome. AI lowers the cost of building to learn, making outcome-led discovery more practical, but it must not become another way to avoid independent thinking.

Key Takeaways

  • Claim: Business viability must be treated as a first-class product risk, not a secondary concern behind value, usability, and feasibility. | Evidence: Cagan says the first 2008 edition of Inspired omitted viability as an explicit risk; he defines it as whether a solution can be marketed, sold, serviced, and operated legally, compliantly, privately, safely, and ethically, in addition to being something customers will buy. | Implication: For any AI or agent offering, evaluate commercial operations, support burden, privacy, safety, ethics, regulatory exposure, and unit economics alongside user desirability and technical performance. | Caveat: Developer tools and platforms can make viability appear deceptively simple, which Cagan identifies as a source of his own blind spot; most products, particularly AI products, face materially broader viability constraints.
  • Claim: Product teams should minimize time spent acting as problem gatekeepers and invest more heavily in discovering a superior solution. | Evidence: Cagan distinguishes problem discovery from solution discovery and argues that teams often misdiagnose failed products as insufficient demand; when another company delivers a better solution, it becomes clear that the underlying problem was real. | Implication: Treat problem definition, target user, and success criteria as necessary framing, then allocate the bulk of discovery capacity to testing whether a solution is compelling enough to change user behavior.
  • Claim: The highest-leverage customer-learning question is why people use, do not use, or churn from the product. | Evidence: Cagan describes personally trying many products, churning from most, and rarely receiving any follow-up asking why; he calls usage and non-usage feedback the key to unlocking innovation and notes that teams need to talk to customers rather than rely only on data. | Implication: Instrument churn and non-adoption, then pair behavioral data with direct customer conversations to uncover failure modes, unmet expectations, and opportunities for differentiated solutions.
  • Claim: Roadmaps and PRDs are useful only when they communicate evidence-backed decisions; they are harmful when they present unvalidated feature guesses as requirements and commitments. | Evidence: Cagan says a PRD used to tell engineers what to build because leaders assume they know the answer is the project model; after learning, testing, and gathering evidence, the same document can be a useful communication device. Likewise, dated feature roadmaps consume engineering capacity on guesses. | Implication: Require explicit validation evidence and intended outcome behind roadmap items and requirements; separate discovery hypotheses from delivery commitments rather than removing planning artifacts altogether. | Caveat: He does not predict that roadmaps or PRDs will disappear; his objection is to their function as false certainty, not to the artifacts themselves.
  • Claim: Empowered product teams require better product leadership, not simply less management. | Evidence: Cagan says readers of Inspired often assume that setting up empowered teams and hiring strong PMs is sufficient, but companies learn that leadership is critical; at minimum, leaders must provide context through a product strategy defined as a prioritized list of problems to solve. | Implication: Ensure the operating model includes leaders accountable for strategic context, prioritization, decision alignment, and navigating organizational power—not merely autonomous teams executing local discovery. | Caveat: He also notes that organizational politics and corporate governance can redirect even strong product organizations, so team-level practice alone cannot protect product direction.
  • Claim: AI increases the value of product strategy and discovery because it reduces the cost of experimentation, but teams must not use LLMs as a substitute for thinking. | Evidence: Cagan adopts Jeff Patton's distinction between 'building to learn' and 'building to earn,' arguing that AI makes product discovery dramatically easier. He warns that organizations already use process, frameworks, and predictability to avoid thought and fears LLMs may be used similarly. | Implication: Use AI to create and test prototypes, workflows, and assumptions rapidly, while retaining human ownership of problem framing, evidence evaluation, trade-offs, and product judgment. | Caveat: Faster engineering does not remove the cost of bad decisions: Cagan notes that tokens are not free and faster implementation can still waste capacity.

Detailed Brief

Cagan's corrections to the product-model narrative

  • Claims: Humility is an operational product competency: it means recognizing what cannot be known in advance and admitting uncertainty.; The popular interpretation that a PM should be the 'CEO of the product' conflicts with the epistemic humility required for discovery.; A product that is merely good is insufficient in a competitive market; it must be dramatically better than alternatives to motivate switching.
  • Evidence: Cagan calls product competition a 'full contact blood sport,' saying his earlier work made the discipline sound more academic and genteel than it is.; He says the desire for predictability is deeply rooted among both product practitioners and senior executives, even when it conflicts with innovation, outcomes, and trust.
  • Caveats: Predictability has legitimate value; Cagan's position is that it should not be purchased by sacrificing validated outcomes or organizational trust.
  • Implications: Competitive positioning should test whether an offer is meaningfully superior to current alternatives, including customers' status quo, rather than merely whether it solves a recognized problem.; Leaders should treat certainty claims as hypotheses requiring evidence rather than as signs of product competence.

Organizational constraints beyond team craft

  • Claims: Politics is embedded in every company, and good product work does not automatically prevail.; Corporate governance differs from process governance: ownership and oversight structures can attract actors whose incentives pull a successful product in a different direction.
  • Evidence: Cagan says roughly half of his recent content has addressed organizational politics, alongside AI's impact.; He references Eric Ries' book Incorruptible in connection with corporate-governance risks.
  • Caveats: The talk identifies these governance dynamics as important but does not provide a detailed governance design or political-navigation method.
  • Implications: Assess incentive alignment, decision rights, and ownership structure alongside team process when evaluating whether a product strategy can survive scale or success.

Notable Concepts & Terms

  • Product model vs. project model: The product model organizes around solving customer problems and achieving business outcomes; the project model translates presumed answers into feature requirements and delivery plans.
  • Business viability: The full set of commercial and operational conditions that make a solution work for the company: marketing, sales, service, legal, compliance, privacy, safety, and ethics.
  • Problem discovery vs. solution discovery: Problem discovery establishes the user problem and success definition; solution discovery determines whether a specific approach can solve it compellingly enough.
  • Build to learn vs. build to earn: Jeff Patton's distinction between experimental work intended to reduce uncertainty and production delivery intended to generate value from validated decisions.
  • Missionaries, not mercenaries: John Doerr's framing for teams motivated by the purpose of their work; Cagan argues this purpose should be clear from strategy, while actual customer behavior remains the more urgent 'why.'
  • Product sense: The thinking and judgment required to make product decisions under uncertainty; Cagan positions it as foundational and not replaceable by process or LLM output.
  • PRD and roadmap: Potentially useful communication artifacts that become harmful when used to impose unvalidated feature certainty and dated commitments.
  • Corporate governance: Company-level oversight and incentive structures, distinct from PMO-style process governance, that can shape or distort product direction.

Operator Notes / Why Ken Should Care

  • Add a viability review gate to AI/agent initiatives covering support model, distribution and sales motion, privacy, security/safety, compliance, ethics, and ongoing operating cost before committing to delivery.
  • Create a recurring non-adoption and churn research loop: identify users who tried but did not activate, active users who disengaged, and prospects who chose alternatives; require direct qualitative follow-up.
  • Redesign roadmap reviews so every proposed commitment states the target outcome, current evidence, key remaining assumption, and whether it is a learning build or an earning build.
  • Audit internal AI usage for 'answer laundering': require owners to document source evidence and decision rationale rather than accepting LLM-generated plans, frameworks, or requirements as judgment.
  • Clarify decision rights and leadership responsibility for product strategy so empowered teams receive prioritized problem context and are not left to absorb unresolved political conflicts.

Source/Metadata

  • Title: Marty Cagan: Strong Opinions, loosely held
  • Transcript words: 6847
  • Duration seconds: 1351
  • Timestamp note: No usable timestamps or chapters were present; the supplied transcript contains substantial duplicated passages.
Search this video Resume transcript at 0%
Full transcript 3439 words · 30 min read
0:05

Thank you. Also, thank you to Lenny for running this and for inviting me 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 ask me that they have tattered copies of Inspired and they ask for signatures and it's 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 thinking, 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 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 products. 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 yes, every wave you're like, will this invalidate those principles? You don't really know until you look at it. And of course, all those waves were actually a lot of fun. I am one of those. The reason I'm a product person is because I love the fact that what's just now possible is changing all the time. But 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 is really discovery on product content. And it was very good for me to hear these other views, all of the other views. But 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 minor learnings. But what I wanted to do was identify what I thought, honestly, I started brainstorming a list, and it's a big list. It's 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, 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 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 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 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, that the solutions are both what the customer will buy and work 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 Cloud 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. That's not a criticism. It's 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 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 is, 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 didn't know there 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 have 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.

0:15

part you're paid for, which is solution discovery. You might think when a product fails, it's because you didn't have 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 have 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 yes, 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 a surprise for Google. For a while, they thought it was all based on data and we're not going to talk to them. 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. They'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.

0:22

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 the opposite of a humility message.

0:29

And yes, 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.

0:34

So roadmaps, of course, the prioritized list 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 till this morning. And I'm like, 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 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.

0:42

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.

0:54

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 longest, 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.

1:00

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 is still true today because by far, somehow, all these years later, Inspired is still selling 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 list of problems to be solved.

1:07

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 Ries' new book, Incorruptible.

1:13

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 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, I, 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.

1:18

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 was right about this. In many companies, process is

1:24

In the competitive open market, product is a full contact blood sport. And most people from my content would not get that. And a lot of teams aren't prepared. And the last point, which I'm thrilled to see, but fundamentally good product work is about thinking. It's about thinking. Here's what the mistake is: I did not appreciate the lengths that people would go to in order to avoid thinking. I wish I was joking.

1:30

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 has already happened with process. 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 out. I should have called that out, called out thinking, called out the necessary foundation of product sense much more loudly and clearly. Those are the 10 big things that I really genuinely regret.

1:41

However, I will tell you, 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 over the last 20 years is that people wish they could work like is described in Inspired. 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.

1:48

But 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. Product discovery is build to learn. Everybody in this room, I hope you don't leave this session without an understanding that there are two kinds of building: building to learn and building to earn. It comes from a guy named Jeff Patton as a term. But we have lots of terms for this. It's the difference between product discovery and product delivery.

1:56

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, a totally different job. Your job is to make sure that when they do build that thing, you achieve the outcome you need.

2:01

Thanks to AI, the principles of the product model, the craft of product strategy and product discovery have never been more important. I really hope this was useful to everybody. I do want to thank Sri Ash 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. 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.

2:29

Because that's not actually the job of products. 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

3:18

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. But 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

4:00

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

4:41

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

5:28

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

6:06

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.

6:44

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 Cloud Code? I mean, I love that space. However, you need to understand this. It's one of the few areas

7:29

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 big advantage. I felt like that was my sort of superpower. But today, I would argue going forward

8:12

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

8:56

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 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,

9:29

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

10:09

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 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?

10:52

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 them. 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

11:26

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.

12:15

And yeah, this might sound like a personality trait to you, but it's not. I would argue this that 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 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.

13:09

But consider for a second the two big artifacts in the product world. Roadmaps and PRDs. So roadmaps, of course, the prioritized list 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 till this morning. And I'm like, despite Claire's optimism, I guarantee your roadmaps are not going away.

13:58

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.

14:40

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.

15:29

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, 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

16:13

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 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

16:54

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 list of problems to be solved. Another one that just is tough, corporate governance. I'm not talking about PMO, which is process

17:31

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 Ries' new book, Incorruptible. You know, this is a funny one. Product is just not as genteel

18:15

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, I, this is

19:01

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 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 was right about this. In many companies, process is

19:56

used as a substitute for thinking. So please don't fall out. 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. I really regretted that. 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

20:36

years, is that 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.

21:26

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.

22:00

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 Sri Ash 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.

Reading tools

Type to find a passage

Appearance
Ask this transcript

Notebook

Export Markdown

Add a note