The last roadmap | Claire Vo
In a Nutshell
The speaker argues that traditional product roadmaps are obsolete because engineering scarcity is no longer the constraint—now the bottleneck is conviction about what is worth building. AI enables shipping at unprecedented speed, but this creates three traps: task accumulation, competitive parity, and premature abandonment. The new approach requires shifting from feature lists to "conviction roadmaps" that define ambitious bets, the evidence needed to prove them, and the willingness to run many experiments while maintaining high standards for what becomes a customer promise.
These notes were generated by AI and may contain inaccuracies.
Good morning everyone. The speaker stayed up very late at 8:15 with a small child but arrived ready to present. Last year, the speaker declared that product management was over but now acknowledges being wrong. Product management is not dead, with many great product leaders, product managers, and executives present. The speaker asks who agrees that product management has changed completely since the last Linyi Summit, and the room supports this view.
Last year the speaker came for product managers but that didn't work out. This year the focus is on the roadmap, followed by OKRs, after which the speaker's role will end. The roadmap has always been the essential tool in the field, supposed to tell teams where they are headed, what is next, and what is important. After over two decades in the products industry, the speaker believes many in the room are about to write the final roadmap.
The speaker has a confession: they are releasing more products than ever before. They have access to the smartest programming agents, best developer tools, highly intelligent models, and customer context through API, CLI, MCP, and all available means. The speaker counted 40 Grok robots yesterday and can build almost anything. The honest confession is that they have run out of good ideas. They have completely run out of ideas regarding things they can build. They can build but don't think any of them are good ideas. This is not about lacking reasonable demands or things that can be built, but rather that execution has exceeded their ability to discover valuable, essential, or marketable products.
This is a completely different situation from before. Engineering ability was a scarce resource, which was the main reason product managers existed. There were far more ideas than staff, and demand exceeded the ability to meet it. The job of the product manager was to prioritize all those ideas and spend most time in meetings, on Slack, and in spreadsheets saying "no." Product managers needed to say "no" more often with clear boundaries. The job of engineering seemed to be to say "No, not like this. Not with all these features. Not with a perfect architecture. We can't do more than this." Design's task seemed to be to say "No, wait for us. Please." Everyone became bound by precious engineering ability, and things got more difficult until only a small part of the roadmap was published.
Now the speaker feels they have more executive ability than genuine conviction about what needs to be built. The obstacles have shifted from thinking about building what could be built to believing in what was truly worth building. The speaker is a huge advocate for resource exploitation, tripling withdrawal requests and working on everything with agents everywhere. No product manager or other qualifications are needed. But the gap between ability to build and firm conviction about whether code has value is a much bigger problem than admitted. Everyone is under pressure from the board, schedule, each other, and bosses to move faster, take advantage of artificial intelligence, focus on it, and demonstrate potential.
The speaker can build in this new way. Last year the speaker said product management had ended with scary circles displayed, saying "Launch to the moon. Do it. Do it. Do it." But the speaker believes none of them are like that. The question asked was who achieved the highest shipping rates in their companies during the past year and whose revenues increased proportionally to the size of purchase orders. This is the fundamental problem faced.
The speaker tells a story about having an idea for a "product blueprint" for chat product requirements documentation (PRD). It's a genuine product idea for product managers, not unique because everyone has done it. It would gather everything the company knows about customers and what it works on, analyze this data, add "Opos," and make it available through agents. It would enable better decisions, better products, and better PRDs. The speaker built an insights engine and sophisticated semantic product graph that is automatically created as a wiki for agents to use. It worked and looked good, matching competitor features. But every time the speaker built this product, they would say to themselves: "This belongs in the trash. All this work, all this wonderful product, belongs in the trash." Because it was a competitor, not an outstanding individual. Even though it clearly had a market, people would probably want it, and customers said it was interesting, deep down the speaker felt it wasn't worth customers' attention. The return on investment was uncertain, and the speaker wasn't convinced by the user interface.
The speaker wondered whether this product should remain a webinar-style product, whether focus should be on the agent first, and whether this was the best option. They wanted to build something amazing that competitors couldn't even imagine. The biggest problem was that the symbols and roadmap laid out to execute the bet were neither tested, nor confirmed, nor reinforced conviction. Meanwhile, code was being piled to no avail. The speaker continued to release more programs than ever before. Customer repairs became automated, with requests sent to robot programs and then fixed. The goals were to eliminate technical debt. The speaker redesigned Chappy seventy times because they could. They stopped tracking problems, saying they didn't need to track problems anymore and would only issue withdrawal requests. This artificial intelligence factory appeared and began operating on its own, doing what everyone wanted it to do. It's magical.
The secret is that the speaker is not sure if any of it matters. They are not entirely convinced of the importance of all that. This prompted deep thinking about what product management is, the purpose of software development, how decisions are made, how priorities are set, and how resources are distributed. The speaker always came back to the idea of a roadmap. Road maps made sense given the scarcity of engineering resources. It defines strategy and tells what features will be developed. There was what was called the effort, which meant more than just taking voice notes. A lot of thought went into sequence, key milestones, and minimum viable product. Scarcity, in theory, helped filter out bad ideas because the last ideas were never put forward. There weren't enough engineers. There was not enough conviction throughout the organization. These were "ideas that were never put forward."
Now all bad ideas can be thrown out. Congratulations. The speaker believes cheap implementation still needs careful evaluation. We are now witnessing a moment where the roadmap, in addition to unlimited ability or feeling of unlimited implementation, creates three traps. The first is the trap of accumulating tasks. If you have a to-do list, artificial intelligence will create it. It will create everything on the list. The problem is that getting orders or ideas done does not necessarily mean making real progress in business or solving customer problems. The second is the parity trap. All competitors are copying each other, communicating with the same customers, gathering the same information, arriving at the same intuitive conclusion, and building the same intuitive product using the same intuitive methods: improving product quality, making it look good, getting rid of the M marks, and eliminating the boundaries. Everyone does exactly the same thing. This is more like a parody trap, where there was an interesting dynamic with competitors. Now things seem to be balancing out, and the question of what constitutes competitive advantages and differentiating factors remains important.
The last trap is the trap of abandonment. Products are launched, some confusion is noticed, and either acceptance or rejection occurs because another product can always be launched, so products are abandoned without learning or developing what is offered. All these things seem very fruitful from the inside. The backlog of tasks is shrinking, advantages are growing, and more products are being released than ever before. But what is happening is speeding up the path towards the middle of the road.
This leads to the concept of the "zero roadmap." This doesn't mean the roadmap is finished, although some people already have a zero roadmap meaning there is nothing in it. It means that every visible feature becomes possible and implementable. There is no empty to-do list. Simply put, everything on the to-do list is something that can be accomplished. When everything on the to-do list is doable, what is the point of the to-do list? Feasibility and effort cease to be important indicators of what is essential, and prioritization, as with project managers, ceases to be a strategy. We have been relying on prioritization, but when so many of these elements lose their meaning, especially the effort involved, why do we still pretend that prioritization is the right way to think about products? That's why roadmaps are a thing of the past. Their era is over.
It is extremely dangerous at the moment to rely on artificial intelligence with an outdated roadmap. It will lead into those three traps very quickly. Because the system cannot distinguish between a significant bet and a mere idea, artificial intelligence will demonstrate the consequences of poor assessment more quickly. Bad thoughts will turn into problems faster than ever before. The roadmap is not the ideal solution. The solution lies in asking: "What do I believe in strongly enough to make an effort to prove it?" Because the remaining constraint is not the code, nor the construction, nor the features. That's the reality experienced on the ground with clients. Artificial intelligence cannot consider an untested assumption as an absolute truth, no matter how many counter-checks are conducted. Real customers, real data, and repeated testing are needed. Then a very unique perspective and very unique and high quality standards are needed. What artificial intelligence allows is to communicate more quickly with reality, and that's fantastic. Everyone wants to connect with reality more quickly. But this means there is a greater obligation to face reality. The market must be entered and what it dictates must be accepted.
This will seem very old-fashioned because the focus is on results rather than outputs. However, the central document, the roadmap, still lists features and dates. The lack of engineering resources wants to make it practical, but the zero roadmap makes these features and dates extremely risky. The list of features becomes ammunition for a very powerful cannon. What is needed is to move from the building phase to the proof phase.
Instead of just a roadmap, convictions must be built. What direction should be taken? How should the future be envisioned? Not after three months, or six months, or nine months, or even after a year, or two years. Where will all this lead? It is essential to identify the evidence that proves the validity of conviction, and this should be determined in advance. What needs to be seen to prove the right thing is being done, and what needs to be seen to stop? A factory is needed. The speaker personally loves factories and says it's dangerous, but likes dangerous things. The factory is needed; the ability to build extremely fast to keep up with reality is needed. This is not about getting rid of it, but rather putting it in the right place in the process. Then capital must be allocated. The cycle must be gone through, and when reality is reached, investment, conviction, effort, and symbols must be directed in the right direction.
What is most interesting about this new world is that firm convictions are needed, but with changeable features. The speaker was talking to Mar, who was going to take the stage later, and she said companies love feature development plans. At the end of the day, people have made a lot of changes to a lot of features and products. As consumers, some have accepted that level of change. So the point will be reached where customers and teams can think: "Am I betting on these convictions? Am I betting on this team? Am I betting on this space? Am I betting on this vision?" Features have to come and go. They might be unique to a particular person, they might be unique to a particular market. What should be seen is clear progress toward achieving convictions, but without any arrogance about solutions. There are two possible ways to do that. Stubbornness must be maintained about deeply held convictions, but there's good stubbornness and bad stubbornness. Good stubbornness is staying true to the problem, revising the solution, holding on to what's going to happen even if there's a trend. Bad stubbornness is that because there are codes, the objective is simply changed. "Ah, we're close. We'll reship again and again." The question should be considered: deeply held beliefs - positive stubbornness or negative stubbornness? How to integrate into the system the ability to accommodate changeable features while maintaining quality standards and learning? This is truly scary, especially when it impacts customers, but the point is being reached where not everything offered is a promise.
The speaker asks if anyone is feeling hesitant, if anyone has ever shipped a product. Products are shipped saying "This is a hypothesis—this is a real experiment, and I could be wrong, or the market could change, or the technology could change dramatically." The idea must be considered that not every product launched is a process or a promise. Roadmaps used to be relied upon, and the speaker would swear to God that they would launch the product and say "I swear on my children, this feature will be launched with these specific things on this specific date." It could certainly be included in the contract. Promises were being made, and now careful thought is needed about how to communicate internally and with customers. Everything will be used, starting from the experimental stage like a bet explored a little, leading to a more serious experiment to test convictions. This is something truly believed in and will be stuck with until the desired outcome is achieved. Then there are promises. Promises mean that a product has been launched that customers can rely on and build their customer base on. It is truly believed in and will continue to be developed. Honesty is needed about commitments to any feature. This is almost the most important angle of the new roadmap: how strongly it is believed in, how robust that promise is, compared to how difficult it is to build, and what its expected impact is. As this is done, code is plentiful, but customer trust is scarce.
Going back to the product blueprint, that feature that was developed over and over until convinced of its validity was marked because once shown to the customer, they would build upon it and use it, and if not convinced it was true, customer trust would be lost completely. That was thought about very carefully during the launch of that feature. A roadmap is still needed, but it should be more about ambition. It needs to be broader. A partial roadmap is not wanted. The future believed in should be seen. What the evidence shows should be seen. Are we making progress? What might prove us wrong? What will earn more time and customer attention? The speaker wants to get back to ambition because the last 12 to 18 months have been the golden year, where everything was being released, product managers were writing pull requests, and prototypes were everywhere. The speaker truly believes we are in a sprint. A real sprint. If prototypes can get to customers faster, they'll give feedback faster. If things can get to customers and the engineering team faster, they'll be able to write pull requests faster. Agents will take care of the technical aspects. Agents will take care of the features. In the last 12 to 18 months capabilities have been building up to achieve real sprint. This is not the strategy for next year. Next year is a race of ambition. Radical changes that can be made must be thought about. What experiments can be run in two or three weeks that would have taken a whole year last time? How can a roadmap for very large investments in very ambitious projects be created? This is more important than just the speed of feature development. The current roadmap is not achieving this.
The speaker was talking to someone and went back to the concept of OKRs, which unfortunately still exist. She asked what OKRs should be adopted in the transition to artificial intelligence, for example withdrawal requests and revenue per employee. The speaker was asking her: "How many large experiments do you conduct per month?" It doesn't matter what kind of experiments they are, and what they should be is unknown. But how many bold attempts are made each month, assuming most of them won't work? This is a completely new way of thinking about how to map out the roadmap and develop products. Again, it's about big ambition and ambiguity in the details.
The request to everyone is to put the final roadmap in place. This doesn't mean the final plan. It means stopping with the lists of ideas and features in spreadsheets, where impact is guessed, a date is set, and then agreement that nothing will ever change because that's how things operate. That era is over. Instead, conviction and ambition must be built, great ideas must come up with, and what success will look like in a year or two must be defined. Some big decisions must be made. The speaker is relying on guesswork because what will happen in a week or two cannot really be predicted. The point must be reached where there is a system that can surprise. Unnecessary software must be gotten rid of and then the system must be leveled up. The system will be up to the highest standards. A lot of code will be written and then discarded. That's fine. Customers don't need mediocre products. AI will generate better ideas than the team. That's fine. Good ideas are needed, and very high standards must be set for that AI. Promises cannot be made to the team or customers about what next year will look like. That's fine, because it will probably be better than can be imagined right now. The final roadmap must be written. This stage will be very enjoyable.
Keep Lenny's Podcast in your library
Save the videos and channels worth coming back to, and find them again in one place.
