Write Your Last Roadmap: Claire Vo on Building When Code Is Cheap

Claire Vo opens by recalling that at last year's summit she declared product management dead, a claim she says was proved wrong but which pointed at real change. This year she is coming for the roadmap. In her telling, it has been the defining artifact of her two-decade career, the thing meant to say where a team is going and what matters. She believes many people in the room are about to write their last one.

She then makes a confession. She has the most capable coding agents and developer tools, customer context available through APIs, CLIs and MCP, and plenty of skills and bots. She can build almost anything, and she says she has run out of good ideas about what to build. Execution, she says, has outrun her ability to discover meaningful, commercializable products.

Vo contrasts this with the past, when engineering capacity was the scarce resource and there were far more ideas and demand than people to deliver. Product managers existed to prioritize, sequence and say no, while engineering and design were constrained too. Her bottleneck has now moved from what she can build to what she believes is worth building. She describes herself as a heavy "token maxer" with PRs up threefold, yet she thinks the gap between building capacity and real conviction is a bigger problem than people admit, especially with boards and bosses pushing for speed.

To make the point concrete, Vo describes an idea for ChatPRD that she calls a product graph. It would pull in everything a company knows about its customers and its work, parse it with a frontier model and make it available to agents so teams could decide better. She built an insights engine and a semantic graph that generates an auto-wiki, in something close to a one-shot. It worked and looked good, and customers called it interesting.

But each time she built it, she felt it belonged in the trash. It matched competitors feature for feature and was not differentiated, the return on investment felt shaky, and she was unsure about the interface. She wanted something surprising that competitors could not imagine. The tokens and roadmap had executed her bet without testing, validating or strengthening her conviction.

Meanwhile the rest of the AI factory kept running. Customer fixes were automated, tech debt was attacked, and she says she re-architected ChatPRD 70 times because she could. They stopped tracking issues and just shipped PRs. She says she is still not convinced that any of it mattered, and that experience sent her back to the question of what the roadmap is for.

Vo says roadmaps made sense under engineering scarcity. They laid out strategy, sequencing, milestones and MVPs, and effort was a real input. Scarcity also filtered out bad ideas, because whatever fell below the cut line simply never shipped. With cheap execution, she says, we can now ship all our bad ideas, and judgment still has to come from somewhere.

The first trap is the backlog trap. If you have a backlog, AI will build all of it, and clearing requests does not mean progress against the business or a customer problem. The second is the parity trap. Competitors talk to the same customers, pull in the same insights, reach the same obvious conclusions and run the same design skills, so products converge and moats and differentiators get harder to find.

The third is the churn trap. A team ships something, sees noise, abandons it because it can always ship something else, and never learns or compounds on what it built. All three feel productive from the inside, with the backlog shrinking and competitive features growing. Vo says they accelerate the path to mid, and an AI factory with an old roadmap reaches them at machine speed. Its bad ideas become problems faster, she adds, because the factory cannot distinguish a consequential bet from any other idea.

Vo introduces "roadmap zero". She does not mean an empty backlog. She means that every visible feature becomes both plausible and buildable. When you can kind of do everything on the list, buildability and effort stop being a meaningful proxy for importance, and she questions why teams still pretend that RICE-style prioritization is the way to think about products.

The remaining constraint, she says, is truth, not code. AI cannot turn an untested assumption into fact however many adversarial reviews you run, so you need real customers, real data, repeated tests, a distinctive point of view and a high quality bar. AI lets teams make faster contact with reality, which raises the obligation to go into the market and accept what it says. She acknowledges this sounds retro, since people have long preached outcomes over outputs while the central artifact still lists features and dates.

Her alternative is to move upstream from what to build to what to prove. First, build convictions about where things will be in a year or two, not three, six or nine months. Next, define up front what evidence would show the conviction is true and what would make you stop. Then keep the factory but put it at the right point in the process, so you can intersect reality quickly and allocate investment, effort and tokens toward what the evidence supports.

Vo argues for durable convictions but disposable features. Teams should show clear progress against their convictions while having zero ego about their solutions. She notes that a colleague told her enterprises love feature roadmaps, but she believes customers increasingly accept feature churn and may bet on a team, space or vision instead. She distinguishes good stubbornness, which stays with the problem and revises the solution, from bad stubbornness, which keeps moving the goalposts because tokens are cheap.

This also changes what a shipment means. Not everything shipped is a promise, she says, so teams should be honest internally and with customers about commitment levels: a probe is a small exploratory bet, an experiment is a durable test of a conviction, and a promise is something customers can build on. The key lens becomes how strong the conviction is and how durable the commitment, rather than how hard something is to build. Her own product graph stayed feature-flagged off, because she knew customers would build on it and she did not want to burn their trust without conviction. Code is abundant, she says, but customer trust is not.

She still wants a roadmap, but one about ambition. She wants no "onesie twoosies", and instead wants the future the team believes should exist, the evidence of progress, what would prove it wrong and what earns more time, tokens and customer attention. The last 12 to 18 months were a velocity game, she says, and next year is the ambition game. That means big swings and experiments that take weeks rather than a year. She suggests that one OKR could be how many big experiments a team runs per month, assuming most will fail.

Vo closes with a request that the audience build their last roadmap. She stresses that she does not mean the last plan. She means no more spreadsheets of ideas and features with guessed impact and fixed dates, defended by teams that refuse to change anything because that is how they work. In her view that day is over.

Instead, teams should raise their conviction and ambition, come up with big ideas and define what success looks like in a year or two. That requires some big guesses, since nobody can honestly say what will happen in a week or two. The goal is a factory that can surprise you, and being willing to discard software while holding the factory to a high bar.

She accepts that teams will write a lot of code and then trash it, and says customers do not need trash products. She also expects AI to have better ideas than the team at times, and wants that AI held to a very high bar. Teams will not be able to promise what next year looks like, and she says that is fine because it may be better than anyone can imagine now.