Ten Regrets: Marty Cagan on What He Got Wrong About Product

Speaking at Lenny and Friends Summit, Marty Cagan observes that the day's talks fell into two camps, which he has always called the project model and the product model. Roughly half the speakers came from each, and he suggests the audience saw two dramatically different definitions of the job. He notes that two of the earlier speakers had already said much of what he would have said.

Cagan says he does not care about the latest process, framework or agent that automates a task. Those may offer tooling, but the job of product is to solve problems for customers and achieve outcomes for the business. Because he focuses on principles, he argues, they have proved durable across every technology wave he has lived through.

AI, however, pushed him to examine even the things he was taught were sacred. He treats his content as his product and does discovery on it weekly, so he set out to pick the ten things he most genuinely regrets. He draws the line at the 2008 first edition of *Inspired*, written after about 25 years in product, though some regrets are less than six months old.

The first regret is business viability, which Cagan calls the most embarrassing. A product manager must make sure a solution works for the business: it can be marketed, sold and serviced, and it is legal, compliant, and respects privacy, safety and ethics. The first edition of *Inspired* listed value, usability and feasibility as the risks and barely mentioned viability, which he fixed in the second edition a decade later.

He traces the blind spot to his career in developer tools and platforms, a space he still loves. In his view it is one of the few areas where a product manager can get away with fairly weak skills, because viability is much simpler there. For most products, and especially AI products, that is not true, and he now sees holistic, systems-level viability thinking as essential at every level.

The second regret is about problem discovery. Cagan did not foresee how strongly people would be drawn to it, with many product managers seeing themselves as gatekeepers who approve which problems to solve. Understanding the problem, the audience and the definition of success matters, he says, but it is not very hard, and over-investing in it leaves less time for solution discovery, where innovation happens.

He adds that when a product fails, people blame too little demand, but they are almost always wrong. As soon as a competitor ships a better solution, it becomes clear that demand was never the issue.

Cagan next takes aim at his emphasis on explaining why a team is working on a given problem. He credits John Doerr with the line about missionaries rather than mercenaries, and agrees missionaries need to understand the reason. But if the company has a product strategy, he says, that reasoning is already spelled out for everyone, so it is the easy part.

The far more important "why", he argues, is why people are not using the product. He was glad that a Google speaker called this out, and notes that Google once believed the answer lay in data alone. He says teams need to talk to customers, and he shows how rarely they do: he churns from products all the time and almost never gets a survey or an email asking why.

The fourth regret is humility, which he describes as knowing what you can't know and admitting what you don't know. Many readers took away that the product manager should be the "CEO of the product", which is nearly the opposite message. He argues this is not just a personality trait but a direct contributor to the root cause of many failed products.

Cagan calls his single biggest regret not appreciating how deeply rooted the desire for predictability is, among both product people and senior executives. That desire is at odds with humility, with innovation and with outcomes. He frames it as opening a can of worms by turning to the two big artifacts of the product world: roadmaps and PRDs.

Roadmaps are prioritized lists of features and dates, and PRDs describe the requirements for those features. Cagan asks the audience to consider how much these artifacts enable the belief that we know more than we do. He says he guarantees roadmaps are not going away despite one speaker's optimism, and that the real question is what you use them for.

If a PRD simply hands engineers requirements based on someone's confident guess, that is the project model, and he calls it the root cause of many failed products. If the team has tested and gathered enough evidence that what is built will achieve the outcome, the PRD is merely a communication device and is useful. Roadmaps work the same way: filling them with untested ideas and dates wastes engineering capacity, and even though engineering time has fallen, he notes that tokens are not free.

On politics, Cagan says he naively assumed good product work would carry the day. In reality, politics are woven into the fabric of every company, and he says half of his content in the last three years deals with politics while the other half deals with AI's impact.

The regret he says has done the most lasting damage is that *Inspired* focused on teams and the craft of discovery and hardly mentioned product leadership. Many companies read it and conclude that setting up empowered teams with a strong product manager is enough, and the book still sells strongly. Companies have since learned that empowered teams need not less management but better management, starting at minimum with a product strategy, a prioritized list of problems to solve.

He also names tough corporate governance, meaning oversight of the company rather than process governance such as a PMO. He once believed this was beyond product's influence, and one of his most painful lessons is seeing companies get better at shipping great products only to become targets for people with different motivations. He recommends Eric Ries's new book *Incorruptible* on the topic.

Cagan says he made product sound too genteel. Solving problems in ways customers love and that work for the business is true but insufficient: you must solve them dramatically better than the competition to get people to switch. In a competitive open market, he says, product is a full-contact blood sport, and many teams reading his work would not realize that or be prepared for it.

His last regret is that good product work is fundamentally about thinking, and he did not appreciate the lengths people go to in order to avoid it. It shows up as a craving for process, frameworks and predictability, and he regrets structuring *Inspired* as people, process and product. He worries that large language models will be used as an alternative to thinking, and says Elon Musk was right that many companies already use process as a substitute.

Despite the list, Cagan feels good about the content and about the future of product. The main criticism he hears is that readers wish they could work as *Inspired* describes, but their company is addicted to output and its predictability, and the approach seems hard. He argues that, partly thanks to AI, more organizations now understand outcomes over output, and working this way is dramatically easier.

He closes by distinguishing building to learn from building to earn, a framing he credits to Jeff Patton, which maps to product discovery versus delivery. If you want to merge pull requests, he says, you might as well be a developer. A product person's job is to make sure that what engineers build achieves the needed outcome, and with AI, the craft of product strategy and discovery has never been more important.