Faster is not better: notes from Marty Cagan's talk at WaysConf

On 17 September I sat in Marty Cagan's talk and Q&A at WaysConf in Kraków. It was a much needed talk for the Polish product community, and honestly, a much needed one for me. (The rest of the two days is in my WaysConf 2026 recap.)

I have been coaching product teams across Europe for years, and every so often I wonder whether my focus on discovery and strategy is too narrow. Then I run a workshop, or start with a new client, and I am reminded that a lot has changed, but most companies still run on a project model.

Cagan's talk was that reminder, delivered to a full room. Here is what I took away, and the one part I would push further.

Teams are shipping more, and results aren't following

His opening theme was what he calls the AI productivity paradox. Teams are producing more than ever. The business results are not moving with them.

He has written the argument up as The AI Productivity Paradox on the SVPG site, where he cites Atlassian's State of Teams 2026 report: 89% of executives say AI has increased the speed of work, and only 6% feel confident they can point to organization-wide AI ROI.

His diagnosis is simple. The job of product people was never to ship features. It is to make sure that what the engineers build actually has an impact on customers and on the company. The project model measures output. Speed up a model that measures output, and what you get is more output.

This is the part I see in almost every engagement. Roughly 80% of features are rarely or never used. If that ratio holds and you double the number of features you ship, you have doubled the waste, not the value. I went through the cost side of this in building got 10x cheaper, building the right thing didn't, so I won't repeat it here.

Discovery just lost its best excuse

For years the most common reason I heard for skipping discovery was time. We don't have time for customer interviews. Testing ideas properly is slow. We'll learn after launch.

Cagan's point is that AI kills that excuse. Testing an idea before you build it is now dramatically faster than it used to be. He also mentioned using AI as a personal product coach, which is a use I see far less often than code generation, and one that probably matters more.

The distinction he leans on is build to learn versus build to earn. Discovery builds to learn: fast, rough, thrown away, never meant to scale. Delivery builds to earn: production quality, reliable, built to scale.

The line from the panel afterwards that stuck with me: anyone can build to learn now. Almost nobody can build to earn yet.

That is the trap. A prototype that looks like a product gets treated like a product. It gets a launch date, a sales deck, a support queue. The thing you built to answer a question quietly becomes the thing you have to maintain. It is why I keep calling it a prototype, not an MVP.

The admission I didn't expect

Then came the honest moment of the talk. Cagan said that the focus of Inspired on product managers, rather than product leaders, was his mistake. It helped convince a generation of product organizations that they did not need strong product leaders, while agile coaches told PMs that vision and strategy were theirs to own.

He said he would probably reverse that emphasis now. And he closed with the news that a third edition of Inspired is coming.

His definition of strategy was refreshingly concrete: deciding which problems we are solving this quarter. And the more teams you have, the more that strategic context matters, because without it every team optimizes locally.

This matches what I see. Empowered teams without strategic context do not become autonomous. They become busy in five directions at once, which is the failure I describe in if everything is a priority, nothing is.

Two smaller points landed too. A product manager has to learn the whole business viability context, because that is where product sense actually comes from. And designers stuck in a project model are doing what he called lipstick on a pig: polishing whatever was already decided, instead of shaping what gets decided.

Smaller teams, bigger scope

The panel after the talk was just as sharp, and it was mostly about team shape.

Two years ago, the typical product team was a PM, a designer and five to eight engineers. The panel's view is that it is moving toward a PM, a designer and one to three engineers. The ratio of PMs to engineers is going up, not down.

With AI, each team can carry more scope. That means less orchestration between teams, and teams that are not only more empowered but more autonomous. The panel also asked tech leads for a promise: care about what to build as much as how to build it.

This is the product trio argument with the volume turned up. When a team has two engineers, there is no room for one of them to sit outside discovery waiting for tickets. Everyone is in the room when the decision gets made, or the decision is worse.

Where I would push further

To be fair to the Polish market: over the last five years I have watched the number of product teams here, and across Europe, who understand the product operating model grow a lot. Many of them are actively trying to work that way.

But understanding the operating model and living it day to day are two very different things. Plenty of teams can explain empowered teams in a workshop and then go back to a roadmap of features with dates.

Usually the blocker sits at C-level. I don't think the change has to start there, though. A pilot inside one strong product team is a good start. Once it works, you scale it across the product organization, alongside the product leadership putting the strategy fundamentals in place. I made the longer case for starting with one team in "that looks good in theory, but won't work in practice".

If your teams are already using AI to ship faster and you want it to help them decide better, that is exactly what the AI-First workshop and sprint is built around. With AI commoditizing delivery, discovery and strategy matter more than ever, not less.