Claire Vo on Writing Your Last Roadmap
Lenny's Podcast
At Lenny and Friends Summit, Claire Vo, a product leader with more than two decades in the field and the builder of ChatPRD, followed up on last year's provocation. A year ago she told this audience that product management was dead. She now jokes that she likes to make grand statements and then be "proved completely wrong in the market." PM is clearly not dead, she said, but it has changed dramatically since the last summit. This year her target is the roadmap, "the defining artifact of our industry, of our careers." Her central question is what should guide teams once AI makes nearly anything buildable. Her answer is that the constraint is no longer code but conviction and evidence, and that the feature-and-date roadmap has become actively dangerous.
A confession: unlimited execution, no good ideas
Vo opened with what she called a confession. She is shipping more than ever. She has access to the most capable coding agents, the best developer tools, smart models, and customer context available "via API, via CLI, via MCP." She writes many skills and counted 40 bots running for her. She can build almost anything.
Her "true true confession" was that she is out of good ideas. She stressed that she does not lack plausible requests or things she could build. Her problem is that execution has outrun her ability to discover meaningful, "meaty," commercializable products. She has never been in this situation before.
She described the old world for contrast. Engineering capacity used to be the scarce resource, which she said is largely why product managers exist. Teams had far more ideas and demand than they could deliver. The PM's job was to prioritize, sequence, and spend most of their time in meetings, Slack, and spreadsheets saying no, drawing aggressive cut lines and stack ranks. In her caricature, engineering's job was to say "no, not like that," with fewer features and less perfect architecture, and design's job was to say "wait for us." Everyone was constrained by precious engineering capacity until only a sliver of the roadmap shipped.
Now, she said, she has more execution capacity than true conviction about what to build. Her bottleneck has moved from what she can build to what she believes is worth building. She described herself as "the biggest token maxer on the planet," with PRs up 3x, agents everywhere, no need for PMs or specs. Still, she argued that the gap between building capacity and heartfelt conviction that any of the code matters is a much bigger problem than people admit. Boards, timelines, bosses, and peers are all pushing teams to move faster and prove they are AI-native. She acknowledged that her own talk last year contributed to that pressure. She then posed the question she thinks matters: of everyone shipping more than ever, whose revenue is rising in proportion to their PR count?
The product graph that belonged "in the trash"
To make this concrete, she told the story of a feature she built for ChatPRD called the product graph. She admitted the idea was not special, since "everybody's done it." The plan was to ingest everything a company knows about its customers and its work, parse it, put Opus on it, and expose it through agents so teams could make better decisions, build better products, and write better PRDs.
She built it: an insights engine, a semantic product graph, an auto-generated wiki that agents could consume. She said it was nearly a one-shot build. It worked, looked good, and matched competitors feature for feature. Yet each time she rebuilt it, her reaction was that it "belongs in the trash."
Her reasoning was that it was competitive but not differentiated. There was clearly a market, customers said it was interesting, and people would probably want it. But she did not feel it was worth her customers' attention. The ROI seemed shaky. She was unsure about the interface. It still had a web UI, and she wondered whether it should be agent-first. She wanted to build something surprising that competitors couldn't imagine. Her key point was that spending tokens and executing the roadmap had carried out her bet without testing, validating, or strengthening her conviction.
The AI factory that ran itself
Meanwhile the rest of her operation kept shipping. Customer fixes were automated: issues arrived, went to one of her bots, and got fixed. Tech debt was being "obliterated." She said she rearchitected ChatPRD "70 times because I could." Her team stopped tracking issues and just shipped PRs. The AI factory, she said, "manifested and started running itself," doing exactly what everyone hopes for. "It's magical."
Then came the secret: she is not yet convinced any of it mattered. That doubt led her to reconsider what product management is for, how decisions and prioritization work, and how to allocate tokens. It brought her back to the roadmap.
Why roadmaps worked under scarcity
In her account, roadmaps made sense when engineering was scarce. They laid out strategy, listed features, and relied on a concept called "effort," which meant more than voice-noting a request to an agent. Teams thought carefully about sequencing, milestones, and MVPs. Scarcity also helped filter out bad ideas, "theoretically, let's be honest," because the bottom of the list never shipped. Below the cut line, there were not enough engineers and not enough organizational conviction. "Now we can ship all our bad ideas," she said. "Congratulations to us." Cheap execution, in her view, still needs judgment.
Three traps
Vo argued that a roadmap combined with seemingly limitless execution creates three traps.
The backlog trap. If you have a backlog, AI will build all of it. She hears many teams say they have burned through their backlog because all it takes is telling an agent to go build it. But clearing requests and ideas is not meaningful progress for the business, or even against a customer problem.
The parity trap. She felt this one directly with the product graph. Competitors copy each other, talk to the same customers, ingest the same insights, reach the same obvious conclusions, and build the same obvious products. They then polish everything the same way: run a taste skill, run Impeccable, remove the em dashes, remove the borders. Competitive dynamics that used to be interesting are evening out. What counts as a moat or differentiator is, she said, a big open question for her.
The churn trap. A team ships something, sees noise or some pickup or nothing, and because it can always ship something else, abandons it. It never learns or builds on what it shipped.
All three feel productive from the inside: the backlog shrinks, competitive features grow, output is at record levels. Her warning was that they "accelerate our path to mid."
"Roadmap zero"
She named the condition she is observing "roadmap zero." She did not mean an empty backlog, though she said some teams really have reached that. She meant that every visible feature is now both plausible and buildable. When everything on the backlog can be done, she asked, what is the backlog for?
In her view, buildability and effort no longer serve as meaningful proxies for what matters, and prioritization as the industry has practiced it stops being strategy. Teams still run RICE scoring, but when several of its inputs, especially effort, mean little, she questioned why anyone pretends prioritization is the right frame.
This is why she called roadmaps dangerous, not just outdated. An AI factory fed by an old-style roadmap will lead teams into all three traps "at machine speed," because the factory cannot tell a consequential bet from a mere idea. AI makes the consequences of weak judgment arrive faster, so bad ideas become real problems sooner than ever.
The remaining constraint is truth
In place of the roadmap, she asked a different question: what do you believe strongly enough to go out and try to prove? The remaining constraint, she said, is not code, building, or features. It is truth: on-the-ground truth with customers. AI cannot turn an untested assumption into fact, "no matter how many adversarial reviews you do." Teams need real customers, real data, repeated tests, a distinctive point of view, and a high quality bar.
AI does allow faster contact with reality, which she welcomed. But she said that raises the obligation to actually engage with reality: to get into the market and accept what it says. She acknowledged this sounds retro to veterans who have long preached "outcomes over outputs," while the central artifact still lists features and dates. Engineering scarcity once made that workable. Under roadmap zero, she argued, a feature list becomes "ammunition for a very powerful slop cannon." The shift she wants is upstream, from what we need to build to what we need to prove.
What to do instead: conviction, evidence, factory, allocation
She laid out an alternative cycle:
- Build convictions. Decide the direction and what you believe the future looks like, not in three, six, or nine months, but in one or two years.
- Define evidence up front. Decide what you would need to see to prove you are right, and what would make you stop.
- Use the factory. She was clear she is not abandoning it. "I love something dangerous." Fast building is what lets teams hit reality quickly. The point is to place it correctly in the process.
- Allocate. Once you have contact with reality, direct investment, conviction, effort, and tokens accordingly.
The principle she emphasized most was "durable convictions but disposable features." She mentioned that Mara, a later speaker, objected that enterprises love feature roadmaps. Vo responded that some companies have already changed features and products around consumers repeatedly, and that consumers, at least some, have accepted that churn. She expects customers and teams to shift toward asking whether to bet on a conviction, a team, a space, or a vision, while accepting that features come and go and may be unique to a customer or market. Her goal: clear progress against convictions, "zero ego about your solutions."
Good stubborn and bad stubborn
Holding durable convictions requires stubbornness, and she distinguished two kinds. Good stubborn means staying with the problem, revising the solution, and holding to your view of the future even when some trend of the week is popular. Bad stubborn means using abundant tokens to move the goalposts: "we're close, we'll just ship again," over and over. She asked the audience to consider which kind they practice, and how to build systems that can absorb disposable features while keeping rigor around quality and learning.
Not every ship is a promise
She admitted this is scary when it reaches customers, but she believes we are moving to a world where not everything shipped is a promise. She recalled the old way: going to the go-to-market team "hand on heart" and swearing a feature would ship with specific functionality on a specific date so it could go in contracts. Today, she said, many releases are truly experiments. You might be wrong, the market might shift, or the technology might change dramatically.
She proposed being explicit about the level of commitment behind each release:
- Probe: a bet, a limited exploration.
- Experiment against a conviction: something the team strongly believes in and will stay with until it gets it right.
- Promise: shipped functionality customers can rely on and build their own customers on, which the team will keep compounding.
She called this perhaps the most useful lens for the new roadmap: how strong is our conviction, and how durable is this promise, as opposed to how hard is it to build and what is the estimated impact. Throughout, she said, remember that "code is abundant, customer trust is not."
That, she explained, is why the product graph stayed feature-flagged off despite repeated rebuilds. She knew that once customers saw it, they would build on it and use it. If she lacked conviction that it was right, she would burn their trust.
From the velocity game to the ambition game
Vo said she still thinks teams need a roadmap, but one built around ambition, and bigger. She does not want to see "onesie-twosies." She wants to see the future a team believes should exist, the evidence that shows progress, what would prove the team wrong, and what earns more time, tokens, and customer attention.
She described the past 12 to 18 months as "the year of our Claude": PMs writing PRs, prototypes everywhere, a pure velocity game. Faster prototypes meant faster customer feedback. Faster handoffs meant faster PRs. Agents handled tech debt and features. She thinks that period built real muscle for high velocity, but does not think velocity is the game for next year. Next year, she argued, is the ambition game. What huge swings can a team make? What experiments can it run in two or three weeks that previously would have taken a year? How does it build a roadmap of very large investments in very ambitious builds? She considers that more important than raw feature velocity, and does not think the current roadmap format serves it.
She told of a conversation with someone asking what OKRs should track an AI transformation, with PRs or revenue per headcount as candidates. Vo's suggestion was to count how many huge experiments the team runs per month, assuming most will fail. She said she doesn't care what the experiments are and doesn't know what they should be. The model is "big on the ambition and very fuzzy on the specifics."
The ask: write your last roadmap
She closed with a request she also called a gift: build your last roadmap. She was explicit that this does not mean your last plan. It means no more spreadsheets of ideas and features with guessed impact and dates, locked in with a promise never to change. Instead, she urged the audience to raise their conviction and ambition, come up with big ideas, and define success a year or two out. She acknowledged this means making big guesses, since she herself can't tell what will happen in a week or two.
The goal, she said, is a factory that can surprise you, the willingness to discard software, and a high bar for that factory. Teams will write a lot of code and throw it away, which she called good, because customers don't need trash products. AI will have better ideas than the team, also good, but it must be held to a very high bar. And teams won't be able to promise colleagues or customers what next year looks like. Her response: "Good. Because it's probably going to be better than you can imagine right now."
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 can 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 Grock bots. I can build almost anything. And here is my true true confession. I am out of good ideas, y'all. I'm like 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. And 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 that I have been in than before. You know, it used to be that engineering capacity was the scarce resource. I mean that's kind of why we exist honestly, is engineering capacity used to be the really scarce resource. We had way more ideas than people and 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, like 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's just constrained on this precious engineering capacity. And so things got narrowed 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 building, what can I build, to believing, what do I believe is actually worth building. And look, I am like 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, in our heart of hearts conviction, like 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 a lot of 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. 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, this 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 ChatPRD. It's a real product for product managers idea and it's not special because everybody's done it. But it's like 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, you know, 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. And 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 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. 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. So, 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 mean, I rearchitected ChatPRD 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 me voice noting, you know, 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. 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. It will build every single thing on your list. And so I hear a lot about, you know, we've burned through our backlog. It's because all you have to do is slash go 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. Can you tell I took max? Yeah. So we're all doing the exact same thing. And so this parity trap, where we used to have this really interesting dynamic with competitors, now it feels like it's evening out. And again, 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 shipping. And so 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 it just 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 we've gone through the roadmap, although some people truly have roadmap zero, 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 that 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 this meaningful proxy for what matters. And prioritization, again kind of why PMs exist as we've practiced it, I think stops being strategy. Right, we've been doing these RICE prioritizations, but when many of those letters mean nothing anymore, especially effort, 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. And 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 turn 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 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 who are 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 again, engineering scarcity once made that workable. But 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 slop 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 would think about what we do instead of a roadmap. First we build our convictions. So what is the direction that we want to go and what do we believe the future looks like? Not in 3 months, 6 months, 9 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 that's dangerous, but I love something dangerous. 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 is 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 this 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 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 while 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 has anybody... come on. Has anybody shipped some... thank you, right in the middle. Like you ship things and you're
Like, this is a hypo, 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 process, 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. You can definitely sell it in the contract, like, you know, and 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, 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, I, 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 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 Claude, 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 is 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, 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.
Article published · Updated