Most of what I read about AI and product roadmaps splits into two camps:
- AI will fix everything.
- AI will ruin everything.
There is some discussion in the middle, of course, but people usually prefer to say something controversial rather than offer a balanced take.
I have worked on a few very different products, and the hard part about building a roadmap was never the same twice. What worked on one was beside the point on the next.
So treat this as one practitioner thinking out loud, not a playbook.
If anything, the longer I do this, the more I value stopping every so often to ask whether my own habits still make sense - and whether the tools I have reached for are quietly helping or quietly getting in the way.
Speed only acts on a decision you already made
Let me start where almost everything I read ends up. Marty Cagan put it bluntly: people are using AI to build roadmaps, and they still have their crappy roadmaps - they are just doing them faster.
Speed acts on whatever decision you already made. Good or bad, it just gets there sooner.
That sounds obvious written down. It stops being obvious the moment you notice how much of the current excitement is, underneath, just excitement about speed.
Where roadmaps came from
It helps to remember where roadmaps came from.
I am describing a pattern here, not a universal truth - plenty of teams always worked differently, and someone reading this will think "it was not like that where I was." They are probably right.
Roadmaps built well in advance, closer to waterfall than to anything iterative. Roadmaps moving through layers of approval until they became the thing people were judged against - done or not, green or red.
Roadmaps tightly coupled to a strategy that changed rarely, so predictability was treated as a value in itself. Sometimes the stability had a more mundane source: a contract with a large client, turning the roadmap into a list of obligations dressed in product language.
I would not dismiss that as simply outdated. In regulated industries, large infrastructure programs, and systems where a mistake costs lives or millions, predictability is still the value, not the obstacle.
But that older shape is the backdrop the rest of this sits against.
The same roadmap, read four ways
The other thing worth saying about that backdrop is that the same roadmap was rarely read the same way twice. Different stakeholders pick up the same document looking for different things.
- A product manager reads it to justify decisions.
- Engineering reads it to anticipate technical debt and feasibility.
- Marketing reads it to plan campaigns around dates.
- Leadership reads it to check progress against strategy.
None of those readings is wrong. They just rarely line up perfectly - and a fair amount of what gets called "roadmap conflict" is really these readings quietly colliding.
That tension predates AI by decades. It is worth holding onto, because most of what follows is less a new problem than an old one moving faster.
The numbers we are speeding into
A few numbers from recent surveys map out the landscape we are speeding into. They come from different studies with different definitions, so read them as directional, not precise - but the direction matches what I keep hearing.
- Around 80% of teams leave engineers out of the early phases - ideation, problem definition, roadmap creation.
- Roughly half of PMs say they do not have enough time for strategic planning, and more than 66% of their week goes to manual work.
- Only about a third feel confident they are building the right product.
- In one study of 66 software companies, only 14 built their roadmap around value rather than features.
On payoff, three research houses give three different readings:
- Deloitte finds 66% report productivity gains, but only 20% see actual revenue growth.
- McKinsey finds only 39% of organizations report any enterprise-level profit impact from AI at all.
- Gartner expects more than 40% of agentic AI projects to be canceled by 2027.
Enthusiasm, in other words, is running well ahead of measurable outcome - though how far ahead depends entirely on which survey you trust.
A few patterns that stuck with me
These are the patterns I keep coming back to - in the sources, and in conversations with other product people.
AI helps least exactly where roadmapping lives. In one developer survey, the reported benefit fell off a cliff as you moved from building toward deciding: strong for design and implementation, weak for requirements, weakest of all for planning. Which is more or less the core of what a roadmap is. The place the tools help least is the place the hard work happens.
The time AI saves comes back as checking. A Microsoft study found most PMs say AI saves them time and improves quality - and yet a majority also say the effort required of them has not actually dropped. My read: the work does not disappear, it relocates. You hand off the drafting and inherit the verification.
A roadmap was never a neutral plan. Long before AI, researchers studying multi-year, industry-level technology roadmapping documented the real mechanics of the practice: controlling who is in the room, building coalitions, framing the technology around problems people already cared about. A roadmap selects perspectives, legitimizes scenarios, and mobilizes participants.
None of that goes away when AI shows up. AI-generated summaries can gatekeep or frame just as easily - only faster.
The thing genuinely brewing: intent debt
So far, so familiar. But here is the thing I keep circling back to - the one I think is genuinely brewing under all of this.
It is an idea one researcher, Margaret-Anne Storey, has started calling intent debt. She takes the old notion of technical debt - the shortcuts in code you pay for later - and extends it into decisions.
Intent debt is the slow disappearance of the written-down why: the goal, the constraint, the trade-off you weighed at the time. The thing nobody records because, in the moment, it feels too obvious to bother with.
Here is what caught me. AI is genuinely good now at the what and the how. It drafts the feature list, scaffolds the code, summarizes the feedback, generates the plan. The one thing it cannot do - because it was not in the room - is remember why you chose one thing over another.
So you end up with a roadmap that is richer, faster, and more detailed than ever, while the reasoning underneath it quietly evaporates.
To be clear, connecting intent debt to roadmaps is my own extension - Storey writes about software health more broadly. But it is the connection that made everything else click into place for me. And the more I sit with it, the more plausible it feels.
A roadmap is not really a list of features. It is a record of decisions - this over that, now instead of later. Strip out the reasoning and what is left is a list of outputs with no way to judge whether they still make sense once the market moves. And the market keeps moving.
There is a number that makes it less abstract. A study of more than 302,000 AI-assisted commits found over 15% introduced at least one issue - and almost a quarter of those were still sitting in the latest version. The shortcuts do not get cleaned up. They accumulate.
Now picture the same dynamic one level up, at the level of intent rather than code: the faster we ship without recording the rationale, the faster the coherence drains.
What unsettles me is who inherits the result. It used to be the next product manager, who could at least ask around. Increasingly it is an AI system asked to extend a roadmap it has no record of the reasons behind. It will happily produce something plausible. It just has nothing real to evaluate against.
I cannot prove this is happening at scale - the evidence is scattered, and I am joining dots the studies did not draw themselves. But it matches what I see, and what I keep hearing from other product people.
Maybe AI did not create the disappearing why. Maybe it just sped everything up enough that we can no longer afford to skip writing it down.
If the reasoning behind a decision is never recorded, does the roadmap lose coherence - or do good teams carry the why in their heads well enough that it never needed to be on paper?
A few shifts worth keeping an eye on
These are bigger than tactics - less "do this" than "the ground may be moving." I am not certain any of them will hold, but they turn up across enough unrelated sources that I have stopped dismissing them.
The constraint is moving from building to deciding. If AI keeps making the building cheaper, the bottleneck stops being how fast you can ship and becomes whether you picked the right thing to ship.
Andrew Ng describes one of his AI Fund teams proposing to flip its staffing from one PM per four engineers toward two PMs per engineer, on exactly that logic - while admitting he does not yet know whether it is a good idea. Others are drawing the opposite conclusion - that AI absorbs enough discovery work to justify fewer PMs. Both are circulating.
But either way, the deciding - which is what a roadmap is - gets more weight, not less.
The roadmap as a record of decisions, not a list of outputs. This is the intent-debt idea turned into a stance: if the why is the one thing AI cannot reconstruct, then the rationale becomes the part of the roadmap actually worth protecting. A feature list ages badly. A decision with its reasoning attached can still be re-judged when the market moves.
The same idea can be wrong now and right in six months. Andrew Ambrosino, who leads the Codex desktop app at OpenAI, talked about this on Lenny's Podcast. He framed part of roadmapping as a timing question: when can an idea actually be turned into value, given what is possible right now? For them it hinged on model maturity. The same thing shipped too early reads as a failure, and a few months later as a success.
The take I came away with is my own, not his: you can have a roadmap full of genuinely great items and still be wrong about all of them, if you judge them outside the current technical and business reality.
So treat validation as something you redo, not something you do once. At every larger shift - a new underlying technology, a swing in the market - go back to an item and re-ask whether its moment has arrived, passed, or has not come yet.
The PM role is drifting toward orchestration. Parikh frames the PM moving toward something like an orchestrator of a socio-technical system rather than a lone decision-maker - coordinating people and AI rather than out-producing either.
The Microsoft study puts a guardrail next to that drift. Across 885 PMs, the working norm was to delegate the drafting but hold on to the decision: accountability must not be delegated to non-human actors. Worth noticing that is a value those PMs chose to hold, not a law - and 12% of them were already writing code with AI, so the line moves.
Governance is becoming a practice, not a policy. Two unrelated groups landed here from different directions. A 2025 XP-conference workshop of 30+ practitioners argued for continuous AI governance over a policy written once and filed away. Deloitte's enterprise survey found the most-cited barrier to AI value was not the technology but a skills gap.
The shift, if it is real, is away from "we have an AI policy" toward "we keep re-deciding how we use this as it changes."
Outcome-over-feature is still the road less traveled. We have talked about value-driven roadmaps at conferences for years, yet in one study of 66 software companies only 14 actually built theirs around value rather than features. AI does not change that math on its own. If anything, cheap output makes it easier to fill a roadmap with features and skip the harder question of which outcome they are meant to serve.
None of these are predictions I would bet money on. They are directions that several sources - none of them talking to each other - seem to be leaning the same way on.
Questions I keep coming back to
These are the questions I have been sitting with - some mine, most sharpened in conversations with other product people who are clearly wrestling with the same thing. It is worth doing this kind of audit on yourself now and then, and especially now, while the tools are changing faster than our habits around them.
- Is this tool actually improving my work - or just helping me produce more of it, faster?
- How would I even know? What would I honestly measure: time saved, fewer reworks, better decisions, less second-guessing later?
- When I use AI to write something for other people, am I helping them understand - or just shifting the work of reading and making sense of it onto them?
- Am I reaching for AI to think more clearly, or to avoid the thinking altogether?
- If I removed the AI from a given task tomorrow, would the quality of my work drop - or just the volume?
- Across the different products I have worked on, the right approach was never the same twice. So why would the right way to use AI be?
The act of asking these out loud, with other people, can be more useful than any single tool.
A few approaches worth chewing on
These are just approaches I have seen others reach for, offered as conversation-starters more than conclusions.
Match the format to the situation, not the trend. The format a team lands on tends to say more about its situation than its sophistication. Now-Next-Later while you are still hunting for fit. Date-and-OKR timeline when compliance outweighs speed. Dependency view when you are juggling a portfolio. A small litmus test: if your roadmap format does not let you answer "why this over that," it might be the wrong format for where you are.
Treat prioritization as a discipline, not a vibe. Even teams who all know RICE or ICE often default to whoever argues most persuasively in the room. One idea that might be quietly useful is to add Time-to-Value as a third axis next to impact and confidence - not revolutionary, just a small nudge away from pure instinct.
Watch for AI amplifying the loudest voices. AI is good at reading sentiment from reviews and tickets, but it amplifies whoever is speaking - usually the thrilled and the furious. The quiet majority who simply use the product stays invisible. Worth asking now and then: who is not in this summary?
Spend on clarity, not just information. If AI makes reports and summaries nearly free, the scarce thing becomes shared understanding of what is actually wanted, and why. That is slower, more human work, and it does not automate well.
Write the why down while it is fresh. It is the one piece of intent debt that looks genuinely fixable - and, ironically, capturing rationale is exactly the kind of low-glamour writing the tools are already decent at, if we point them there.
I would genuinely love to hear which of these you think is wrong, or what you have seen work that is not on the list. That is the part I am actually curious about.
Sources
- Marty Cagan (2026). AI Product Management - 2 Years In (LinkedIn); summarized at airfocus.com
- Andrew Ng (2025). Public remarks on PM-to-engineer ratios in AI-native teams (an AI Fund team's proposal; summarized by Lenny Rachitsky).
- Andrew Ambrosino (2026). Lenny's Podcast - on the Codex desktop app and roadmap timing.
- Atlassian (2026). State of Product 2026 (N=1,000+, US/France/Germany).
- Airtable (2026). Product Management Trends 2026: 10 Future Predictions.
- Product School (2026). Product Management Trends: 11 Shifts Shaping 2026.
- Dr. Nishant Parikh (2025). Agentic AI in product management: A co-evolutionary model. arXiv:2507.01069.
- Zheying Zhang, Tomas Herda, Victoria Pichler, Pekka Abrahamsson, et al. (2025). AI and agile software development: A research roadmap from the XP2025 Workshop. arXiv:2508.20563.
- Dr. Stefan Trieflinger (2024). Development of Outcome-Driven Product Roadmaps (Doctoral dissertation, University of Stuttgart).
- Deloitte AI Institute (2026). The State of AI in the Enterprise: The Untapped Edge (N=3,235, 24 countries).
- McKinsey & Company (2025). The State of AI: How Organizations Are Rewiring to Capture Value.
- Gartner (2025). Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027 (press release, June 25, 2025).
- Stefan Lessmann, Prof. Dr. Robin Gubela, Vincent Gurgul (2026). The State of Generative AI in Software Development: Insights from Literature and a Developer Survey. arXiv:2603.16975.
- Ulloa, M., Butler, J. L., Haniyur, S., Miller, C., Amos, B., Sarkar, A., & Storey, M.-A. (2025). Product Manager Practices for Delegating Work to Generative AI. arXiv:2510.02504.
- Nijssen, E. J., Chakraborty, S., & Valkenburg, R. (2025). Stakeholder involvement in industry-level technology roadmapping: A political perspective. Technological Forecasting and Social Change, 221, 124358.
- Margaret-Anne Storey (2026). From Technical Debt to Cognitive and Intent Debt: Rethinking Software Health in the Age of AI. arXiv:2603.22106.
- Liu, Y., Widyasari, R., Zhao, Y., Irsan, I. C., Chen, J., & Lo, D. (2026). Debt Behind the AI Boom: A Large-Scale Empirical Study of AI-Generated Code in the Wild. arXiv:2603.28592.