最后一份路线图：当 AI 让执行过剩、信念成为稀缺品 | Claire Vo

Brief Description

Fresh off declaring "product management is dead" at last year's summit, Claire Vo returns to go after a bigger target: the roadmap itself. Drawing on two decades in product and her own experience running an AI-powered "factory" that ships more than ever, she argues that execution capacity has become abundant while conviction has become scarce — inverting the engineering scarcity that roadmaps were built for. She warns of three traps (backlog, parity, and churn), introduces the idea of roadmap zero, and lays out what should replace the feature-and-date roadmap: durable convictions, disposable features, clearly labeled probes, experiments, and promises, and a shift from the velocity game to the ambition game.

Table of Contents

• Opening: This Year I'm Coming for the Roadmap
• A Confession: Out of Good Ideas
• When Engineering Capacity Was the Scarce Resource
• The Product Graph That Belonged in the Trash
• The AI Factory That Ran Itself
• Roadmap Zero and the Three Traps
• What Replaces the Roadmap: Convictions, Evidence, Factory, Allocation
• Durable Convictions, Disposable Features
• Probes, Experiments, and Promises
• The Ambition Game, Not the Velocity Game
• The Ask: Build Your Last Roadmap

Opening: This Year I'm Coming for the Roadmap

Good morning, everybody. Somebody texted me calling last night's party "the How I AI sauna" — I was out way past my bedtime, which is 8:15, because I've got a little baby. But I am here prepared to do the thing that I do.

Last year I came here and I said product management is dead. I said that because, as a product leader, I like to make big grand statements and then be proved completely wrong in the market — it keeps me really honest. Product management is obviously not dead; there are so many amazing product leaders, product managers, and product executives in this room. But who's with me that between the last Lenny's Summit and now, product management is completely different? It's really different.

So last year I came for the PMs that didn't work. Let's do it again: this year I'm coming for the roadmap. OKRs are next, and then my job is over.

The roadmap has been the defining artifact of our industry and of our careers. It's supposed to tell us and our teams where we're going, what's next, and what matters. I've been in product for over two decades, and I believe — fingers crossed — that a lot of us in this room are about to write our last roadmap.

A Confession: Out of Good Ideas

Before I go into why I think that, I have a confession. I am shipping more than ever. I have access to the most intelligent coding agents in the world, the best developer tools anybody can ask for, super smart models, and customer context via API, via CLI, via MCP — all the letters. I write so many skills; I counted yesterday, and I have 40 Grok bots. I can build almost anything.

And here is my true confession: I am out of good ideas. I'm straight up out of good ideas of things to build. It's not that I don't have plausible requests or things I could build — it's just that execution has outrun my ability to discover meaningful, meaty, commercializable products in the market. That's a very different situation than I've been in before.

This is a bigger problem than any of us are willing to admit. I'm the biggest token maxer on the planet — PRs up 3x, ship ship ship, agents everywhere, I don't need a PM, I don't need any specs. But the gap between our building capacity and our heart-of-hearts conviction — does any of this code matter? — is enormous. We're all getting pressure from the board, the timeline, each other, our teams, and our bosses to move faster, get leverage with AI, lean in, and show we're AI-native: Claire said product management is dead, she showed all those scary circles, she said ship to the moon — do it, do it, do it.

Here's the question I keep asking: who's shipping more than ever at their companies in the last year — and whose revenue is going up proportionate with the amount of PRs? That's the fundamental problem we're facing.

When Engineering Capacity Was the Scarce Resource

It used to be that engineering capacity was the scarce resource — honestly, that's kind of why we exist. We had way more ideas than people, and way more demand than ability to deliver against that demand. The product manager's and product leader's job was to prioritize all those ideas and sequence them, then spend all our time in meetings, in Slack, and in spreadsheets saying no. PMs should say no more. We had cut lines — "here's my cut line for the quarter, this is my priority list, this is my stack rank."

While the PM's job was to say no, engineering's job was to say "no, not like that" — not with all those features, not with perfect architecture, we can only do this much. And design's job was to say "no, wait for us, please." Everybody was constrained on this precious engineering capacity, so things got narrowed and narrowed until you only shipped a little bit of your roadmap.

Now I feel like I have more execution capacity than true conviction about what to build. My bottleneck has moved from "what can I build" to "what do I believe is actually worth building."

The Product Graph That Belonged in the Trash

So let me tell a story to bring this home. I had an idea for a thing called the Product Graph for ChatPRD. It's a real product idea for product managers, and it's not special because everybody's done it: we're going to suck in everything a company knows about customers and what you're working on, parse it, slap Opus on it, and make it all available through agents. It's going to be awesome — it'll help you make better decisions, build better products, and of course write better PRDs.

And so I built it. I built this insights engine and this very fancy semantic product graph that generates an auto-wiki that agents can consume. It was almost a one-shot — not quite, but pretty close. It worked, it looked good, it was feature-for-feature matching competitors in the market. And every time I would build it, I would think: this just belongs in the trash. All this work, all this amazing product, belongs in the trash.

Why? Because to me it was competitive but it wasn't differentiated. Even though it obviously had a market, people would probably want it, and customers said it was interesting — in my core, I felt it wasn't worth my customers' attention. The ROI was really shaky. I wasn't convinced on the interface: it still had a web interface, and I wondered, should it be agent-first? Is this the right thing? I wanted to build something surprising, something competitors couldn't even imagine.

My big problem was that those tokens and that roadmap executed my bet, but they didn't test, validate, or strengthen my conviction. Meanwhile, I'm sitting on all this code to nowhere.

The AI Factory That Ran Itself

I kept shipping more than ever. Customer fixes were automated — they'd come in, go to one of my bots, and get fixed. My goals were obliterating tech debt; I rearchitected ChatPRD 70 times because I could. We stopped tracking issues — "we don't need issue tracking anymore, we're just going to ship PRs." This AI factory manifested and started running itself. It did the thing we all want it to do. It's magical.

And here's the secret: I'm not sure any of it mattered. I'm not yet convinced that any of that mattered.

That really got me thinking. What is product management? What is the purpose of building software? How do we make decisions, prioritize, and allocate all these tokens? And I kept going back to the roadmap. Roadmaps made sense under engineering scarcity. They laid out your strategy and told you which features you were going to build. We had this thing called effort, which meant more than voice-noting Devon saying "can you please build this." We thought a lot about sequencing, milestones, and MVPs. And scarcity — theoretically, let's be honest — helped us filter out our bad ideas, because the bottom of the list just never shipped. It never could: there weren't enough engineers and there wasn't enough conviction across the organization. Below the cut line — that's what we called it — never shipped.

And now we can ship all our bad ideas. Congratulations to us. Cheap execution still needs judgment.

Roadmap Zero and the Three Traps

The roadmap plus limitless — or feeling-limitless — execution capacity is creating three traps I want to warn you about.

The backlog trap. If you have a backlog, AI will build it. They will build every single thing on your list. I hear a lot of "we've burned through our backlog" — of course you have, because all it takes is a prompt to build the backlog and it gets done. The problem is that clearing out requests or ideas does not mean meaningful progress against your business, or even meaningful progress against a customer problem.

The parity trap. This is something I really felt in the product graph story. All your competitors are copying each other, talking to the same customers, sucking in the same insights, and arriving at the same obvious conclusion — building the same obvious product with the same obvious polish. Run the taste skill, run impeccable, make it look good, get rid of the em-dashes, get rid of the borders. We're all doing the exact same thing. We used to have a really interesting dynamic with competitors; now it feels like it's evening out. What moats and differentiators even are is a big open question in my mind.

The churn trap. We ship something, we see noise and pick it up or not — because we can always ship something else — we abandon it, and we never really learn or compound on top of what we're shipping.

From the inside, all of this feels very productive: my backlog is going down, my competitive features are going up, we're shipping more than ever. But what it actually does is accelerate our path to mid.

This brings me to something I'm really observing, which I call roadmap zero. I don't mean you've run out of roadmap — although some people truly have roadmap zero, nothing on the roadmap anymore. I mean that every visible feature becomes both plausible and buildable. You don't have an empty backlog; it's just that everything on your backlog, you can kind of do. And when everything on your backlog is buildable, what is the point of the backlog? Buildability and effort stop being meaningful proxies for what matters, and prioritization — the reason PMs exist as we've practiced it — stops being strategy. We've been doing RICE prioritizations, but when many of those letters mean nothing anymore, especially effort, why are we still pretending prioritization is the right way to think about our products?

This is why I think roadmaps are over. They're dead — because they're really dangerous right now. An AI factory plus an old roadmap will get you to those three traps at machine speed, because the factory cannot distinguish a truly consequential bet from an idea. AI will make the consequences of weak judgment show up at your front door faster. Your bad ideas will become your problems quicker than ever.

What Replaces the Roadmap: Convictions, Evidence, Factory, Allocation

I think the right thing is to ask yourself: what do I believe strongly enough to go out and try and prove? Because the remaining constraint is not code. It's not building. It's not features. It is truth — on-the-ground, with-your-customers truth. AI cannot take an untested assumption into fact, no matter how many adversarial reviews you do — and I know you're doing them. You need real customers, real data, and repeated tests. And then you need a very unique point of view and a very high quality bar.

What AI allows us to do is make faster contact with reality, which is great — we all want that. But it means you have a higher obligation to actually encounter reality. You have to get into the market and accept what it's telling you. This is going to feel really retro to people like me who are a little older, because we've been saying "outcomes over outputs" forever — and yet our central artifact, the roadmap, still lists features and dates. Engineering scarcity once made that workable. Roadmap zero makes those features and dates very dangerous, for the reasons I outlined: that feature list becomes ammunition for a very powerful slop cannon.

So we need to move upstream from what we need to build to what we actually need to prove. Here's how I'd think about what we do instead of a roadmap.

First, build your convictions. What is the direction we want to go, and what do we believe the future looks like — not in three, six, or nine months, but in a year, in two years? Where do we think all of this is going?

Second, determine what evidence would show that your conviction is true, and define it upfront. What would I need to see to prove I'm doing the right thing? And what would I need to see to stop?

Third, you do need a factory. I love the factory — I'm saying it's dangerous, but I love dangerous things. You need the ability to build quickly and intersect reality very, very fast. I'm not saying get rid of it; I'm saying put it at the right place in the process.

And then you allocate. Go through that cycle, and when you get into reality, allocate your investment, your conviction, your effort, your tokens in the right direction.

Durable Convictions, Disposable Features

The most interesting thing about this new world we're moving into: you need durable convictions but disposable features. I was talking to Mara, who's going to come on stage later, and she said, "But Claire, enterprises love feature roadmaps." I'm going to talk to some folks at the end of the day who have changed a lot of features and products on us, and we as consumers — at least some of us — have accepted that level of churn. I think we're going to get to a place where customers and teams can shift the question to: do I bet on these convictions? Do I bet on this team, this space, this vision? And I understand features need to come and go — they might be unique to me, unique to a market.

What you want to see is clear progress against your convictions and zero ego about your solutions. You have to be stubborn about the durable convictions — but there's good stubborn and bad stubborn. Good stubborn is staying with the problem and revising the solution; holding true to what's going to happen even if the flavor of the week is trending. Bad stubborn is, because you have tokens, just moving the goalposts: "ah, we're close, we'll just ship again and ship again and ship again." I want you to think about: what are my durable convictions? Am I being good stubborn or bad stubborn? And how do you build into your system the ability to absorb disposable features while keeping rigor around quality and learning?

Probes, Experiments, and Promises

This is really scary, especially when it hits customers. But I think we're moving to a place where not everything we ship is a promise. Has anybody shipped something and thought: this is a hypothesis, this is truly an experiment — I might get it wrong, the market might move underneath me, or the technology might change tremendously? Not every ship is a promise.

We used to do these roadmaps where I'd go hand-on-heart to go-to-market and say: I swear, on my children, this feature will ship with these specific things on this specific date. You could sell it in the contract and make these promises. Now I think we really have to rethink how we communicate internally and with customers. There's going to be a spectrum: a probe — kind of a bet, we're going to explore a little bit. A more durable experiment against your conviction — this is something we really believe in, and we're going to stick with it till we get it right. And then promises: I have shipped something, customers can rely on it, they can build their customers on it, we really believe, and we'll keep compounding here.

You need to be honest about what your commitment is on any feature. That's almost the most helpful lens on the new roadmap: how strong is our conviction here, and how durable is this promise — versus how hard is it to build and what's our estimated impact.

And while we do this, remember: code is abundant; customer trust is not. Going back to that product graph — the feature I built over and over until I felt conviction — it was feature-flagged off, because I knew that as soon as I put it in front of a customer, they were going to build on it and use it. If I didn't have conviction that it was right, I was really going to burn that customer trust. That's something I thought about really deeply as I rolled it out.

The Ambition Game, Not the Velocity Game

So I do still think you need a roadmap — but it needs to be more about ambition. It needs to be bigger. I don't want to see onesie-twosies on your roadmap. I want to see the future you believe should exist. I want to see what evidence shows we're making progress, what would prove us wrong, and what earns more time, tokens, and customer attention.

I want to go back to ambition because the last 12 to 18 months — the year of our Claude — we were shipping everything: PMs were writing PRs, prototypes everywhere. We were in a straight-up velocity game. If I can get prototypes to customers faster, they can give me feedback faster; if I can hand things to customers or engineering faster, they can do PRs faster; my agents will take care of tech debt; my agents will take care of features. We've been building up our muscle for true velocity.

I don't think that's the game next year. I don't think that's the game we should be playing next year. Next year is the ambition game. What huge swings can I make? What experiments can I run in two or three weeks that would have taken us a year last time? How do I build a roadmap of very, very large investments in very ambitious builds? Because I think that is more important than raw feature velocity — and the roadmap as it is doesn't serve that goal.

I was talking to somebody — and going back to OKRs, unfortunately not dead yet — and she asked, what should our OKRs be relative to our AI transformation? PRs? Revenue per headcount? My answer: how many huge experiments are you running a month? I don't care what the experiments are — I don't know what they should be. How many big swings are you taking a month, with the presumption that most of them won't work out? That is a very new way to think about how you build your roadmap and how you do product: big on the ambition, very fuzzy on the specifics.

The Ask: Build Your Last Roadmap

So here is my ask — slash gift — to you all: build your last roadmap. I do not mean build your last plan; of course not. I mean no more lists of ideas and features in spreadsheets where you guess impact, put a date on them, and then lock arms and say "we'll never change anything because this is how we work." That day is over.

Instead, truly raise your conviction and raise your ambition. Come up with big ideas and define what success looks like in a year or two. You're going to have to make some big guesses, because honestly I can't tell you what's going to happen in a week or two.

You really want to get to a place where you have a factory that can surprise you — where you're able to discard software and still hold that factory to a high bar. Look: you're going to write a lot of code and then trash it. Good — your customers do not need trash products. Your AI is going to have better ideas than your team. Good — we need good ideas, and you need to hold that AI to a very, very high bar. And you're not going to be able to promise your team or your customers what next year looks like. Good — because it's probably going to be better than you can imagine right now.

So this is my ask: write your last roadmap. I promise you, it is extremely fun on this other side. Enjoy the rest of your summit — I'll see you later this afternoon, and please come say hi.