[Webinar] CX for the AI Era: Fireside Chat with Sunil Joseph, VP of CS & Support at OpenRouter Register Now

CONTENT

Product Insights

August 28, 2026

Key Lessons with Marty Cagan on Building in the AI Era

A recap of Enterpret's fireside chat with Marty Cagan, founder of Silicon Valley Product Group and author of Inspired, Empowered, and Transformed.

The number we can't stop thinking about since our conversation with Marty: in the traditional project model, only ~20% of what teams ship actually achieves the intended outcome. The other 80% ships, goes live, doesn't break... and then customers simply choose not to use it. They stay with what they were doing before.

Now layer AI on top of that. Teams are measurably faster. Both McKinsey and Atlassian have documented the same pattern and given it a name: the AI productivity paradox. Teams get faster. Outcomes don't get better.

This gap is the single most important thing for product teams to understand right now. We sat down with Marty Cagan to unpack why it's happening and what the best teams are doing differently.

The paradox is predictable if you're running the wrong model

Marty draws a hard line between two operating models, and almost everything downstream depends on which one you're in.

In the project model, executives (or your largest customers) drive a roadmap. They request and demand features. A set of leaders triages what gets built, prioritizes it on a roadmap, and eventually, something percolates to the top and it's time to build. You make sure it works, make sure people can figure it out, and push it live. That's it. The problem has always been the same: this way of working achieves the intended outcome maybe one time in five. Not because it crashes or has egregious usability issues, but because it wasn't the solution the customer actually wanted.

In the product model, teams are given a problem to solve and an outcome to achieve, and they do the discovery work to find a solution that's valuable, usable, feasible, and viable before they commit to building it for real.

Most companies are using AI to speed up the project model. So of course they get faster without getting better. If your process reliably produces the wrong thing, doing it faster just gets you to the wrong thing sooner.

The companies genuinely making use of AI don't build this way, and the strong pre-AI companies haven't for decades.

Build to learn vs. build to earn

Another important distinction from Marty was his framing of building to learn versus building to earn.

Building to learn is prototyping. Figuring out a solution that will actually solve the business problem.

Building to earn is taking a proven solution and making something your business can run on, monetize, afford, market, sell, and service.

The AI tooling story splits cleanly along this line. Cursor, Claude Code, and Codex are on fire because they are extraordinary at build to earn. Marty's assessment is that these tools have already accomplished more in the last couple of years than the previous fifty years combined, and they're only getting better. Most teams in the project model are only doing build to earn, so that's where all their AI leverage goes.

But run the logic forward. If the cost to build-to-earn collapses, the bottleneck moves. It moves to what do we build? What will actually achieve the outcome? And answering that is build to learn, a.k.a. discovery. Good product teams were doing 30, 40, 50 prototypes a week in discovery long before AI (it's a big part of why Figma became so valuable). The difference now is that almost anyone can do it if they put in the work to learn the craft.

The point of a prototype is not to hand it to engineers and say "build a product version of this." The point is to test it with users, buyers, and stakeholders, and make sure engineers can actually build it without feasibility surprises. That's why you need so many iterations. For a significant new capability, Marty says 25 to 50 prototype iterations is not unusual before you get it right.

This is the mindset shift every PM should internalize: when the cost of building drops, the value of deciding what to build goes up. Discovery isn't the slow part anymore. It's the whole game.

The team is shrinking. The scope is growing.

Two years ago, the typical team was one product manager, one product designer, and five to ten engineers. Today the engineering count is dropping fast. In some teams to three or four, in a few to a single engineer doing what five did before. It's a moving target, but the direction is clear.

What's easy to miss is the second change happening underneath: as the team shrinks, the scope it owns expands. New-generation tools can analyze multi-million-line codebases almost instantly, allowing engineers to wrap their heads around much larger chunks of the product. And that solves one of the oldest, most hated problems in product: dependencies. The nightmare where you know how to fix something customers are screaming about, but it takes ten teams working together to do it. Bigger scope means end-to-end ownership, which means teams don't just get empowerment, they get autonomy. That's the thing teams really love.

Interestingly, Marty noted that the product-to-engineer ratio is going up in the near term: fewer engineers, with more weight on the product role.

The roles are not collapsing (and this is where Marty changed his mind)

The loudest narrative in product right now is that PM, design, and engineering are collapsing into one "builder." A year ago, that was a view many of us shared. Marty's position is more precise, and it comes down to which model you're in.

In the project model, the roles are converging. This is really a polite way of saying you don't need product managers. And Marty agrees you don't. In the project model you never really did; you needed project managers, and most PMs were doing project management with a title that felt better. He calls it Product Management Theater.

In the product model, those skills are more necessary than ever. When empowered teams have to make real choices about value and viability, someone has to own them. That doesn't have to be three people. Marty has "triple threat" friends with deep skills across all three areas, but a triple threat is genuinely rare, and he's quick to say he isn't one. People who say the roles are collapsing often don't understand what a PM does in the product model, or they're picturing the Agile "product owner" administrative role—which is a role, not a job.

His verdict on each:

Engineering: Strong future, not going away. The PMs who tried to skip engineers and do build-to-earn themselves learned the hard way. It's been a fiasco.
Product management: Stronger than ever. AI products are probabilistic, and the risks are higher and harder than conventional products. This is a hard job that needs someone with the skills to do it.
Design: The hardest one to call. Code-generating models are doing a genuinely good job on parts of design, which puts the role under stress. But for complex, human-facing products the best designers in the industry are joining the AI companies right now. If those companies didn't believe design was essential, they wouldn't be hiring them.

Marty's bet: as the volume of software explodes, there will be a premium on software that feels like it's for you, that understands you, that feels beautiful to use. Taste, product sense, design sense will matter more, not less.

Why enterprise software has been allowed to be bad

We got honest about a frustration a lot of us share: most enterprise software is pretty horrible. How does it survive? Its saving grace is that the people who buy it aren't the people who use it. Users can be in pain every day and the business buyer still sees positive value.

Will AI fix this? Marty is measured. The bar to build your own is lower, but far fewer people are doing it than he expected. He cited Benedict Evans' explanation: the users of software are very different from the people equipped to build products for those users.

There are real forces pushing quality up, though. Consumerization of the enterprise is real, and there are B2B products today that are genuinely delightful. Platforms are being re-architected so that agents are first-class users. And AI-powered economics (high marginal cost, unlike conventional software) are pushing the industry toward pay-for-performance, pay-for-real-value pricing, which Marty thinks is a good change overall.

The one-line takeaway

If you take one thing from the whole conversation, take the note we ended on: go talk to a customer today. Jeff Bezos' line to his early teams was that the biggest mistake is listening to customers, and the second biggest mistake is not listening to customers. Customers live the pain. They don't necessarily know the solution, because the solution depends on what's newly possible. Your job is to know the pain deeply and to figure out what's possible. AI can't do that part for you.

Q&A from the audience

How do you actually measure the impact of AI tools and the ROI?

Straightforward, but not easy. The project model measures output. What did we ship? Shipping matters—ship nothing and you have no chance of achieving anything. But the product model measures outcomes. Did we solve a real customer problem in a way customers love and that works for the business? Reframed as a metric: the project model optimizes for time to market, the product model optimizes for time-to-money. Once time-to-money is the goal, you work completely differently. This is exactly what OKRs were built for. Andy Grove created them at Intel to give teams a problem to solve (the objective) and an outcome to achieve (the key result). It's been around forever. Most people don't use it well because it's simple but hard, and those are two different things.

Any reference examples of a fully integrated, AI-powered product-development lifecycle stack versus copilots or AI chat used in isolation?

Marty pushed back on the framing, and we loved it. You do not want a single integrated AI stack. That would be a genuinely bad move. Build-to-learn and build-to-earn are completely different activities, with different goals, different skills, and different context. Forcing them into one pipeline is the wrong architecture. His deeper point was about the impulse behind the question: people are hungry for structure, for a framework, for a playbook, for a recipe. "Give me the next step." But successful product is all about thinking. The framing that wants one integrated stack is implicitly saying I don't want to think. Bad move.

Who's doing this well right now? Any new voices to follow?

Several of the people you'd expect are still the best at it: Teresa Torres has been exploring discovery for AI products specifically for two years and is doing the best thinking Marty has found on it. He also subscribes to Lenny Rachitsky's newsletter for the range of perspectives. His own focus is on principles that stay true, and the ones that become even more important in the AI era. His most honest note: the people at the top AI companies don't fully know either. Even they don't completely understand how the system works—a situation he says is nearly unprecedented in tech. The closest parallel he's lived through is the internet disruption. Uncertain and a little scary, yes. Also the most exciting opportunity in a generation.