Marty Cagan Blames Product Failures on Process Addiction

Lenny's Podcast

The obsession with predictable roadmaps and rigid process allows product teams to bypass rigorous thinking, leading directly to systemic failure.

AI-assisted summary of Marty Cagan: Strong Opinions, loosely held — original source. Check the original for full context.

Source published: 2026-09-25

Key ideas

Re-evaluating decades of product advice in the wake of AI, Marty Cagan shares his top 10 regrets since publishing the first edition of Inspired in 2008, arguing that durable principles and business outcomes matter far more than frameworks or automated workflows. (1:53)
Cagan calls omitting business viability as a core risk in the 2008 edition of Inspired his most embarrassing blind spot—a mistake rooted in his background in developer tools—and warns that mastering viability across marketing, sales, legal, privacy, safety, and ethics is exponentially harder and more vital for AI products. (5:36)
Rather than acting as problem-validation gatekeepers or "CEOs of the product," product managers must embrace intellectual humility, focus the bulk of their energy on solution discovery, and talk directly to churning users to uncover why people abandon their products. (8:22)
An addiction to schedule predictability, unvalidated feature roadmaps, and paint-by-numbers processes often serves as an escape from rigorous thinking, whereas empowered product teams actually require strong product leadership to provide strategic context and navigate corporate politics. (12:36)
Because AI makes generating output fast and trivial, the value of product management shifts decisively from shipping minor code changes to "building to learn"—using rapid discovery to ensure that when engineering "builds to earn," business outcomes are guaranteed. (20:16)

Detailed notes

## Background Published by Lenny's Podcast on YouTube on September 25, 2026, this keynote captures Marty Cagan speaking live at the Lenny and Friends Summit in San Francisco. According to the description, Cagan reflects on ten personal regrets regarding his product management advice—spanning business viability, product leadership, and solution discovery—while examining how the rise of AI makes rigorous thinking and outcome-oriented work more essential than ever.

## TL;DR Reflecting on his influential career and the legacy of his seminal book Inspired, Marty Cagan candidly outlines his top ten regrets, admitting he long understated business viability, neglected the vital role of product leadership, and allowed teams to prioritize problem discovery over the hard work of solution discovery. He critiques the tech industry's obsessive craving for artificial predictability—manifested through rigid roadmaps and PRDs—as an escape mechanism from deep, disciplined thinking. Finally, Cagan argues that as AI makes engineering output cheap and rapid, product managers must move away from delivery-focused mercenary work and master 'building to learn' to drive genuine customer and business outcomes.

## Atmosphere & style The presentation carries a refreshingly humble, reflective, yet intellectually sharp tone as a seasoned industry icon deconstructs his own foundational teachings before a room of ardent followers. Cagan balances self-deprecating humor with unvarnished critiques of widespread industry dogmas, speaking with the relaxed confidence of a practitioner who has weathered multiple technological waves. Listening feels like an intimate, candid masterclass in intellectual honesty, shifting from nostalgic reminiscence to an urgent, pragmatic challenge for modern product builders.

## Bulletin - [01:53](https://www.youtube.com/watch?v=fF3lkTCM5-c&t=113s) Re-evaluating decades of product advice in the wake of AI, Marty Cagan shares his top 10 regrets since publishing the first edition of Inspired in 2008, arguing that durable principles and business outcomes matter far more than frameworks or automated workflows. - [05:36](https://www.youtube.com/watch?v=fF3lkTCM5-c&t=336s) Cagan calls omitting business viability as a core risk in the 2008 edition of Inspired his most embarrassing blind spot—a mistake rooted in his background in developer tools—and warns that mastering viability across marketing, sales, legal, privacy, safety, and ethics is exponentially harder and more vital for AI products. - [08:22](https://www.youtube.com/watch?v=fF3lkTCM5-c&t=502s) Rather than acting as problem-validation gatekeepers or "CEOs of the product," product managers must embrace intellectual humility, focus the bulk of their energy on solution discovery, and talk directly to churning users to uncover why people abandon their products. - [12:36](https://www.youtube.com/watch?v=fF3lkTCM5-c&t=756s) An addiction to schedule predictability, unvalidated feature roadmaps, and paint-by-numbers processes often serves as an escape from rigorous thinking, whereas empowered product teams actually require strong product leadership to provide strategic context and navigate corporate politics. - [20:16](https://www.youtube.com/watch?v=fF3lkTCM5-c&t=1216s) Because AI makes generating output fast and trivial, the value of product management shifts decisively from shipping minor code changes to "building to learn"—using rapid discovery to ensure that when engineering "builds to earn," business outcomes are guaranteed.

## Key takeaways - [01:53](https://www.youtube.com/watch?v=fF3lkTCM5-c&t=113s) The tech industry remains divided between the "project model" and the "product model," where the actual job of product is not adopting the latest process, framework, or agent automation, but solving customer problems to achieve business outcomes. - [05:36](https://www.youtube.com/watch?v=fF3lkTCM5-c&t=336s) Omitting business viability from the 2008 first edition of Inspired (which only listed value, usability, and feasibility risks) was a 10-year blind spot caused by Cagan's career in developer tools; in the AI era, holistic systems thinking around marketing, sales, legal, privacy, safety, and ethics is a primary imperative for PMs. - [08:22](https://www.youtube.com/watch?v=fF3lkTCM5-c&t=502s) Product managers frequently over-index on problem discovery and act as validation gatekeepers, robbing teams of the time needed for solution discovery—which is where real innovation happens and where products actually succeed or fail. - [09:47](https://www.youtube.com/watch?v=fF3lkTCM5-c&t=587s) While a clear product strategy easily explains why a team is working on a given problem, teams routinely fail to ask a far more critical "why": talking directly to users who churn to understand why people are not adopting the product. - [11:19](https://www.youtube.com/watch?v=fF3lkTCM5-c&t=679s) The popular takeaway that a PM is the "CEO of the product" is the exact antithesis of the humility required in product management—rigorously knowing what you cannot know and admitting what you don't know—and acts as a direct root cause of product failure. - [12:36](https://www.youtube.com/watch?v=fF3lkTCM5-c&t=756s) The deep-seated addiction to predictability is at war with innovation and outcomes; placing unproven features on timeline roadmaps wastes engineering capacity (even with AI, "the tokens aren't free"), and PRDs are only harmless communication devices after discovery evidence has validated a solution. - [15:19](https://www.youtube.com/watch?v=fF3lkTCM5-c&t=919s) Good product work does not win purely on its own merits without navigating corporate politics, an organizational reality that has accounted for roughly half of Cagan's new content over the last three years. - [15:19](https://www.youtube.com/watch?v=fF3lkTCM5-c&t=919s) Focusing Inspired almost exclusively on team-level discovery mechanics unintentionally created a leadership vacuum; empowered product teams do not need less management, they need better product leadership to provide context and a clear product strategy. - [17:25](https://www.youtube.com/watch?v=fF3lkTCM5-c&t=1045s) Even world-class product execution can be derailed by misaligned corporate governance or ownership changes following an acquisition, a structural challenge Cagan connects to Eric Ries's book Incorruptible. - [17:25](https://www.youtube.com/watch?v=fF3lkTCM5-c&t=1045s) Rather than an elegant academic exercise, open-market product management is a "full contact blood sport" where a product must be dramatically superior to alternatives to convince customers to switch. - [18:58](https://www.youtube.com/watch?v=fF3lkTCM5-c&t=1138s) Organizations routinely use rigid processes, paint-by-numbers frameworks, and now large language models as a substitute to avoid the deep, disciplined thinking required for product work. - [20:16](https://www.youtube.com/watch?v=fF3lkTCM5-c&t=1216s) As AI makes generating output near-instantaneous, product managers must focus on Jeff Patton's concept of "building to learn" (fast discovery prototyping to test assumptions) rather than submitting minor front-end pull requests, ensuring that when engineers "build to earn" in production delivery, business outcomes are assured.

## Detailed walkthrough ### [00:06](https://www.youtube.com/watch?v=fF3lkTCM5-c&t=6s) Two Worlds of Product: The Project Model vs. The Product Model

Marty Cagan opens his talk at the Lenny and Friends Summit by thanking Lenny for inviting him, admitting that while he doesn't attend many conferences, he thoroughly enjoys them when he does. Throughout the day, so many attendees came up to thank him for his content and ask him to sign their tattered copies of *Inspired* that he lost track—an experience he describes as both hugely flattering and humbling. However, he laughs that he had to warn several of those fans that his talk today is actually all about his regrets, "of which there are quite a few."

Having sat in the audience listening to every single talk all day, Cagan shares a striking observation: there are two distinct kinds of product in the world, which he has always called the "project model" and the "product model." Roughly half of the day's speakers came from each camp, presenting dramatically different definitions of the product job. While Cagan openly admits he is highly biased, his work spans both worlds, making the contrast fascinating to watch. As he listened to certain talks, he initially felt an urge to correct the record onstage—"Oh, I got to talk about this and I got to talk about that. I don't want them to leave thinking this"—until speakers Robbie from Google and Kayi took the stage and said essentially everything he would have said, which he loved.

[01:53](https://www.youtube.com/watch?v=fF3lkTCM5-c&t=113s) Durable Principles vs. The AI Wave

Rather than rehashing those points, Cagan pivots to a difficult exercise he has been procrastinating on for a long time: re-examining the core arguments he has spent decades defending. For those unfamiliar with his work, he makes his philosophy clear: "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." While those things might provide helpful tooling, the actual job of product is "to solve problems for our customers and achieve outcomes for our business."

Because Cagan focuses on underlying principles rather than fleeting frameworks, his advice has remained remarkably durable across technology waves—joking that someone earlier gave a very polite introduction implying he must be very old to have witnessed so many waves. With every new wave, he asks whether the shift will invalidate those foundational principles. He became a product person precisely because what is newly possible is constantly changing, which is what makes the career so exciting. However, with the arrival of AI, he felt compelled to scrutinize everything from scratch, including principles he was taught were sacred and untouchable.

Treating his own content as a product, Cagan conducts product discovery every single week with product teams—including his conversations with attendees at the summit—to test and refine his ideas. Normally, he publishes articles to address minor learnings, but this time he brainstormed a massive, "kind of depressing" list of things he got wrong and narrowed it down to his top 10 genuine regrets. To frame this retrospective, he draws the starting line at 2008, the year the first edition of *Inspired* was published (noting with a grin that some people in the room weren't even born yet). Even back in 2008, he had already been in product and engineering leadership for 25 years, learning from amazing people at "the Anthropics of the day." Yet despite that deep pedigree, his list of 10 big regrets spans mistakes dating back to that first book all the way to realizations from less than six months ago.

[05:36](https://www.youtube.com/watch?v=fF3lkTCM5-c&t=336s) Regret 1: Understating Business Viability

Cagan begins with what he considers his most embarrassing regret: "I completely understated the importance of business viability." In the product model, a product manager's job is to ensure a solution is something the customer will buy *and* something that works for the business—meaning the company can afford to market, sell, and service it, while ensuring it is legal, compliant, and respects privacy, safety, and ethics. While business viability was already a massive responsibility before AI, anyone building AI products today knows it has become exponentially harder.

The embarrassing truth, Cagan confesses, is that the first edition of *Inspired* didn't even list business viability as a core risk, focusing only on three risks: value, usability, and feasibility, with viability buried inside them. It took him 10 years to fix that omission in the second edition. Doing deep introspection on how he could have maintained such a huge blind spot for so long, he traced it back to his own career background: he spent almost his entire career working on developer tools and platforms. While he still adores that space ("Who doesn't love Claude Code?"), he warns that developer tools are one of the few product areas where a product manager can get away with relatively weak business viability skills because the viability landscape there is much simpler.

```mermaid flowchart TD accTitle: Evolution of Core Product Risks in Inspired accDescr: Compares the three product risks in the 2008 first edition of Inspired with the four risks in the 2018 second edition, highlighting the addition of Business Viability. subgraph Ed1["Inspired 1st Edition (2008)"] V1["Value Risk"] U1["Usability Risk"] F1["Feasibility Risk"] end subgraph Ed2["Inspired 2nd Edition (2018) & AI Era"] V2["Value Risk"] U2["Usability Risk"] F2["Feasibility Risk"] BV["Business Viability Risk<br/>(Marketing, Sales, Legal, Privacy, Safety, Ethics)"] end Ed1 -->|"10 years later: Fixed blind spot"| Ed2 ```

For most products—and especially for AI products—that simplicity does not exist. Cagan notes that he used to view his engineering academic background and technical knowledge as his personal superpower because it helped him quickly grasp new technologies. Going forward, however, he argues that the true imperative for product managers to succeed at every level is mastering business viability from a holistic, systems-thinking perspective.

[08:22](https://www.youtube.com/watch?v=fF3lkTCM5-c&t=502s) Regret 2: Overemphasizing Problem Discovery Over Solution Discovery

His second regret centers on the balance within product discovery, which consists of two parts: problem discovery (figuring out what problem to solve) and solution discovery (actually solving that problem). Cagan's mistake was failing to anticipate just how strongly product managers would gravitate toward the problem discovery side of the equation. Many PMs have come to view themselves primarily as gatekeepers whose main job is to validate and agree on whether a problem is worth solving.

While a PM obviously needs to understand the problem, who they are solving it for, and the definition of success, Cagan stresses that "honestly, that's not very hard." Spending excessive time on problem discovery robs teams of the time needed for what they are actually paid to do: solution discovery. When a product fails, teams often rationalize it by claiming there wasn't enough market demand or not enough people had the problem. "You're almost always wrong," Cagan counters, pointing out that as soon as a competitor comes out with a better solution and succeeds, it proves market demand was never the issue. He wishes he had told teams to spend just a little bit of time on problem discovery and save the bulk of their energy for solution discovery, because "that's the essence, that's where innovation happens."

[09:47](https://www.youtube.com/watch?v=fF3lkTCM5-c&t=587s) Regret 3: Focusing on the Wrong "Why"

For his third issue, Cagan reflects on how much time he spent preaching the importance of helping teams understand *why* they are working on a given problem. Quoting John Doerr's famous maxim—"we need teams of missionaries, not teams of mercenaries"—Cagan had long argued that creating missionaries requires explaining the overarching reason behind the work. While that remains true, he now realizes that communicating that initial "why" is actually quite easy; if an organization has a proper product strategy, the reasons for tackling specific problems are already spelled out clearly for everyone to see.

Instead, Cagan highlights a much more critical "why" that Robbie from Google had called out earlier in the day: "Why are people not using our product?" Cagan was thrilled to hear a Google leader emphasize this, noting with a touch of irony that for a while Google acted as if everything could be answered purely through data without ever talking to users. In reality, teams must talk directly to customers to uncover why they aren't adopting a product. As an early adopter who constantly tests new products himself, Cagan bluntly observes that "most of them are crap products"—he tries them out, sees they aren't good, and immediately churns, yet almost nobody ever follows up with him to ask why.

[11:19](https://www.youtube.com/watch?v=fF3lkTCM5-c&t=679s) The Overlooked Power of Churn and True Humility

Reflecting on customer behavior, Cagan expresses bewilderment at how infrequently companies ask the most fundamental question: why are people using or abandoning the product? Having recently churned from a service without receiving so much as a single follow-up email or survey asking why, he emphasizes that understanding why customers walk away is the primary key to unlocking breakthrough innovation, yet it remains routinely ignored by product teams.

This missed opportunity ties directly into the next major regret: the necessity of humility. Cagan explains that as his career has progressed, he has come to appreciate just how critical an open mind is at every level of product. Humility in product does not mean meekness; it means rigorously "knowing what you can't know and admitting what you don't know." Unfortunately, rather than taking away a message of intellectual honesty and curiosity, the broad tech industry walked away from his books with the takeaway that the product manager is the "CEO of the product"—the exact antithesis of humility. This misunderstanding is not merely an annoying personality trait; Cagan argues it acts as a direct root cause of product failure.

---

[12:36](https://www.youtube.com/watch?v=fF3lkTCM5-c&t=756s) The Addiction to Predictability, Roadmaps, and PRDs

Cagan identifies what may be his single greatest regret: vastly underestimating how deep-seated and powerful the addiction to predictability is among both product practitioners and executive leadership. Predictability is inherently at war with humility, innovation, and outcome-oriented work.

To illustrate this tension, Cagan addresses the perennial controversy surrounding the two canonical product artifacts: roadmaps (prioritized feature lists mapped to timelines) and PRDs (product requirements documents). These artifacts actively trick teams into believing they know answers they cannot possibly know:

* **PRDs as Arrogance vs. Communication:** If a PM drafts a PRD out of arrogance, presuming they already know the solution and handing engineering rigid requirements to build, they are trapped in the waterfall-like project model that causes failure. Conversely, if a team has already validated hypotheses, run discovery experiments, and gathered conclusive evidence that the solution will deliver business outcomes, the PRD transforms into a harmless and genuinely useful communication device. * **Roadmaps and Wasted Cycles:** Placing unproven feature ideas against arbitrary calendar dates wastes immense engineering capacity. While AI tools may make writing code faster and cheaper, building the wrong thing remains a waste of resources—because "the tokens aren't free." * **The Core Trade-off:** While some predictability is naturally necessary in business, trading off actual business outcomes and customer trust to maintain an illusion of schedule predictability is fatal.

```mermaid flowchart TD accTitle: The Two Paths of Product Artifacts accDescr: Contrasting the predictability-driven project model with the evidence-driven product model for PRDs and Roadmaps.

subgraph Trap["The Predictability Trap (Project Model)"] direction TB A1["Unvalidated Feature Ideas & Fixed Dates"] --> B1["PRD Written as Rigid Specifications"] B1 --> C1["Engineering Delivery Capacity Wasted"] C1 --> D1["Failure to Achieve Desired Outcomes"] end

subgraph Model["The Evidence-Driven Product Model"] direction TB A2["Prioritized Strategic Problems"] --> B2["Rapid Discovery & Customer Validation"] B2 --> C2["PRD as Communication Device for Proven Solutions"] C2 --> D2["Predictable Value & Business Outcomes"] end ```

---

[15:19](https://www.youtube.com/watch?v=fF3lkTCM5-c&t=919s) Corporate Politics and the Omission of Product Leadership

Cagan candidly admits his early career naivety regarding organizational politics. He long believed that simply executing good product work would win on its own merits, but corporate politics are woven into the fabric of every organization. Over the last three years, roughly half of all his new writing and content has been dedicated strictly to managing company politics (with the remaining half focusing on AI).

This blind spot ties directly into what he considers perhaps the most damaging legacy of his seminal book *Inspired*. Because Cagan loved the craft of product discovery, he intentionally wrote *Inspired* focused almost exclusively on the mechanics of product teams. He barely touched upon product leadership, not anticipating the downstream consequences:

* **The Leadership Vacuum:** Organizations mistakenly concluded from *Inspired* that building great products required nothing more than standing up autonomous, "empowered product teams" with strong PMs, stripping away management layers. * **The Real Role of Management:** Empowered product teams do not need less management; they need *better* management. Without product leadership providing critical context and establishing a clear product strategy—defined as a prioritized list of specific problems to solve—empowered teams drift aimlessly.

---

[17:25](https://www.youtube.com/watch?v=fF3lkTCM5-c&t=1045s) Corporate Governance and Product as a Blood Sport

Cagan touches upon two harsh realities of the commercial product world that his earlier, more idealistic writings smoothed over:

* **Corporate Governance vs. PMO Governance:** Beyond bureaucratic process governance, broader corporate governance and ownership structures can derail great work. Cagan recounts the heartbreak of coaching product organizations to world-class execution, only to see the company acquired or overtaken by external stakeholders with misaligned motivations who strip away the product vision. He directs practitioners to Eric Ries's book *Incorruptible* for an honest treatment of this structural challenge. * **A "Full Contact Blood Sport":** In his early books, Cagan described product management with an almost academic elegance: "solve problems in ways your customers love but work for your business." While accurate, that framing conceals the harsh competitive reality. In an open market, a product cannot just be adequate; it must be dramatically superior to alternatives to convince customers to switch. Modern product is a contact sport, and under-preparing teams for that ruthless competitive pressure leaves them vulnerable.

---

[18:58](https://www.youtube.com/watch?v=fF3lkTCM5-c&t=1138s) Process as an Escape from Thinking

Cagan underscores what he sees as the central requirement of product work: deep, disciplined thinking. His major regret was failing to anticipate "the lengths that people would go to in order to avoid thinking."

When teams seek to bypass cognitive effort, they inevitably develop an obsessive craving for process, paint-by-numbers frameworks, and artificial predictability. Cagan admits that organizing *Inspired* around the triad of "People, Process, and Product" was an error because it legitimized process obsession. Echoing Elon Musk's critique that companies routinely use process as a substitute for thinking, Cagan warns that large language models are now at risk of becoming the latest crutch teams lean on to dodge real reasoning. True product sense requires raw cognitive effort, not dogmatic framework compliance.

---

[20:16](https://www.youtube.com/watch?v=fF3lkTCM5-c&t=1216s) Building to Learn vs. Building to Earn in the Age of AI

Despite his list of ten regrets, Cagan concludes on an optimistic note regarding the future of product. Over the past two decades, the most common objection to his teachings was that working in an empowered, outcome-driven way was simply too difficult for organizations addicted to output. However, the rise of AI is radically reshaping that dynamic:

* **The Shift to Outcomes:** Because AI makes the generation of output trivial and near-instantaneous, organizations are forced to realize that output itself has minimal standalone value; business outcomes are all that matter. * **Discovery vs. Delivery:** Cagan references Jeff Patton's framework differentiating the two core modes of engineering and product work: * **Building to Learn:** The heart of product discovery. Fast, cheap, lightweight prototyping designed to test assumptions, discover viability, and ensure that a proposed solution will work before serious investment occurs. * **Building to Earn:** The domain of product delivery. Hardening production systems, optimizing code, and deploying reliable solutions to generate business value.

Cagan cautions product managers that if their primary day-to-day contribution is submitting minor pull requests on the front end, they may be better off transitioning to pure software engineering. The true responsibility of the product manager is discovering what to build so that when engineers commit to delivery, success is assured. Thanks to the acceleration brought by AI, foundational product strategy and discovery have never been more critical.

Cagan closes by expressing his gratitude to Shreyas Doshi and Teresa Torres for reviewing early iterations of the presentation, and thanks Lenny Rachitsky for hosting the summit.

## Notable quotes > [01:53](https://www.youtube.com/watch?v=fF3lkTCM5-c&t=113s) 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. — Marty Cagan

> [01:53](https://www.youtube.com/watch?v=fF3lkTCM5-c&t=113s) to solve problems for our customers and achieve outcomes for our business. — Marty Cagan

> [05:36](https://www.youtube.com/watch?v=fF3lkTCM5-c&t=336s) I completely understated the importance of business viability. — Marty Cagan

> [08:22](https://www.youtube.com/watch?v=fF3lkTCM5-c&t=502s) You're almost always wrong — Marty Cagan

> [08:22](https://www.youtube.com/watch?v=fF3lkTCM5-c&t=502s) that's the essence, that's where innovation happens. — Marty Cagan

> [09:47](https://www.youtube.com/watch?v=fF3lkTCM5-c&t=587s) Why are people not using our product? — Marty Cagan

> [11:19](https://www.youtube.com/watch?v=fF3lkTCM5-c&t=679s) knowing what you can't know and admitting what you don't know. — Marty Cagan

> [12:36](https://www.youtube.com/watch?v=fF3lkTCM5-c&t=756s) the tokens aren't free. — Marty Cagan

> [17:25](https://www.youtube.com/watch?v=fF3lkTCM5-c&t=1045s) solve problems in ways your customers love but work for your business. — Marty Cagan

> [18:58](https://www.youtube.com/watch?v=fF3lkTCM5-c&t=1138s) the lengths that people would go to in order to avoid thinking. — Marty Cagan

## Mentioned Marty Cagan, Lenny Rachitsky, Lenny and Friends Summit, Inspired, Robbie, Google, Kayi, Anthropic, Claude Code, John Doerr, Eric Ries, Incorruptible, Elon Musk, Jeff Patton, Shreyas Doshi, Teresa Torres

## Video description At Lenny and Friends Summit, Marty Cagan shares ten regrets about his product advice, from underestimating business viability and product leadership to placing too little emphasis on solution discovery. He explains how the pursuit of predictable roadmaps and processes can keep teams from learning what customers need. As AI makes building easier, he argues that clear thinking and a focus on outcomes matter more than ever.

Recorded live at Lenny and Friends Summit on September 10, 2026, in San Francisco.

[Source](https://www.youtube.com/watch?v=fF3lkTCM5-c)

中文简报

Marty Cagan将产品失败归咎于对流程的沉迷对可预测路线图和僵化流程的痴迷，让产品团队得以逃避严密思考，从而直接导致系统性失败。回顾自己颇具影响力的职业生涯以及经典著作《Inspired》留下的深远影响，Marty Cagan坦诚列出了自己的十大遗憾，承认自己长期低估了商业可行性、忽视了产品领导力的关键作用，并任由团队将精力偏向问题探索而非艰巨的解决方案探索。他批评科技行业对虚假可预测性的病态渴望——表现为僵化的路线图和PRD——是一种逃避深度、严谨思考的机制。最后，Cagan指出，随着AI让工程产出变得廉价而快速，产品经理必须摆脱以交付为中心的雇佣军式工作，掌握“以构建促学习”，从而推动真正的客户与商业成果。在AI浪潮下重新审视数十年的产品建议，Marty Cagan分享了他自2008年出版第一版《Inspired》以来的十大遗憾，认为持久的原则和商业成果远比框架或自动化工作流重要得多。 (1:53) Cagan表示，在2008年版《Inspired》中遗漏商业可行性作为核心风险，是他最尴尬的盲点——这一错误源于他的开发者工具背景——并警告说，涵盖营销、销售、法律、隐私、安全和伦理的可行性把控呈指数级难度上升，对AI产品而言更是至关重要。 (5:36) 产品经理不应扮演问题验证的守门人或“产品的CEO”，而必须保持求知上的谦逊，将大部分精力集中在解决方案的探索上，并直接与流失用户交流以查明人们放弃产品的原因。 (8:22) 对进度可预测性、未经验证的功能路线图以及照本宣科式流程的沉迷，往往沦为逃避严谨思考的借口，而赋能型产品团队实际上需要强大的产品领导力来提供战略背景并应对企业政治。 (12:36) 由于AI让产出生成变得快速且微不足道，产品管理的价值已决定性地从交付细微代码更改，转向“以构建促学习”——即通过快速探索来确保当工程团队“以构建促营收”时，商业成果能够得到保障。 (20:16)

Reading summary

Marty Cagan reassesses his foundational product principles, arguing that the discipline's true purpose—solving customer problems while achieving business outcomes—has been compromised by an obsession with artificial predictability, uncritical frameworks, and an underappreciation of business viability and leadership. Rebalancing Business Viability and Solution Discovery (5:36) Cagan identifies understating business viability as his most embarrassing career regret. The 2008 first edition of Inspired omitted viability as an explicit core risk—focusing solely on value, usability, and feasibility—which took a decade to rectify in the second edition. Cagan attributes this blind spot to his career in developer tools, an area where viability concerns are uniquely straightforward. In contrast, mainstream products and modern AI applications demand systems-level mastery of commercial realities, including marketing, sales, compliance, privacy, safety, and legal constraints. Simultaneously, Cagan cautions that product managers have over-indexed on problem discovery at the expense of solution discovery. While understanding the target user and problem is necessary, Cagan observes that many practitioners act primarily as problem gatekeepers. Because market failure rarely stems from a lack of user demand but rather from inadequate solutions, he argues teams should spend minimal time validating problems and direct the bulk of their energy toward solution discovery, where breakthrough innovation occurs. Intellectual Humility and Escaping Predictability Traps (12:36) Rather than explaining why teams work on a given initiative—a rationale that should already be evident in a clear product strategy—Cagan argues teams routinely fail to ask the most critical question: why users abandon the product. While examining customer churn provides direct insight into product deficiencies, teams rarely investigate why early adopters leave. This missed opportunity is exacerbated by the industry myth of the product manager as the "CEO of the product," an attitude Cagan views as the direct opposite of the intellectual humility needed to admit what one does not know. A lack of humility also fuels an addiction to predictability among practitioners and leadership. Artifacts such as calendar-based feature roadmaps and rigid product requirements documents (PRDs) create a false sense of certainty. Cagan explains that PRDs written out of arrogance enforce a waterfall project model that squanders engineering capacity. Conversely, PRDs used to communicate validated, evidence-backed solutions remain useful. Ultimately, adherence to rigid frameworks and process often serves as a substitute to avoid deep, disciplined thinking. The Necessity of Leadership, Strategy, and Politics (15:19) A major unintended consequence of Inspired was the misconception that organizations only need autonomous, empowered product teams without managerial oversight. Cagan clarifies that empowered teams do not need less management; they need better management. Without product leadership establishing strategic context and prioritizing specific problems to solve, autonomous teams drift without clear direction. Cagan also reflects on his early naivety regarding organizational dynamics, noting that half of his recent writing focuses specifically on navigating corporate politics. Sound product craft alone cannot protect teams from misaligned ownership, corporate governance shifts, or disruptive acquisitions. Furthermore, Cagan emphasizes that commercial product development is a ruthless competitive contact sport where products must be dramatically superior to existing alternatives, rather than merely functional. Differentiating Discovery and Delivery with AI (20:16) Cagan argues that the rise of artificial intelligence reinforces the necessity of the product model over the project model. Because AI tools make code generation and feature output cheap and rapid, organizations can no longer mistake output volume for genuine business value. Building the wrong features remains an expensive waste of delivery capacity, as computing tokens and engineering resources are not free. Citing Jeff Patton's framework, Cagan distinguishes between "building to learn" (rapid discovery prototyping to test viability and value assumptions) and "building to earn" (hardening delivery code to generate revenue). Cagan warns product managers that if their primary contribution is writing minor front-end code changes, they may belong in engineering. The primary responsibility of product management remains discovering what to build so that engineering commitments deliver validated business outcomes. While AI accelerates software production, Cagan maintains that fundamental principles—prioritizing business outcomes over output, navigating viability constraints, and practicing intellectual humility—remain the ultimate determinants of product success.

Source quotes

[1:53] Marty Cagan: 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. [1:53] Marty Cagan: to solve problems for our customers and achieve outcomes for our business. [5:36] Marty Cagan: I completely understated the importance of business viability. [8:22] Marty Cagan: You're almost always wrong [8:22] Marty Cagan: that's the essence, that's where innovation happens. [9:47] Marty Cagan: Why are people not using our product? [11:19] Marty Cagan: knowing what you can't know and admitting what you don't know. [12:36] Marty Cagan: the tokens aren't free. [17:25] Marty Cagan: solve problems in ways your customers love but work for your business. [18:58] Marty Cagan: the lengths that people would go to in order to avoid thinking.

Original transcript

[0:06] Thank you. Um, also thank you to Lenny [0:09] for running this and for inviting me [0:12] actually to be a speaker. Um, I don't [0:16] actually go to a lot of conferences. Uh, [0:18] but when I do, um, I really enjoy them [0:21] and I will tell you I can't I lost track [0:23] of the people that came up to me and [0:26] thanked me for content for books. People [0:29] ask me to they have tattered copies of [0:31] inspired and they ask for signatures and [0:34] it's you know hugely uh flattering and [0:37] humbling to see that. I did warn several [0:41] of them that my talk was actually all [0:43] about [0:45] my regrets [0:48] uh of which there are uh quite a few. [0:52] So that is what I wanted to talk about. [0:55] But I have been here with you all day [0:57] listening to every one of the talks. And [1:00] um I learned something really [1:03] interesting from every single one of [1:05] them. I observed and I'm sharing this [1:08] for a reason, but I observed that there [1:10] are two kinds of product in the world. [1:14] Two kinds. I've always called them the [1:16] project model and the product model. [1:18] About half the speakers were from each. [1:20] Obviously, I'm highly biased, but my [1:23] world is both of them. And so, it's [1:26] super interesting for me to hear, but [1:28] hopefully you all can think back on the [1:30] day and you saw dramatically different [1:34] definitions of the job. [1:37] Now, the truth is, as I was listening, I [1:39] was like, "Oh, I got to talk about this [1:40] and I got to talk about that. I don't [1:41] want them to leave thinking this." But [1:43] then Robbie from Google and Ki basically [1:47] said what I would have said. loved it. [1:50] Again, I'm biased, but loved them. [1:53] What I want to talk about here is a [1:56] little different. Honestly, it's uh [1:58] something I've known I've needed to do [2:00] for a long time, but I kept sort of [2:02] procrastinating on it because uh this is [2:06] a really hard question, especially for [2:09] me. I have spent decades arguing certain [2:13] points. Now, for those that don't know [2:16] my work, I am actually one of those [2:18] people. I'm not interested in the latest [2:21] process. I'm not interested in the [2:22] latest framework. I don't really care [2:24] what you created an agent to automate. [2:28] I don't care because that's not actually [2:31] the job of product. [2:33] That might give you some tooling to help [2:36] you do the job, but that's not the job. [2:39] The job of product is to solve problems [2:43] for our customers and achieve outcomes [2:46] for our business. That's what this is [2:49] about. So that's what I'm interested in. [2:52] And because I focus on principles, the [2:56] truth is they're pretty durable. In [2:59] fact, every time a new technology wave, [3:01] you heard a very polite way of saying I [3:04] must be very old to have seen all of [3:06] these waves. But yeah, every wave you're [3:10] like, will this invalidate those [3:12] principles? [3:13] You don't really know until you look at [3:15] it. And of course, as as you know, all [3:18] those waves were actually a lot of fun. [3:19] I am one of those. I mean, the reason [3:21] I'm a product person is because I love [3:23] the fact that what's just now possible [3:26] is changing all the time. That's what [3:29] makes it cool. Otherwise, I would not be [3:31] doing this this area. I wouldn't have [3:32] chosen this as a career. But with AI, [3:38] I feel like I had to look at everything. [3:40] Even the things that honestly I was [3:43] taught are sacred. It's like you don't [3:46] mess with this principle. I wanted to [3:49] look at everything. That's what I did. [3:52] Now, the first thing I had to figure out [3:54] was where do I start? Because the truth [3:56] is I treat my content as my product and [4:00] I am literally doing product discovery [4:03] every single week with product teams. In [4:06] fact, a lot of many of you have been [4:08] with me to know that's what I'm doing. [4:10] I'm learning. That's what I've been [4:12] doing here today is really discovery on [4:14] product content. And it was very good [4:17] for me to hear these other views, all of [4:19] the other views. But anyway, the truth [4:22] is I have a lot of things I've learned. [4:23] Now most of the time I just write [4:25] articles and publish stuff on more minor [4:27] learnings. But what I wanted to do [4:31] was to identify what I thought that I [4:34] mean honestly I started brainstorming a [4:36] list and it's a big list. It's kind of [4:39] depressing but there's a big list. I [4:41] wanted to pick the top 10 things that I [4:44] genuinely regret. I genuinely if I knew [4:48] then what I knew now now I decided to [4:51] draw the line with the publication of [4:53] the first edition of inspired which was [4:56] in 2008 which I some of you weren't even [4:59] born then but that's when I'm drawing [5:02] the line but you have to realize I had [5:04] been doing product for 25 years when I [5:07] wrote that. So I had been a product [5:09] manager. I went through the whole [5:11] engineering side and I was a product [5:13] leader for two and a half decades. So I [5:17] had learned a lot from amazing people at [5:20] some, you know, honestly the anthropics [5:22] of the day, really good companies. So I [5:26] decided let's draw the line there. Even [5:28] though some of the things I'm going to [5:29] talk about are regrets that are less [5:32] than six months old. Let's do that. [5:34] Let's talk about it. 10 big things. The [5:37] first one I want to start with is [5:39] business viability because that's [5:41] honestly the most embarrassing of them. [5:44] There is no way for me to get around [5:46] this. I completely understated the [5:49] importance of business viability. Just [5:52] so that everybody knows what I'm talking [5:54] about here. Business viability. This is [5:56] a product manager's job is to make sure [5:58] at least in the product model is to make [6:01] sure that the solutions are both the [6:04] customer will buy it and it works for [6:06] the business. That means you can afford [6:08] to market it, you can sell it, you can [6:10] service it, it's legal, it's compliant, [6:12] it respects privacy, safety, ethics. [6:16] This is a big thing even before AI. It's [6:19] big. Those of you working on AI [6:21] products, you know it's even harder. [6:23] Business viability is a really big area. [6:26] But the embarrassing truth is [6:29] in the first edition of Inspire. I [6:32] didn't even talk about it as a risk. [6:34] Value, usability, feasibility. There [6:36] were three risks that we talked about. [6:38] Viability was buried in there. I'm [6:40] embarrassed to say that. Now, I fixed it [6:42] in the second edition, but that was 10 [6:44] years later. This is one of those I had [6:46] a lot of introspection because the truth [6:48] is I kept asking how could I have gone [6:51] so long with such a huge [6:55] blind spot around products and I believe [7:00] I know the answer to that and I want to [7:02] share it with you because it's very [7:04] relevant even today maybe even [7:06] especially today because in my career [7:10] for those that might know I almost all [7:13] of my career I was working on developer [7:15] tools and platforms [7:18] which I still absolutely love that [7:20] space. Who doesn't love claude code? I [7:22] mean I love that space. However, you [7:25] need to understand this. It's one of the [7:27] few areas [7:29] where a product manager can get away [7:32] with pretty weak skills. Now, that's not [7:36] the only one, but it's one of them. Now, [7:38] that's not a a criticism. It's kind of a [7:40] an advantage for those kinds of [7:43] products. It's a much simpler space for [7:46] viability. But for most products, [7:49] especially for AI products, that is not [7:52] true. And in fact, I used to be very [7:55] excited about my um knowledge of [7:57] engineering because I felt like it [7:59] helped me learn new technologies. I came [8:01] from an engineering background. That's [8:02] what I studied. And it was like big [8:04] advantage. I felt like that was my my [8:06] sort of superpower. But today [8:10] I would argue going forward and for all [8:13] of you to succeed at every level, [8:16] business viability, [8:18] especially from a holistic systems [8:21] thinking perspective. Second, problem [8:24] discovery. Now the tr you know, I've [8:27] always talked about product discovery [8:29] has got problem discovery, figuring out [8:31] what problem you're going to solve and [8:32] solution discovery, solving that [8:34] problem. The truth is the mistake I made [8:37] was I just did not understand [8:41] how strongly people would be drawn to [8:45] the problem discovery side of that [8:47] equation. In fact, [8:50] a lot of people view themselves as the [8:52] gatekeeper. That's their job as product [8:55] managers to make sure they agree this is [8:57] a problem to solve. Yes, you obviously [8:59] need to make sure you understand the [9:01] problem, who you're solving it for, and [9:03] what the definition of success is. But [9:05] honestly, that's not very hard. It's not [9:08] very hard. And if you spend a lot of [9:10] time on that, you're not going to do the [9:12] real part you're paid for, which is [9:14] solution discovery. You might think when [9:17] a product fails, it's because you didn't [9:20] um you know, it wasn't a big enough [9:21] demand, not enough people had that [9:23] problem. you're almost always wrong [9:25] because what's going on is as soon as [9:27] somebody else comes out with a better [9:28] solution all of a sudden we know that [9:31] that was never the issue. So problem [9:34] discovery I should have emphasized yes [9:38] problem discovery important little bit [9:41] of time save time for solution discovery [9:44] that's the essence that's where [9:45] innovation happens the next big issue um [9:49] and this is another one all of these [9:52] kind of have uh you know good and bad [9:55] sides but um I spent a lot of time [9:58] talking about how important it is to [10:01] understand the reason why we're working [10:03] on whatever we're working on, whatever [10:05] problem we're working on. I didn't make [10:06] this phrase up. John Door did, but we [10:08] need teams of missionaries, not teams of [10:10] mercenaries. If you want missionaries, [10:13] you have to make sure they understand [10:15] the reason. And yeah, that is important, [10:20] but that's so easy. And in fact, if you [10:24] have a product strategy, which you [10:26] should, we'll talk about that in a [10:28] little bit. the reasons you're working [10:31] on these problems is spelled out for the [10:33] whole organization to see. So there's no [10:36] big mystery. So what I want to talk [10:39] about and I was really happy to see that [10:42] Robbie called this out. There is a much [10:44] more important why than why are we [10:47] working on this problem and that is why [10:50] are people not using our product. He [10:52] called that out. I would love seeing [10:54] that. And honestly that's kind of a [10:55] surprise for Google. for for a while [10:57] they thought it was all based on data [10:58] and we're not going to talk to No, we [11:01] need to actually talk to our customers [11:03] to figure out why. I try products [11:06] constantly. I bet most of you do too. [11:07] That's what product people do. We're [11:09] early adopters. We try it out. Most of [11:11] them are crap products. You know this, [11:13] right? We try it. We're not good. So, I [11:15] churn. Almost nobody follows up anyway. [11:19] Nothing. Not a survey, not a email, [11:22] nothing to ask me why I churn. Probably [11:25] the single most important question is [11:28] why are people using our product or not [11:31] using our product? And the part that [11:33] really gets me is that's the key to [11:35] unlocking so much innovation. And yet [11:38] most teams never ask that question. The [11:42] next one, humility. You know, the longer [11:45] I go, the more important I realize that [11:47] humility and a a truly open mind is so [11:51] important to product people at every [11:53] level. What does that really mean? [11:54] Humility. It means knowing what you [11:57] can't know and admitting what you don't [12:00] know. Many of you know this, but instead [12:03] most people the message they took away [12:05] from my books was the C the product [12:08] manager should be CEO of the product, [12:11] which is kind of the opposite of a [12:12] humility message. [12:15] And [12:16] yeah, this might sound like a [12:18] personality trait to you, but it's not. [12:22] I would argue this [12:25] contributes directly to the root cause [12:29] of so many failed products, which really [12:32] leads me to maybe my single biggest [12:34] regret. [12:36] I honestly had no idea and I just didn't [12:42] appreciate how powerful and deeply [12:46] rooted the desire for predictability [12:49] was. And that's from both product people [12:52] and senior executives and how at odds [12:55] that desire for predictability is with [12:58] not just humility but innovation and [13:02] outcomes. [13:04] Consider for a second I'm opening a can [13:07] of worms here. I probably shouldn't but [13:10] consider for a second the two big [13:12] artifacts in the product world maps and [13:16] PRDS. So road maps of course the [13:18] prioritized lists of features we think [13:20] we need to build and when and the PRDS [13:23] which is how we describe the requirement [13:24] of those features. Now for a second [13:28] consider how much of an enabler [13:33] those artifacts are for thinking that we [13:36] know more than we really do. This is [13:39] such an important point and so many [13:42] people misunderstand this. You know, [13:44] people keep asking the question, do you [13:47] still need PRDs? Do we still need road [13:49] maps? I I never heard that one posed [13:51] till this morning. Uh despite Claire's [13:54] optimism, I guarantee your road maps are [13:56] not going away. [13:59] We all know that the issue is not [14:02] whether they are there. And it's never [14:05] been whether they are there. The issue [14:07] is what are you using that PRD for? If [14:10] you're using it because you're forgive [14:14] me arrogance and you think you know the [14:16] answer so you're putting it in terms of [14:19] requirements for your engineers to build [14:22] that's the project model that's the root [14:25] cause of so many failed products. If [14:28] however you have learned and tested and [14:32] and gathered the evidence you need to [14:34] know what's going to be built is going [14:36] to achieve the outcome then the PRD is [14:39] just your communication device. It's not [14:42] only harmless, it's actually useful. The [14:44] same is true with road maps. If you put [14:47] a bunch of features that are somebody's [14:49] idea of what might work and you put [14:52] dates there, you're going to waste most [14:54] of your time. you're going to end up [14:56] wasting most of the engineering [14:58] capacity. And yes, the engineering time [15:00] has gone way down. You're still wasting [15:02] it. And the tokens aren't free. So [15:05] predictability [15:07] is at the root of this. And [15:09] predictability is important, but it's [15:11] not as important or worth uh trading off [15:15] outcomes or trust. [15:19] Politics. The truth is I I we all know [15:23] politics is important, but I thought [15:25] good product work will carry the day. [15:27] That was of course naive. [15:30] And the truth is politics are [15:33] everywhere. They're in the fabric of [15:35] every company. And I now if you look at [15:39] the last three years of my content, half [15:41] of it is with dealing with politics and [15:44] the other half is dealing with the [15:45] impact of AI. It is a big topic. This is [15:50] probably the one with the long long most [15:53] damage created from uh like the book [15:56] inspired. My initial work was all about [16:00] product teams and product discovery [16:03] because to me I what I really love is [16:05] the craft of products and I wanted to [16:08] write about the craft of product because [16:10] there's a lot of principles and a lot of [16:12] techniques and most people were just [16:13] building stuff and shipping it and [16:16] seeing what sticks and that's still true [16:18] today. And that was an intentional [16:20] choice to focus on the on the teams and [16:25] the craft of product discovery. What I [16:27] didn't appreciate was I I almost hardly [16:31] mention product leadership, but I didn't [16:34] realize the consequences of that choice. [16:38] And the result is so many companies and [16:40] I'm I'm sad to say this, this is still [16:42] true today because by far somehow all [16:45] these years later, Inspired is still [16:47] selling like crazy. A lot of teams just [16:49] read inspired and they think all they [16:52] need to do is set up product teams, [16:54] empowered product teams, a strong [16:55] product manager, you can be awesome, and [16:58] they think that's all they need to do [16:59] and they'll be good. And of course, what [17:01] so many companies have learned is that [17:03] in empowered product teams, you don't [17:05] just need less management, you need [17:07] better management. And the role of [17:10] product leadership is so critical. You [17:13] just heard from Kyrie the point about [17:15] context. That is what's so critical. At [17:17] a minimum, it's the product strategy, [17:19] which is your your prioritized list of [17:22] problems to be solved. Another one that [17:25] just um it's tough corporate governance. [17:28] I I'm not talking about PMO, which is [17:31] process governance governance. I'm [17:33] talking about corporate governance here. [17:35] Oversight of the company. I I we've own [17:39] all known that's a problem, but um I [17:41] said this isn't something product can do [17:43] anything about. And uh one of the most [17:45] painful lessons over the years is [17:47] helping so many companies actually get [17:49] better at shipping great products only [17:52] to see they become a target for [17:56] people with very different motivations [17:57] that are pro going to pull the product [17:59] in a different direction. So that's sad. [18:03] If you've I would encourage everybody to [18:05] read Eric Reese's new book [18:06] incorruptible. [18:09] You know that this is a funny one. [18:12] product is just not as gental as I made [18:16] it sound in my books. It almost sounds [18:19] academic, right? Where okay, your job is [18:21] to solve problems in ways your customers [18:23] love but work for your business. Yes, [18:26] that's true. But it kind of hides the [18:28] fact that it's not enough. You actually [18:32] have to solve problems in ways that are [18:35] dramatically better than your [18:37] competition if you're going to get [18:38] people to switch. And the truth is that [18:42] product today a comp in the competitive [18:44] open market product is a full contact [18:48] blood sport and most people from my [18:52] content you would not get that and a lot [18:55] of teams aren't prepared. And the last [18:58] point [19:00] uh and you know I uh this is a point a [19:02] few people have brought up which I'm [19:04] thrilled to see but fundamentally good [19:07] product work is about thinking. [19:11] It's about thinking and I here's what's [19:14] the the mistake. I did not appreciate [19:19] the lengths that people would go to in [19:22] order to avoid thinking. [19:26] Uh, I wish I was joking. Uh, what does [19:29] it show up as? It shows up as a craving [19:32] for process, frameworks, and [19:35] predictability. I structured inspired as [19:38] people, process, and product. Big [19:40] mistake. And I am worried that large [19:43] language models will be used as an [19:45] alternative to thinking, but the truth [19:47] is that's already happened [19:49] with process. And the truth is Elon Musk [19:52] was right about this. In many companies, [19:55] process is used as a substitute for [19:57] thinking. So, please don't fall. I [20:00] should have called that out. Called out [20:02] thinking, called out the necessary [20:04] foundation of product sense much more [20:07] loudly and clearly. All right, those are [20:10] the 10 big things that um I really [20:14] genuinely regret. [20:16] However, I will tell you, funny enough, [20:19] ironically, I am feeling really good [20:22] about the content overall, but more [20:25] importantly, about all of our future as [20:28] products. And I want to try to explain [20:30] why. The main criticism that I've [20:33] received on my content, honestly, over [20:35] the last 20 years is that um people wish [20:39] they could work like is described in [20:41] Inspire. They wish they could. And they [20:43] tell me there are two problems. One, [20:46] their company is addicted to output [20:49] and the predictability of that output. [20:52] And two, it's hard. They think it's [20:54] going to be hard to work that way. But [20:57] look, in no small part, thanks to AI [21:01] today, more places than ever understand [21:05] the need for outcomes and not just [21:08] output. And also, it is dramatically [21:12] easier. You know, we talk about product [21:14] discovery is build to learn. Everybody [21:16] in this room, I hope you don't leave [21:18] this session without an understanding [21:21] that there's two kinds of building. [21:23] Building to learn and building to earn. [21:26] I that comes from many of you know a guy [21:28] named Jeff Patton as a term, but we have [21:31] lots of terms for this. But it's the [21:33] difference between product discovery and [21:34] product delivery. If you want to spend [21:37] your time doing some pull requests on [21:39] the front end, fine. Maybe you should [21:41] just go be a developer. [21:43] But if you want to make sure that what [21:46] your engineers do build and provide to [21:48] your customers, you should be building [21:51] the learned, it's a totally different [21:53] approach, totally different job. Your [21:56] job is to make sure that when they do [21:57] build that thing, you achieve the [21:59] outcome you need. So here's the thing. [22:01] Thanks to AI, the principles of the [22:04] product model, the craft of product [22:06] strategy and product discovery [22:10] have never been more important. All [22:12] right, I really hope this was useful to [22:15] everybody. I do want to thank Shri Doshi [22:17] and Teresa Torres who gave me feedback [22:20] on early versions of this. And I again I [22:22] want to thank Lenny for putting this [22:24] party together. I hope this was useful. [22:26] Thank you very much.