Predictable Roadmaps Can Hide How Little Product Teams Know

Marty Cagan’s central concern is that product teams and executives often want predictability so badly that they mistake plans for evidence. Roadmaps and PRDs can make uncertain ideas look settled: a list of features and dates implies the team knows what to build, while requirements can turn an untested proposal into instructions for engineers.

For Cagan, the problem is not that these artifacts exist. It is what a team uses them to claim. If a team has learned and tested enough to have evidence that its solution can achieve the outcome it needs, a PRD can be a useful communication device. If it is used to tell engineers what to build because someone assumes the answer is already known, it reflects the project model he criticizes.

Roadmaps pose the same risk. A sequence of speculative features with dates can consume engineering capacity without delivering the intended results. Predictability matters, Cagan says, but not enough to justify sacrificing outcomes or trust. Even if engineering time has become cheaper, it is still being spent—and, he adds, tokens are not free.

This tension runs through his regrets about how he presented product work. He says he underestimated how deeply product people and senior executives want predictability, and how that desire can work against humility, innovation, and outcomes. Humility, in his account, means knowing what you cannot know and admitting what you do not know. He regrets that many readers instead took from his books the idea that the product manager should be “CEO of the product,” a message he considers nearly the opposite.

The practical alternative is not to discard plans or process, but to make room for learning and to be clear about what the team knows. Cagan describes good product work as requiring thought and judgment, not simply adherence to a framework. He now sees his decision to structure Inspired around “people, process, and product” as a mistake: he wishes he had emphasized thinking, and the product sense that depends on it, much more clearly.

Cagan worries that large language models could become another substitute for thinking. But he argues the pattern predates AI: process itself has served that role in many companies. Process can help a team work; it cannot replace judgment about what customers need or whether a proposed solution is likely to achieve an outcome. His regret is not that teams use frameworks, but that they can use process and predictability to avoid the thinking product work requires.

Cagan separates product discovery into problem discovery—figuring out what problem to address—and solution discovery—figuring out how to solve it. He says he did not appreciate how strongly people would be drawn to the first, sometimes treating the product manager as a gatekeeper whose main job is to decide whether a problem is worth solving.

Teams do need to understand whose problem they are addressing and what success means. But Cagan considers those questions comparatively straightforward. His concern is that teams can spend so much time agreeing on the problem that they leave too little for solution discovery, which he calls the essence of the work and where innovation happens. Understanding the problem matters; it is not the whole job.

When a product fails, teams may conclude that demand was too weak or that too few people had the problem. Cagan says they are almost always wrong to make that diagnosis. A better solution from another product can show that the problem was not the issue. The team still has to discover what solution works.

He also revises the “why” he thinks product teams should pursue. He has long emphasized that people need to understand why they are working on a problem, invoking John Doerr’s phrase “teams of missionaries, not teams of mercenaries.” But Cagan says a product strategy should make the organization’s reasons for choosing problems visible. The more neglected question, in his view, is why people are not using a product.

Cagan describes himself as someone who regularly tries new products, finds many of them poor, and stops using them. He says companies almost never follow up with a survey, email, or other question about why he churned. He sees that silence as a missed opportunity to understand product use and uncover possible innovation. For him, asking why people do—or do not—use a product can reveal opportunities that teams will miss if they focus only on why a problem was chosen.

Cagan’s regrets about product leadership and corporate politics qualify the idea that better discovery is enough. His early writing deliberately concentrated on the craft of product—especially teams and discovery—because he wanted to explain how to solve customer problems. He says he barely addressed product leadership and did not appreciate what that omission would mean.

Some companies, he says, read Inspired as though setting up empowered teams and appointing strong product managers would be sufficient. But empowered teams do not need simply less management; they need better management. Leadership has to provide context, including a product strategy that prioritizes the problems the organization intends to solve. Without that context, autonomy alone does not tell teams where to focus.

Nor does evidence automatically determine what happens to a product. Cagan says he had assumed good product work would carry the day; he now calls that naive. Politics, he argues, are present throughout companies. He distinguishes corporate governance—the oversight of the company—from process governance, such as the work of a project-management office. He once treated corporate governance as something product teams could not affect. After helping companies get better at shipping products only to see them redirected by people with different motivations, he finds that separation difficult to maintain.

Competitive pressure makes the gap between good work and successful work consequential. Cagan says it is not enough to solve problems in ways customers love and the business can support. In an open market, a product may need to solve them dramatically better than the competition’s offering to persuade people to switch. He calls product “a full contact blood sport” and says his earlier writing did not prepare enough teams for that reality.

These constraints compound. Teams may identify a customer problem and test possible solutions, yet lack the strategy, leadership, or organizational support to pursue what they learn. And even a product that survives internal politics still has to be compelling against alternatives. Cagan’s regret is not just that he left out individual topics; it is that a focus on craft alone can make product work sound more insulated from power and competition than it is.

Cagan names business viability as his most embarrassing omission. In the first edition of Inspired, he discussed value, usability, and feasibility as product risks, but did not give viability comparable standing. He says he corrected this in the second edition, ten years later.

By viability, he means whether a solution works for the business as well as whether customers will buy it. The business must be able to market, sell, and service the product; the product must also be legal and compliant, and respect privacy, safety, and ethics. Cagan says those questions were already substantial before AI and are harder for AI products.

He traces his blind spot partly to his own experience. Much of his career was spent on developer tools and platforms, a field where, he says, product managers can get by with relatively weak business skills. He had regarded his engineering background as a major advantage because it helped him understand new technologies. Looking ahead, he argues that business viability—especially viewed through holistic systems thinking—will matter for product people at every level.

The slide shown during this passage presents book covers and publication years: Inspired (2008), a second Inspired edition (2018), Empowered (2020), and Transformed (2024). Cagan says he had already spent 25 years working in product before publishing the first edition in 2008. He uses that first edition as the line for organizing his regrets, while noting that some of the lessons he discusses are much more recent. The slide’s dates show the decade between the two Inspired editions; Cagan says he fixed the viability omission in the second edition, ten years later.

Despite these regrets, Cagan says he is optimistic about product work. He argues that more organizations than before understand the need to focus on outcomes rather than output, and that it is now dramatically easier to work in the way he described in Inspired.

He uses a distinction he credits to Jeff Patton: building to learn and building to earn. Building to learn is product discovery; building to earn is product delivery. The first is about learning what solution will work. The second is about building what will be provided to customers. Cagan’s point is that product people should help ensure that what engineers build is aimed at achieving the needed outcome, rather than treating the volume of output as the goal.

He draws a sharp boundary between that responsibility and simply doing implementation work. Someone who wants to spend time making front-end pull requests, he says, might be better suited to development. The product role is to help establish that what gets built for customers is likely to achieve the outcome the team needs; it is not a claim that the team can know the result in advance without discovery.

That is why, in Cagan’s view, AI does not make the principles of the product model less important. He says the principles of product strategy and discovery have never been more important. Teams still have to think clearly, test their assumptions, understand what customers do and do not use, and consider whether a product works for the business. For Cagan, building to learn and building to earn are different kinds of work, and the former helps teams make better decisions about the latter.