Claire Vo says AI has made software development dramatically faster, but judging what to build has actually become harder. When the traditional feature- and schedule-driven roadmap is combined with AI's near-unlimited execution power, it can lead into traps: burning down the backlog, copying competitors, and shipping repeatedly without learning. The new roadmap she proposes puts at its center not a list of features but big ambition, testable conviction, fast contact with customer reality, and a clear level of commitment.

1. Product Management Isn't Over, but It Has Changed Completely

Claire opens lightly, recalling that last year, on this same stage, she declared that "product management is dead." Of course, product management hasn't actually disappeared, and the room is full of excellent product leaders, PMs, and executives. Still, she stresses that in the short time since the last Lenny and Friends Summit, the landscape of product management has fundamentally changed.

This time, she says, she will talk not about product managers themselves but about the roadmap, which has been the most central tool of product organizations. A roadmap was originally a document that laid out where the team is heading, what comes next, and what matters. But having worked in product for more than 20 years, she believes many teams may now be writing their "last roadmap."

"The roadmap has been the most essential tool in our field and our careers. It was supposed to tell us where we're going, what's next, and what matters."

"I think many people in this room are now going to write their last roadmap."

2. Plenty of Execution Capacity, Too Few Good Ideas

Claire confesses that she is shipping more product now than at any point in her career. That's because she has an abundance of the tools needed for development and productization: excellent coding agents, development tools, high-performance models, customer-context data, APIs and CLIs, MCP, and more. She even mentions that she has built 40 Grok bots, describing a state in which she can now build almost anything.

But this is where the key confession comes in: the ability to build has exploded, but she has run out of good ideas worth building.

"I can build almost anything. But here's my honest confession: I've run out of good ideas."

"I can build it. But I don't know which of these is actually a good idea."

The problem she describes is not a lack of customer requests or features to implement. If anything, requests are overflowing. The problem is that execution capacity has outrun the ability to discover valuable products. In the past, engineering headcount was the scarcest resource, so the product team's job was to decide which of many ideas not to pursue. PMs had to keep saying "no" in meetings, in Slack, and in spreadsheets.

"Engineering capacity used to be the truly scarce resource. There were more ideas than people, and demand was far greater than we could handle."

"The PM's job was to prioritize and spend most of their time saying 'no.'"

Now, thanks to AI, development capacity is far less constrained. Claire says her bottleneck has shifted from "what can I build?" to "what do I truly believe is worth building?" In other words, the core constraint is no longer the speed of producing code or features but conviction about the product and the ability to verify the truth.

"My execution capacity is now greater than my real conviction about what to build."

"The remaining constraint isn't code, it isn't building, it isn't features. It's the truth."

3. The Uncomfortable Truth Revealed by a Product She Built Herself

Claire gives a real example from her own work. She built a product that gathers customer information, the work the company has in progress, and product-related knowledge in one place, and lets AI models and agents use it. It was a kind of product intelligence / product graph tool that helps PMs make better decisions and write better PRDs.

She built it quickly. She built an insights engine, a sophisticated semantic product graph, and even an auto-generated wiki. It worked, it looked good, and it was close enough to what competitors offered. The market existed, and customers said it was interesting.

Yet every time she built it, she says she felt this inside:

"This belongs in the trash. All this work and this great product belong in the trash."

The reason was simple: it might have been a competitive product, but it was not a distinctive one. Customers might want it and there seemed to be a market, but she wasn't confident it was valuable enough to earn customers' time. She kept questioning whether the interface was right, whether an agent-centric experience was right, and whether she was really building something competitors couldn't even imagine.

"There was clearly a market, and customers said it was interesting. Even so, I wasn't sure it deserved my customers' attention."

"I wanted to build something my competitors couldn't even imagine."

Her problem was that her roadmap and code had not been validated enough to back her "bet." She kept piling up code and shipping more software before testing or strengthening her conviction.

As AI automated repetitive customer fixes, technical-debt cleanup, redesigns, PR generation, and more, the organization looked like an "AI factory" running on its own. But she couldn't be sure that all that productivity was actually doing work that mattered.

"The AI factory did what we wanted. It was magical. But here's the secret: I wasn't sure any of it mattered."

4. Three Traps Created by AI Plus the Traditional Roadmap

Claire acknowledges that roadmaps made sense in an era when engineering resources were scarce. Back then you had to carefully weigh the effort, sequencing, milestones, and MVP scope of feature development, and those constraints also naturally filtered out bad ideas. Lower-priority ideas never shipped at all because there weren't enough engineers.

Now, however, AI makes it possible to build almost any idea. So even the bad ideas that execution constraints used to block can easily make it out into the world.

"Now we can ship all our bad ideas too. Congratulations."

"The cheaper execution gets, the more rigorous judgment has to be."

She explains that three traps arise in particular when the traditional roadmap is combined with excessive execution capacity.

The Backlog Burn-Down Trap

The first is the backlog trap. If there's a backlog, AI can implement all of it. So the team feels progress as the backlog shrinks, requests get handled, and features ship. But completing lots of requests is not at all the same as growing the business or actually solving customer problems.

"Finishing requests or ideas doesn't mean you've made real progress in the business or real progress on solving customer problems."

The Trap of Becoming Identical to Competitors

The second is the homogenization trap. Competitors hear similar things from the same customers, use similar AI tools, and end up arriving at similarly "obvious" answers. Everyone nudges quality up a bit, polishes the interface, removes the edges, and builds the same product faster.

"Every competitor copies each other, gets the same information from the same customers, reaches the same obvious conclusions, and builds the same product."

In this environment, the important question is still "What makes us different?" The more execution capacity levels out, the more differentiation has to come from perspective, customer understanding, quality standards, and long-term bets rather than feature lists.

The Ship-and-Abandon Trap

The third is the abandonment trap. When a team ships a product that turns out confusing or doesn't perform as hoped, it can immediately put out the next product instead of improving or learning. AI is so fast that it becomes easy to skip even the process of confronting failure and learning from it.

"We can always ship another product, so we abandon the product. Then we don't learn, and we don't evolve what we built."

From inside the organization, all of this can look extremely productive. The backlog shrinks, the feature count grows, and shipping frequency rises. But Claire warns that it can ultimately drive everyone rapidly into the middle of mediocrity.

5. In the "Zero Roadmap" Era, Prioritization Is Not Strategy

What Claire calls the zero roadmap does not mean an empty roadmap. Rather, it describes a situation where almost every visible feature is now buildable. If you can build everything on the list, can simply ordering the list be a strategy?

"If everything in the backlog is buildable, what's the point of a backlog?"

"Feasibility and effort are no longer valid signals of what matters."

In the past, development difficulty and required effort were themselves powerful criteria for prioritization. But once AI greatly lowers implementation difficulty, "do the easy things first" or "sort by impact versus effort" can no longer substitute for strategic judgment. If you bolt AI onto a traditional roadmap, you end up executing bad decisions much faster, without being able to tell important bets from mere ideas.

"This system can't tell the difference between an important bet and just an idea. AI only shows you the consequences of that bad judgment faster."

That's why Claire argues that feature- and date-driven roadmaps can be dangerous right now. A feature list can become ammunition loaded into a powerful AI execution engine, explosively increasing only the speed of execution in the wrong direction.

6. From Building to Proving: A New Operating Model for Validating Conviction

The shift Claire proposes is clear. Teams should no longer stop at simply building more; they need to move to a system for proving what they believe.

"We need to move from building to proving."

The flow she presents is as follows:

1. Establish strong conviction.
   Define the future direction you believe in, not a short-term quarterly plan. Ask not about features three or six months out but "Where is all of this ultimately going?"

2. Decide in advance what evidence would support or refute the conviction.
   Make it clear beforehand what you'd need to see to judge that you're heading in the right direction, and what would make you stop.

3. Keep a factory that can build fast.
   This doesn't mean abandoning the AI-driven development factory. On the contrary, you need a powerful execution engine to respond quickly to reality. But that factory should be a means of helping validation, not the entity that decides strategy.

4. Reallocate capital and effort after meeting reality.
   Use customer responses and real data to concentrate money, time, people, code, and attention on the convictions that have grown stronger.

"What would I have to see to know I'm right? What would make me stop?"

"What AI gives you is the ability to connect with reality faster. But it also raises your obligation to face reality."

What matters most here is real customers, real data, and repeated experiments. AI cannot turn untested assumptions into truth. Even multiple rounds of adversarial review cannot replace the reality that customers and the market provide.

7. Be Relentless About Conviction, Flexible About Solutions

The new environment requires "strong conviction and changeable features" at the same time. Teams and customers should be betting not on a single specific feature but on the team's problem definition, direction, view of the market, and long-term vision. Features can come and go, and can change based on experiments.

"What you need to show is clear progress toward conviction, not ego about your solution."

Claire explains this by distinguishing good stubbornness from bad stubbornness.

• Good stubbornness means holding firmly to the problem and the long-term conviction while continually revising the solution.
• Bad stubbornness means clinging to code or plans already written, changing the goal itself, or repeating "we're almost there, let's ship just a little more."

"Good stubbornness is being faithful to the problem and changing the solution."

"Bad stubbornness is changing the goal because the code exists."

She says not every release needs to be an immediate, permanent commitment. When a product goes out to market, you should honestly distinguish and communicate whether it is a hypothesis, an experiment, a more serious bet, or a commitment customers can depend on.

• Exploration stage: a hypothesis or early bet you're taking a light look at
• Experiment stage: a more serious attempt to test a core conviction
• Commitment stage: a product customers can depend on, and that the company takes responsibility for continuing to evolve

"This is a hypothesis. It's a real experiment, and I could be wrong. The market could change, and the technology could change dramatically."

"A commitment is a product customers can build their own customer base on, and trust that we'll keep evolving."

In particular, Claire stresses that code is abundant, but customer trust is scarce. That's also why she didn't rush to show customers the product intelligence features she had built. Customers can look at a feature and build their work and their organization on top of it, and if she lacks the conviction to stand behind that feature to the end, she loses customer trust.

"Code is abundant, but customer trust is scarce."

"The moment I show that feature to customers, they'll build something on it. If I'm not confident in it, I'll lose customer trust completely."

8. The Next Competition Is Not a Race of Speed but a Race of Ambition

Claire calls the past 12–18 months a period of "speed." It was an era when PMs wrote PRs themselves, prototypes were everywhere, and teams showed things to customers and got feedback faster. This clearly mattered, and she acknowledges that teams gained real speed through AI.

But she says next year's strategy shouldn't be just another race for speed. Now we need to move to a race of ambition.

"The last 12–18 months were a real race for speed. But I don't think that's the strategy we should pursue next year."

"Next year is a race of ambition."

The ambition she means is the possibility of using AI to run, in two to three weeks, experiments that would previously have taken a year. Rather than using that possibility merely to speed up feature shipping, teams should invest it in experiments and projects that create much bigger, more fundamental change.

OKRs, too, should not measure AI transformation only through metrics like number of PRs, revenue per employee, or volume of features shipped. She suggests organizations ask how many bold experiments they run each month — on the premise that most of them will fail.

"I want to ask how many huge experiments you run every month."

"On the premise that most of them won't succeed, how many bold attempts are you making?"

The core of the new roadmap is not committing to detailed features in tight detail but combining big ambition with flexibility in the details.

9. A Call to Write the Last Roadmap

Claire's final request is to "write your last roadmap." This doesn't mean stop planning. It means stop the kind of roadmap where you line up ideas and features in a spreadsheet, estimate expected impact, pin down dates, and then promise not to change anything.

Instead, teams should define more boldly what success will look like in one to two years. That process requires accepting estimation and uncertainty, and staying open to the system telling you unexpected things.

"Stop the spreadsheets with feature lists and dates. The approach of estimating impact, setting dates, and agreeing never to change them is over."

"Strengthen your conviction and your ambition. Create great ideas, and define what success looks like one to two years from now."

In the AI era, you may write a lot of code and then throw it away. But that isn't waste; it can be a normal cost of not dumping low-quality products on customers. AI might suggest better ideas than your team, and the future of your product might turn out better than you imagine now. So what matters is not restraining AI but applying a very high bar to what AI produces.

"You're going to write a lot of code and throw it away. That's okay. Customers don't need crappy products."

"Your AI might come up with better ideas than your team. That's okay. We need good ideas."

"It's okay if you can't promise your team or your customers what next year will look like. It'll probably be better than you imagine right now."

Closing

Claire Vo's core message is that product leadership in the AI era depends less on the ability to build more and more on the ability to judge what to believe, how to validate it, and how far to commit to customers. A roadmap should be not a list of features and schedules but a container for the team's big convictions and ambitions, the evidence that would refute or strengthen them, and responsibility for customer trust. In the end, the best product organizations are not the ones that ship the most features, but the ones that learn from reality and boldly concentrate on their most important bets.