Everyone’s shipping more. Does any of it matter? | Claire Vo
Description
AI has made it easier than ever to ship software, but how do you know what’s worth building? In her talk at the Lenny and Friends Summit, Claire Vo argues that traditional feature roadmaps can push teams to clear backlogs, copy competitors, and keep shipping without learning what matters. She makes the case for bigger ambitions, stronger convictions, and experiments grounded in real customer evidence. Recorded live at Lenny and Friends Summit on September 10, 2026, in San Francisco.
Summary
Generated by gpt-5.6-terraAt-a-Glance
- Verdict: Watch fully
- Core thesis: As AI makes implementation cheap and fast, feature roadmaps become a dangerous mechanism for scaling weak judgment; product teams should organize around durable convictions, explicit evidence thresholds, ambitious experiments, and calibrated customer promises instead.
- Why it matters: For AI-native products and agent systems, the limiting factor is rapidly shifting from engineering throughput to differentiated insight, reliable learning loops, and customer trust—areas that cannot be automated merely by generating more code or PRs.
- Best use: Use this as a strategic prompt to redesign planning, experiment governance, and feature-commitment practices around an AI-accelerated product factory.
Executive Summary
Claire Vo argues that product management is not dead, but its defining artifact—the feature-and-date roadmap—was built for an era when engineering capacity was scarce. AI coding agents reverse that constraint: teams can now build almost every plausible request, backlog item, prototype, fix, and architectural rewrite. The new bottleneck is not whether a team can build something, but whether it has sufficient conviction that the thing is worth a customer's attention.
Her central warning is that pairing an AI “factory” with a conventional roadmap produces three failure modes at machine speed. Teams can clear their backlogs without solving consequential customer or business problems; converge on competitive parity because everyone uses similar models, inputs, and design patterns; and churn through features before learning compounds. High visible output can therefore accelerate a company toward mediocrity rather than differentiation.
Vo proposes replacing feature prioritization with a conviction-and-evidence system. Teams should articulate a long-horizon view of the future, define in advance what evidence would validate or disprove that view, use AI-enabled delivery to get into the market quickly, and reallocate time, tokens, and customer attention based on what reality reveals. The operating principle is durable convictions but disposable features: stay committed to an important problem or market belief while holding solutions loosely.
The practical governance change is to label feature work by commitment level: probes, durable experiments, and promises. This protects customer trust by making clear which releases are exploratory versus dependable foundations on which customers may build. Vo ultimately argues that the next competitive game is not raw velocity but ambition: how many large, potentially transformative experiments a company can run in weeks that formerly would have taken a year.
Key Takeaways
- Claim: AI has moved the product bottleneck from engineering capacity to conviction about what is commercially meaningful and differentiated. | Evidence: Vo says she has access to advanced coding agents, customer context through APIs/CLIs/MCP, and roughly 40 GrokBots; she can build almost anything but says she is “out of good ideas.” Her own semantic product graph/PRD product was built close to one-shot and reached feature parity with competitors, yet she felt its ROI and interface were unconvincing. | Implication: Ken should treat code generation and agent throughput as an instrument for testing high-conviction bets, not as proof that a growing feature pipeline is producing value. | Caveat: This is a strategic diagnosis rather than evidence that engineering constraints have disappeared in every organization; regulated, legacy, infrastructure-heavy, and enterprise environments may still face substantial delivery constraints.
- Claim: Traditional roadmaps become actively dangerous when an AI factory can execute nearly every item on them. | Evidence: Vo defines “roadmap zero” as the state where every visible feature is plausible and buildable—not an empty backlog. In that state, effort is no longer a useful filter, so conventional prioritization methods such as RICE lose a major input. She calls a feature list “ammunition for a very powerful slab cannon.” | Implication: Replace backlog burn-down as a planning success metric with an explicit mechanism for deciding which beliefs deserve rapid tests, further investment, or termination. | Caveat: She is not arguing for no planning; she explicitly retains a roadmap-like artifact, but one centered on ambition, conviction, evidence, and allocation rather than fixed features and dates.
- Claim: AI-accelerated feature production creates three predictable traps: backlog completion, competitive parity, and learning-free churn. | Evidence: The backlog trap is building every request simply because it exists; the parity trap is competitors consuming similar customer signals and using similar agent/design recipes to reach the same obvious products; the churn trap is abandoning a newly shipped feature at the first noise because another one can always be built. Vo argues these internally feel productive—backlog down, feature count up—but speed the path to “mediocrity.” | Implication: Any AI product factory needs portfolio-level checks for customer-problem progress, defensible differentiation, and accumulated learning—not merely automated intake-to-PR flow.
- Claim: The correct replacement for feature-first planning is a conviction loop: state a directional belief, predefine validation and stopping evidence, build rapidly, observe reality, and reallocate resources. | Evidence: Vo’s proposed sequence is to build convictions about the one- to two-year future, define what would prove the conviction true and what would require stopping, maintain a fast delivery factory to intersect reality, and then allocate investment, effort, tokens, and customer attention according to the results. She emphasizes that AI cannot convert an untested assumption into fact, even with adversarial reviews. | Implication: For agent initiatives, specify falsifiable customer and business evidence before implementation, including kill criteria, rather than retrospectively justifying work once agents have made it cheap to ship. | Caveat: The framework requires repeated real-customer tests and real data; internal model critiques, prototypes, or synthetic evaluations do not substitute for market contact.
- Claim: Teams should maintain durable convictions while treating individual features as disposable hypotheses. | Evidence: Vo distinguishes “good stubborn” from “bad stubborn.” Good stubbornness stays with the underlying problem and revises the solution despite short-term trends; bad stubbornness repeatedly ships more because tokens are available and continually moves the goalposts. Her product graph remained feature-flagged because she lacked conviction it deserved customer attention. | Implication: Ken should separate the stable strategic thesis for a product or agent platform from the mutable workflows, UX, model choices, and capability surfaces used to test it. | Caveat: Disposable features do not mean disposable quality or irresponsible instability: teams must preserve rigor in learning and clearly communicate what customers can rely on.
- Claim: Feature releases should carry explicit promise levels because code is abundant but customer trust is not. | Evidence: Vo proposes three categories: a probe, which is a small exploratory bet; a durable experiment, which the team believes in and will iterate until it works; and a promise, which customers can depend on and build upon. She contrasts this with the old roadmap practice of making contract-level commitments to precise features and dates. | Implication: Create a release-contract taxonomy for customer-facing AI capabilities, with different support, reliability, deprecation, and sales-commitment rules for experiments versus committed platform surfaces. | Caveat: Enterprise buyers may still demand explicit roadmap commitments, so the model requires disciplined commercial communication rather than unilateral feature churn.
- Claim: The strategic AI metric should shift from feature velocity or PR counts toward the rate of ambitious, consequential experiments. | Evidence: Vo rejects PRs and revenue-per-headcount as the primary answer to AI-transformation OKRs, suggesting instead the question: how many huge experiments can the company run each month, assuming most will fail? Her test is whether two- to three-week experiments can now pursue swings that previously took a year. | Implication: Measure the organization’s ability to run and decisively resolve high-upside bets, including how quickly it learns, stops, doubles down, or turns an experiment into a customer promise. | Caveat: Experiment count alone can become another vanity metric unless each experiment is tied to a defined conviction, decision threshold, and customer-learning outcome.
Detailed Brief
Why the old roadmap worked—and why its old filter no longer protects teams
- Claims: Under engineering scarcity, the roadmap served as both a strategy artifact and a rationing mechanism: prioritization, sequencing, milestones, MVP scope, and “below the cut line” determined what could receive scarce implementation capacity.; Scarcity imperfectly filtered bad ideas because many ideas simply could not be built. AI removes that accidental quality filter, exposing organizations that mistake feasibility for importance.; Vo's critique is not anti-factory: she celebrates automated customer fixes, agent-driven technical-debt removal, and extremely fast rearchitecture. Her point is that the factory must occupy the execution stage after judgment, not determine what gets attention.
- Evidence: She describes customer fixes routing to a bot, stopping issue tracking in favor of shipping PRs, and rearchitecting her product “70 times” because AI made it easy.; Her product-graph example illustrates that market existence and competitive feature matching are insufficient standards; customers calling it interesting did not resolve her doubts about ROI, interaction model, or differentiation.
- Caveats: Fast execution can still be valuable for maintenance, reliability, and customer fixes even when it is not a source of strategic differentiation.; The talk gives an operating philosophy, not a detailed portfolio-scoring formula for selecting convictions.
- Implications: A planning system should distinguish operational throughput work from strategic bets so that automated maintenance velocity does not distort evidence of product progress.; The organization needs a higher quality bar for what enters the AI factory, because a weak request is no longer naturally constrained by implementation effort.
A roadmap redesigned around ambition and customer reality
- Claims: Vo still wants a roadmap, but one that describes the future the team believes should exist, the evidence of progress, the evidence that would disprove the thesis, and the conditions that earn additional resources.; The future-facing horizon should be roughly one to two years, even though exact near-term features are uncertain. The team should make large directional guesses while avoiding false precision about dates and solution details.; The desired organizational capability is a factory that can surprise its operators: it should generate and test possibilities fast enough that plans can improve beyond what leaders can presently specify.
- Evidence: Vo rejects “onesie twosies” on the roadmap and asks for large investments in ambitious builds rather than spreadsheets of individually estimated features.; She says teams will write substantial amounts of code and discard it, which is acceptable because customers do not need discarded, low-conviction products.
- Caveats: Ambition must be paired with explicit evidence standards; otherwise large experiments can become undisciplined spending or a license to perpetually shift goals.; Customers and internal go-to-market teams need clarity about whether a capability is exploratory, durable, or contractually dependable.
- Implications: Planning reviews should focus on thesis quality, proof/disproof conditions, resource allocation, and trust exposure rather than feature completion against a calendar.; Sales, success, product, and engineering need a shared vocabulary for communicating changing capabilities without overstating roadmap certainty.
Notable Concepts & Terms
- Roadmap zero: The condition in which virtually every visible feature request is feasible to build, making feasibility, effort estimates, and conventional backlog prioritization poor proxies for strategic importance.
- AI factory: An agent-enabled delivery system that can generate code, automate fixes, address technical debt, and ship rapidly; powerful but unable on its own to distinguish consequential bets from weak ideas.
- Backlog trap: Treating automated completion of requests and backlog items as meaningful progress even when it does not solve an important customer or business problem.
- Parity trap: AI-enabled teams converge on the same obvious products because they use similar customer inputs, models, competitors, and product-design patterns, weakening differentiation.
- Churn trap: Rapidly replacing features before learning compounds, because low implementation cost makes it easy to abandon a release and ship another one.
- Durable convictions, disposable features: Retain commitment to the underlying customer problem and directional thesis while remaining willing to replace interfaces, workflows, and implementations.
- Good stubborn vs. bad stubborn: Good stubbornness persists on the problem while revising the solution; bad stubbornness repeatedly ships in order to avoid admitting that the original thesis is failing.
- Probe / durable experiment / promise: A feature-commitment taxonomy: exploratory work, work the team intends to iterate toward success, and reliable capabilities customers can safely build on.
Operator Notes / Why Ken Should Care
- Institute a pre-build decision memo for material AI/agent initiatives: state the durable conviction, target customer reality, validation evidence, disconfirming evidence, and resource cap before the factory begins implementation.
- Add a release classification to all customer-facing capabilities—probe, durable experiment, or promise—with defined rules for access, support, reliability, sales language, deprecation, and customer notification.
- Audit the current roadmap and backlog for items whose only rationale is feasibility, competitor parity, or accumulated requests; explicitly decide whether each belongs in a learning experiment, an operational queue, or the trash.
- Replace PR count and backlog burn-down in AI-transformation reporting with a portfolio dashboard of high-ambition experiments, evidence produced, decisions made, and customer-trust exposure.
- Require every strategic experiment to have a named customer-contact plan and a stop condition; do not accept internal agent evaluation or prototype quality as sufficient market validation.
- Protect committed customer surfaces from agent-driven churn by feature-flagging low-conviction capabilities and preventing exploratory functionality from being sold as a roadmap promise.
Source/Metadata
- Title: Everyone’s shipping more. Does any of it matter? | Claire Vo
- Transcript words: 7313
- Duration seconds: 1437
- Timestamp note: No timestamps or chapters were provided. The supplied transcript contains substantial duplicated material in its latter portion.
Transcript
Good morning, everyone. How's it going? Everybody excited to be here? Okay, for those of you that were in the, somebody texted me, they called it the How I AI sauna last night, the party we had. I told you all you need to hype me up this morning because I was out way past my bedtime, which is 8:15. I've got a little baby. But I am here prepared to do the thing that I do. So last year, last year, I came here and I said product management is dead. I said that because as a product leader, I like to make these big grand statements and then be proved completely wrong in the market just keeps me really honest. So product management is obviously not dead. There are so many amazing product leaders, product managers, product executives here in this room. But who's with me that between the last time we had Lenny's summit and now, product management is completely different? Okay, got some hands. It's really different. And so last year, I came for PMs. That didn't work. Let's do it again. This year, I'm coming for the roadmap. Yeah, you're welcome. OKRs next, and then my job is over. So the roadmap has been the defining artifact of our industry, of our careers. It's supposed to tell us and our teams where we're going, what's next and what matters. And I have been in product for over two decades. And I believe, fingers crossed, a lot of us in this room are about to write our last roadmap. Before I go into why I think that I want to tell you all I have a confession. I am shipping more than ever. I have access to the most intelligent coding agents in the world. I have the best developer tools anybody could ask for. I have super smart models. I've got customer context via API, via CLI, via MCP, all the letters I have. I write so many skills. And y'all, I counted yesterday. I have 40 GrokBots. I can build almost anything. And here is my true, true confession. I am out of good ideas. Y'all. I'm straight up out of good ideas of things to build. I'm out. I can build. I just don't think any of it's a good idea. So I'm not saying I don't have plausible requests. It's not that I'm saying I don't have things I could build. It's just that execution has outrun my ability to discover meaningful, meaty, my favorite word, commercializable products in the market. And this is a very different situation than I have been in before. You know, it used to be that engineering capacity was the scarce resource. That's what we exist for, honestly. Engineering capacity used to be the really scarce resource. We had way more ideas than people. We had way more demand than our ability to deliver against that demand. And the product manager, the product leader's job was to prioritize all those ideas, sequence them, and then spend all our time in meetings, and in Slack, and in spreadsheets, saying no, saying no. PMs should say no more. We should have cut lines. It was very aggressive. Here's my cut line for the quarter. This is my priority list. This is my stack rank. And while the PM's job was to say no, it felt like 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 then it seemed like design's job was to say, "No, wait for us, please." And so everybody was constrained on this precious engineering capacity. And so things got narrow, narrow, narrow down till you only shipped a little bit of your roadmap. And now I feel like I have more execution capacity than true conviction about what to build. So my bottleneck has moved from "what can I build" to "what do I believe is actually worth building." And look, I am the biggest token maxer on the planet. I'm like PRs up 3x. Do it all. Ship. Ship. Ship. Agents everywhere. I don't need a PM. I don't need any specs. But I think this gap between our building capacity and true conviction—does any of this code matter—is a much bigger problem than any of us are willing to admit. I think we're all getting pressure from the board, from the timeline, from each other, from our teams, from our bosses to move faster, to get leverage with AI, to really lean in and show we're AI native, we can build in this new way. Claire said product management is dead. She showed all these scary circles. She said, "Ship to the moon. Do it, do it, do it." But I do think none of us are. I know this is a question I asked one: Who's shipping more than ever in the last year at their companies? Whose revenue is going up proportionate with the amount of PRs? That's the fundamental problem we're facing here. And so I'm going to tell a story and bring this home for you. I have no good ideas and I don't know if they matter. So I had this idea for this thing called the product graph for chat PRD. It's a real product manager idea and it's not special because everybody's done it. But we're going to suck in everything a company knows about customers, about what you're working on, blah blah blah. We're going to parse it. We're going to slap opus on it and then it's all going to be available through agents. And it's going to be awesome. It's going to make you be able to make these decisions better and build better products and of course write better PRDs. And so I built it. I built this insights engine. I built this very fancy semantic product graph. It generates this auto wiki. Agents can consume it. It was almost a one shot. Not quite, but it was a pretty close one shot. It worked. It looks pretty good. It was feature for feature matching competitors in the market. Every time I would build it, I would be like, this just belongs in the trash. It belongs in the trash. All this work, all this amazing product belongs in the trash. And why? Because to me it was competitive. It wasn't differentiated. And so, even though I had built this thing that obviously had a market, people would probably want it, customers said it was interesting. In my core, I felt like it wasn't worth my customers' attention. The ROI was really shaky to me. I wasn't convinced on the interface. I was like, should this? It still had a web interface. I was like, should it be agent first? Is this the right thing? I wanted to build something surprising that competitors couldn't even imagine. And my big problem was that these tokens and this roadmap that I had executed my bet, but it didn't really test or validate or strengthen my conviction. Meanwhile, I'm sitting on all this code to nowhere. I kept shipping more than ever. Customer fixes were automated. They would come in, they go to one of my bots and then they get fixed. Goals were obliterating tech debt. I re-architected chapter 70 times because I could. We stopped tracking issues. We're like, 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 that 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. And that really got me thinking. It got me thinking about what is product management? What is the purpose of building software? How do we make decisions? How do we prioritize? How do we allocate all these tokens? And I just kept going back to this idea of the roadmap. Roadmaps made sense under engineering scarcity. They laid out your strategy. They told you what features you were going to build. We had this thing called effort, which was more than just voice noting Devon saying, "Can you please build this?" And we thought a lot about sequencing and milestones and MVPs. And scarcity helped us theoretically—let's be honest—it helped us theoretically filter out our bad ideas. Because the bottom of the list just never shipped. It never could. There were not enough engineers. There was not enough conviction across the organization. So this below the cut line, that's what we called it, below the cut line, never shipped. And now we can ship all our bad ideas. Congratulations to us. Cheap execution, I think, still needs judgment. And I think we're seeing this moment where the roadmap plus limitless or feeling limitless execution capacity is creating three traps that I want to warn you about. The first is the backlog trap. So this is: if you have a backlog, AI will build it. They will build every single We thought a lot about sequencing and milestones and MVPs. And scarcity helped us theoretically, let's be honest. It helped us theoretically filter out our bad ideas. Because the bottom of the list just never shipped. It never could. There were not enough engineers. There was not enough conviction across the organization. So this below the cut, that's what we called it below the cut line, never shipped. And now we can ship all our bad ideas. Congratulations to us. Cheap execution, I think still needs judgment. And I think we're seeing this moment where the roadmap plus limitless or feeling like limitless execution capacity is creating three traps that I want to warn you about. The first is the backlog trap. So this is if you have a backlog, AI will build it. They will build every single thing. It will build every single thing on your list. And so I hear a lot about burning through our backlog. It's because all you have to do is slash goal, build, build the backlog, and it gets done. But the problem is clearing out requests or ideas does not mean meaningful progress against your business or even meaningful progress against a customer problem. The second thing is the parity trap. This is something I really felt in that story about the product graph. All your competitors are copying each other and they all are talking to the same customers and they're all sucking in the same insights and they're all arriving at the same obvious conclusion and building the same obvious product with the same obvious run the taste skill, run impeccable, run whatever, make it look good, get rid of the em dashes, get rid of the borders. We're all doing it. Can you tell I token maxed? We're all doing the exact same thing. And so this is the parity trap where we used to have this really interesting dynamic with competitors. Now it feels like it's evening out. And this question about what moats are and what differentiators are is a big one in my mind. And then the final trap I see is the churn trap, which is we ship something, we see noise and pickup or not. Because we can always ship something else, we abandon it. And then we never really learn or compound on top of what we're doing. And all of these things from the inside feel very productive. My backlog's going down, my competitive features are going up, we're shipping more than ever. But what I think this does is accelerate our path to mediocrity. And that's the thing I want to warn you about. And so this brings me to something that I'm really observing, which is this concept of roadmap zero. I don't mean we've gone through the roadmap, although some people truly have roadmap zeroed, nothing on the roadmap anymore. What I mean is that every visible feature becomes both plausible and buildable. You don't have an empty backlog. That's not what I'm talking about. It's just everything on your backlog you can do. And when everything on your backlog you can do, what is the point of the backlog? I think buildability and effort stop being a meaningful proxy for what matters. And prioritization, again, why PMs exist, as we've practiced it, I think stops being strategy. We've been doing these 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? And this is why I think roadmaps are over. They're dead. It's because I think they're really dangerous right now. I think an AI factory plus an old roadmap will get you to those three traps at machine speed. They will get you there fast. Because this factory really can't distinguish a truly consequential bet from an idea. And AI will make the consequences of this weak judgment show up at your front door faster. So your bad ideas will become your problems quicker than ever. And so I don't think the roadmap is the right thing. 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. It is on the ground with our 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. You need real customers. You need real data. You need repeated tests. And then you need a very unique point of view and a very high unique quality bar. And what AI allows us to do is make faster contact with reality, which is great. We all want to make faster contact with reality. But that means you have a higher obligation to encounter reality. In your minds, you have to both get into the market and accept what it is telling you. And this is going to feel really retro to people like me and those a little older, because we've been saying outcomes over outputs all the time. But yet this central artifact, the roadmap, still lists features and dates. And engineering scarcity made that workable. But I think roadmap zero makes those features and dates very dangerous for the reasons that I outlined. This feature list becomes ammunition for a very powerful slab cannon. And so what I think we need to do is move upstream from what we need to build to what we actually need to prove. And so here's how I think about what we do instead of a roadmap. First, we build our convictions. So what is the direction that we want to go? What do we believe the future looks like? Not in three months, six months, nine months, in a year, in two years, where do we think all of this is going? I do think you need to determine what evidence would show you that your conviction is true. And you need to define that upfront. What would I need to see to prove that I'm doing the right thing? And what would I need to see to stop? You do need a factory. So I do love the factory. I'm saying it's dangerous, but I love something dangerous. So you need your factory, you need the ability to build quickly to intersect reality very fast. So I'm not saying get rid of it. I'm saying put it at the right place in the process. And then you need to allocate. You need to go through that cycle. And when you get into reality, you need to allocate your investment, your conviction, your effort, your tokens in the right direction. And what's interesting, I think most about this new world we're about to move into is I think you need to have durable convictions, but disposable features. And I was talking to Mara, who's going to come on stage later. And she's like, but Claire, enterprises love feature roadmaps. And I'm going to talk to some folks at the end of the day who have changed a lot of features around on us, a lot of products around us. And we as consumers, at least some of us have accepted that level of churn. And so I think we're going to get into this place where customers and teams are able to shift to, do I bet on these convictions? Do I bet on this team? Do I bet on the space? Do I bet on this vision? And I understand features need to come and go. They might be unique to me. They might be unique to a market. And so what you want to see is clear progress against your convictions, but zero ego about your solutions. And what this would look like, I think there's two ways this could go. You have to be stubborn here with your durable convictions, but there's good stubborn and bad stubborn. Good stubborn is you stay with the problem. You revise the solution. You hold true what's going to happen, even if the flavor of the week is trending. Bad stubborn is because you have tokens, you just move the goalpost. You're like, we're close. We'll just ship again and ship again and ship again. And so I want you to think about what are my durable convictions? Am I being good stubborn? Am I being bad stubborn? And then how do you actually build into your system the ability to absorb disposable features and keep rigor around quality and learning? And 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. And I don't know, is anybody feeling, has anybody shipped something? Thank you, right in the middle. You ship things and you're like, this is a hypothesis. This is truly an experiment. And I might get it wrong, or the market might move underneath me or the technology might change tremendously. And so I do think we have to think about this idea of not every ship is a promise. And we used to do these roadmaps and I would go hand on heart to go to market and I'd be like, I swear on my children, this feature will ship with these specific things on this specific date. You can definitely sell it in the contract. I would make these promises. And now I think we have to really think how we communicate internally, how we communicate with customers. You ship things and you're saying this is a hypothesis. This is truly an experiment. And I might get it wrong, or the market might move underneath me or the technology might change tremendously. And so I do think we have to think about this idea of not every ship is a promise. And we used to do these roadmaps and I would go hand on heart to go to market and I'd say, I swear on my children, this feature will ship with these specific things on this specific date. You can definitely sell it in the contract. I would make these promises. And now I think we have to really think how we communicate internally, how we communicate with customers. And so I think there's going to be everything from a probe. This is a bet. We're going to explore a little bit to a more durable experiment against your conviction. I think this is something we really believe in. And we're going to stick with it till we get it right. And then there are promises. Promises are, 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. And I think you need to be honest about what your commitment is on any feature. I think that's almost the most helpful lens on the new roadmap is how strong is our conviction here? And how durable is this promise versus how hard is it to build and what is our estimated impact? And while we do this, you need to remember code is abundant, customer trust is not. So going back to that product graph, that feature that I built over and over again, and over and over again, until I felt conviction, it was feature flagged off because I just knew that as soon as I put this in front of a customer, they were going to build on it, they were going to use it. And if I didn't have conviction that it was right, I was really going to burn that customer trust. And that's something I thought about deeply as I was rolling out this feature. So I do still think you need a roadmap, but I think that roadmap needs to be more about ambition. I think 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 that we're making progress, what would prove us wrong, and then what earns more time tokens and customer attention. And I want to go back to ambition because I think in the last 12 to 18 months, it was the year of our cloud, and we were shipping everything and PMs were writing PRs and it was prototypes everywhere. I really think we're in a velocity game. We're in an inflect PRs, 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 to engineering faster, they can do PRs faster. My agents will take care of tech debt. My agents will take care of features. I think in the last 12 to 18 months, we've been building up our muscle for true inflected velocity. I don't think that's the game next year. I don't think that's the game we should be playing for next year. I think next year is the ambition game. I think you should think like what huge swings can I make? What experiments can I run in two weeks, three weeks, that would have taken us a year last time? And how do I build this roadmap of very large investments in very ambitious builds? Because I think that is more important than raw feature velocity. And I don't think the roadmap as it is serves that goal. I was talking to somebody, and going back to OKRs, unfortunately, not dead yet. And she was like, what should our OKRs be relative to our AI transformation? Like PRs, revenue per headcount, what it should be? I'd be like, 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? And I think that is a very new way to think about how you build your roadmap and a very new way to think about how you do your product. Again, it's big on the ambition and very fuzzy on the specifics. So here is my ask and gift to you all. Build your last roadmap. And I do not mean build your last plan. Of course not. I just mean no more lists of ideas and features in spreadsheets where you guess impact and where you put a date on them, and then lock arms and say, we'll never change anything because this is how we work. I just think that day is over. Instead, what I want you to do is truly raise your conviction, raise your ambition, come up with big ideas, define what success looks like in a year or two. You're going to have to make some big guesses because I can't honestly tell what's going to happen in a week or two. I really think you want to get to a place where you have a factory that can surprise you. And so you really want to be able to discard software and then hold your factory to a high bar. And you're going to write a lot of code and then you're going to 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 high bar. And you're not going to be able to promise your team, 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 to you. Write your last roadmap. I promise you it's extremely fun on this other side. Enjoy the rest of your summit. I will see you later this afternoon and please come say hi. was like almost a one shot. Not quite, but it was a pretty close one shot. It worked. It looks pretty good. It was like feature for feature matching competitors in the market. I kind of just like every time I would build it, I would be like this just belongs in the trash. It belongs in the trash. All this work, all this amazing product belongs in the trash. And why? Because to me it was competitive. It wasn't differentiated. And so, you know, even though I had built this thing that like obviously had a market, people would probably want it. Customers said it was interesting. Like in my core, I felt like it wasn't worth my customers attention. I like the ROI was really shaky to me. I wasn't convinced on the interface. I was like, should this? It still had a web interface. I was like, should it be agent first? Is this the right thing? I wanted to build something surprising that competitors couldn't even imagine. And my big problem was that these tokens and this like roadmap that I had executed my bet, but it didn't really test or validate or strengthen my conviction. Meanwhile, I'm sitting on all this kind of like code to nowhere. I kept shipping more than ever. So customer fixes were like automated. They would come in, they go to like one of my bots and then they get fixed. Goals were like obliterating tech debt. I mean, I re architect, I re architected chapter 70 times because I could. We stopped tracking issues. We're like, we don't need issue tracking anymore. We're just going to ship PRs. This AI factory like manifested and started running itself. It did the thing that we all want it to do. It's magical. And here's the secret. I'm not sure any of it mattered. Like I'm not yet convinced that any of that mattered. And that really got me thinking. It got me thinking about what is product management? What is the purpose of building software? How do we make decisions? How do we prioritize? How do we allocate all these tokens? And I just kept going back to this idea of the roadmap. Roadmaps made sense under engineering scarcity. They like laid out your strategy. They told you what features were you going to build. We had this thing called effort, which was like more than me like voice noting, you know, Devon saying, can you please build this? And we we thought a lot about sequencing and milestones and MVPs. And scarcity helped us theoretically, let's be honest. It helped us theoretically filter out our bad ideas. Because the bottom of the list just never shipped. It never could. There were not enough engineers. There was not enough conviction across the organization. So this like below the cut, that's what we called it below the cut line, never shipped. And now we can ship all our bad ideas. Like congratulations to us. Cheap execution, I think still needs judgment. And I think we're seeing this moment where the roadmap plus like limitless or feeling like limitless execution capacity is creating three traps that I want to warn you about. The first is the backlog track. So this is if you have a backlog, AI will build it. They will build every single single thing. It will build every single thing on your list. And so I hear a lot about like, you know, I were burned through our backlog. It's because all you have to do is slash goal, build, build the backlog, and it gets done. But the problem is clearing out requests or ideas does not mean meaningful progress against your business or even meaningful progress against a customer problem. The second thing is the parody trap. This is something I really felt in that story about the product graph. All your competitors are copying each other and they all are talking to the same customers and they're all sucking in the same insights and they're all arriving at the same obvious conclusion and building the same obvious product with the same obvious like run the taste skill, run impeccable, run whatever, make it look good, get rid of the M dashes, get rid of the borders. Like we're all doing. Can you tell I token max? Yeah. So we're all doing the exact same thing. And so this is like parody trap where we used to have this like really interesting dynamic with competitors. Now it feels like it's evening out. And again, like this question about what moats are and what differentiators are is a big one in my mind. And then the final kind of trap I see is the churn trap, which is we ship something, we see noise and pick up or not. Because we can always ship something else, we abandon it. And then we never really learn or compound on top of what we're doing. And so all of these things from the inside feel very productive. Like my backlogs going down, my competitive features are going up, like we're shipping more than ever. But what I think this does is it just like accelerates our path to mid. And that's the thing I want to warn you about. And so this brings me to something that I'm really observing, which is this concept of roadmap zero. I don't mean like we've gone through the roadmap, although some people truly have roadmap zeroed, nothing on the roadmap anymore. What I mean is that every visible feature becomes both plausible and buildable. You don't have like an empty backlog. That's not what I'm talking about. It's just like everything on your backlog you can kind of do. And when everything on your backlog you can kind of do, what is the point of the backlog? I think buildability and effort stop being like this meaningful proxy for what matters. And prioritization, again, kind of like why PMs exist, as we've practiced it, I think stops being strategy, right? Like we've been doing these like rice prioritizations, but when like many of those letters mean nothing anymore, especially effort, like why are we still pretending like prioritization is the right way to think about our products? And this is why I think, you know, roadmaps are over, they're dead. It's because I think they're really dangerous right now. I think an AI factory plus an old roadmap will get you to those three traps at machine speed. They will get you there fast. Because this factory really can't distinguish a truly consequential bet from an idea. And AI will make the consequences of this weak judgment show up at your front door faster. So, your bad ideas will become your problems quicker than ever. And so, I don't think the roadmap is the right thing. 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. It is like on the ground with our 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. You need real customers. You need real data. You need repeated tests. And then you need a very unique point of view and a very high unique quality bar. And what AI allows us to do is make faster contact with reality, which is great. We all want to make faster contact with reality. But that means you have a higher obligation to encounter reality. In your minds, you have to both get into the market and accept what it is telling you. And this is going to feel really retro to people like, you know, me and they're a little older. Because we've been saying outcomes over outputs all the time. But yet this like central artifact, the roadmap, still lists features and dates. And again, engineering scarcity, one must be that workable. But like, I think roadmap zero makes those features and dates very dangerous for the reasons that I outlined. This feature list, I say becomes ammunition for a very powerful slob cannon. And so what I think we need to do is move upstream from what we need to build to what we actually need to prove. And so here's how I think about what we do instead of a roadmap. First, we build our convictions. So what is the direction that we want to go? What do we believe the future looks like? Not in three months, six months, nine months, in a year, in two years, where do we think all of this is going? I do think you need to determine what evidence would show you that your conviction is true. And you need to define that upfront. What would I need to see to prove that I'm doing the right thing? And what would I need to see to stop? You do need a factory. So I do love the factory. I'm saying it's dangerous, but I love something dangerous. So you need your factory, you need the ability to build quickly to intersect reality very, very fast. So I'm not saying get rid of it. I'm saying put it at the right place in the process. And then you need to allocate, you need to go through that cycle. And when you get into reality, you need to allocate your investment, your conviction, your effort, your tokens in the right direction. And what's interesting, I think most about this new world we're about to move into is I think you need to have durable convictions, but disposable features. And I was talking to Mara, who's going to come on the stage later. And she's like, but Claire, enterprises love feature roadmaps. And I'm going to talk to some folks at the end of the day who have changed a lot of features around on us, a lot of products around us. And we as consumers, at least some of us have accepted that level of churn. And so I think we're going to get into this place where customers, where teams are able to shift to, do I bet on these convictions? Do I bet on this team? Do I bet on the space? Do I bet on this vision? And I understand features need to come and go. They might be unique to me. They might be unique to a market. And so what you want to see is clear progress against your convictions, but zero ego about your solutions. And what this would look like, I think there's two ways this could go. You have to be stubborn here with your durable convictions, but there's good stubborn and bad stubborn. Good stubborn is you like stay with the problem. You revise the solution. You know, you hold true what's going to happen, even if the flavor of the week is trending. Bad stubborn is because you have tokens, you just move the goalpost. You're like, ah, we're close. We'll just ship again and ship again and ship again. And so I want you to think about what are my durable convictions? Am I being good stubborn? Am I being bad stubborn? And then how do you actually build into your system the ability to absorb disposable features and keeping rigor around quality and learning? And 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. And I don't know, is anybody feeling, ah, come on, like, has anybody shipped something? Thank you, right in the middle. Like, you ship things and you're like, this is a hypothesis. This is like truly an experiment. And I might get it wrong, or the market might move underneath me or the technology might change, you know, tremendously. And so I do think we have to think about this idea of like, not every ship is a promise. And we used to do these roadmaps and I would like go hand on heart to go to market and I'd be like, I swear on my children, this feature will ship with these specific things on this specific date. Like, you can definitely sell it in the contract. Like, you know, I would make these promises. And now I think we have to really think how we communicate internally, how we communicate with customers. And so I think there's going to be everything from a probe. This is like kind of a bet. We're going to explore a little bit to a more durable kind of experiment against your conviction. I think this is something we really believe in. And we're going to stick with it till we get it right. And then there are promises. Promises are, 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. And I think you need to be honest about what your commitment is on any feature. I think that's almost the most helpful lens on the new roadmap is like how strong is our conviction here? And how durable is this promise versus like how hard is it to build and what is our estimated impact? And while we do this, you know, again, you need to remember code is abundant, customer trust is not. So going back to that product graph, that feature that I built over and over again, and over and over again, until I felt conviction, it was feature flagged off because I just knew that as soon as I put this in front of a customer, they were going to build on it, they were going to use it. And if I didn't have conviction that it was right, I was really going to burn that customer trust. And that's something I thought about really deeply as I was rolling out this feature. So I do still think you need a roadmap, but I think that roadmap needs to be more about ambition. I think 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 that we're making progress, what would prove us wrong, and then what earns more time tokens and customer attention. And I want to go back to ambition because I think the last 12 to 18 months, as you know, it was like, you know, the year of our cloud, and we were shipping everything and PMs were writing PRs and it was prototypes everywhere. I really think we're in a velocity game. We're in a inflect PRs, 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 to engineering faster, they can do PRs faster. My agents will take care of tech debt. My agents will take care of features. I think we're really in the last 12 to 18 months, building up our muscle for true inflected velocity. I don't think that's the game next year. I don't think that's the game we should be playing for next year. I think next year is the ambition game. I think you should think like what huge swings can I make? What experiments can I run in two weeks, three weeks, that would have taken us a year last time? And how do I build sort of this roadmap of very, very, very large investments in very, very ambitious builds? Because I think that is more important than raw feature velocity. And I don't think the roadmap as it is serves that goal. You know, I was talking to somebody, and again, going back to OKRs, unfortunately, not dead yet. And she was like, what should our OKRs be relative to our AI transformation? Like PRs, revenue per headcount, like what it should be? I'd be like, how many huge experiments are you running a month? Like, I don't care what the experiments are. I don't know what they should be. Like, how many big, big swings are you taking a month with the presumption that most of them won't work out? And I think that is just a very new way to think about how you build your roadmap and a very new way to think about how you do your product. Again, it's big on the ambition and very fuzzy on the specifics. So here is my ask slash gift to you all. Build your last roadmap. And I do not mean build your last plan. Of course not. I just mean like, no more lists of ideas and features in spreadsheets where you guess impact and where you like, put a date on them, and then lock arms and say, we'll never change anything because this is how we work. I just think that day is over. Instead, what I want you to do is truly raise your conviction, raise your ambition, come up with big ideas, define what success looks like in like a year or two. You're going to have to make some big guesses because I can't honestly tell what's going to happen in a week or two. I really think you want to get to a place where you have a factory that can surprise you. And so you really want to be able to discard software and then hold your factory to a high bar. And look, you're going to write a lot of code and then you're going to 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, 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 to you. Write your last roadmap. I promise you is extremely fun on this other side. Enjoy the rest of your summit. I will see you later this afternoon and please come say hi.