Your AI product roadmap is missing a layer
Feature roadmaps assume the technical ground stays still. For AI products the model keeps improving underneath you, so your roadmap needs a capability layer as well as a feature layer.
Key takeaways
- Part of an AI product’s value sits on a capability curve owned by your model provider, so it moves whether or not you ship anything
- Stanford’s AI Index put the cost of GPT-3.5 level performance at $20 per million tokens in November 2022 and 7 cents by October 2024, a fall of more than 280 times
- METR has the length of task frontier models complete unaided doubling roughly every seven months, a trend holding for about six years
- An AI product roadmap needs a capability layer underneath the feature layer, tracking what has become possible
- Label your scaffolding, run a routine evaluation habit, keep a conditional capability list, and treat model releases as product events
Here’s a situation a lot of product teams have now lived through at least once.
You spend most of a quarter engineering your way around a model limitation. Prompt chains, guardrails, fallback logic, retry handling, a whole scaffold of careful work to get reliable output from something that was only ever going to be about eighty per cent reliable on its own. It ships. It works. Everyone is pleased.
Then a model upgrade lands, and the base model does the whole thing natively in one step, more reliably than your scaffold ever managed.
Your roadmap didn’t predict that, and it was never going to. So now you’re making a call nobody trained you for. Do you rip out the scaffolding, keep it as a safety net, or leave it in place and let it slowly turn into technical debt that somebody discovers during a refactor eighteen months from now.
This is the tension sitting underneath AI product management in 2026, and it’s worth naming plainly. A meaningful share of your product’s value is no longer entirely within your control. It’s tied to a capability curve that belongs to your model provider rather than to your backlog. That curve moves on price as well as capability. Stanford’s AI Index found the cost of running a model at GPT-3.5 level performance fell from twenty dollars per million tokens in November 2022 to seven cents by October 2024, a drop of more than 280 times in about eighteen months, and a fair few architecture decisions made on cost grounds in that window were obsolete before the work shipped.
Two model generations is not a long time anymore. Plan on a twelve month horizon and you are planning across at least one doubling.
Feature roadmaps assume the ground stays still
Classic roadmapping works, and it has worked for decades, because it rests on a reasonable assumption. You decide what to build, you build it, the value is locked in, and it stays locked in until you decide to change it. Every planning ritual most product teams run is shaped around that.
AI products break the assumption, because the floor keeps rising underneath them. A feature that took heavy engineering last quarter might take none this quarter. A feature that looks impossible today might be trivial two model generations from now, and two model generations is not a long time anymore. METR, which benchmarks how long a task a model can finish on its own, has the length of task frontier models can complete with fifty per cent reliability doubling roughly every seven months, a trend that has held for about six years. Plan on a twelve month horizon and you are planning across at least one doubling.
Plan as though the ground is static and you tend to land in one of two places. Either you over-invest in scaffolding that a model upgrade quietly makes redundant, or you under-invest in the organisational muscle you need to notice a capability jump and do something with it while it still counts as being early.
Whether the model underneath your product changes is often not your call. When it changes is sometimes not your call either.
What a capability roadmap looks like
None of this means throwing out the roadmap you already have. What it means is adding a second layer underneath the feature layer, one that tracks what has become possible rather than what you’ve committed to build.
In practice, four things.
Build an evaluation habit alongside the shipping habit
Teams need a lightweight, repeatable way to ask “can the model do this now?” before anyone commits engineering time to building it the hard way. It should feel as routine as sprint planning, and it should take about as long as a stand-up.
Label your scaffolding
Know which parts of your product exist to work around a model limitation, and which parts are product differentiation that no model upgrade is going to hand you for free. Write it down somewhere your team will see it. When the scaffolding stops being necessary you want to find out that week, rather than during a refactor six months later.
Run two roadmaps in parallel
One holds committed feature work in the usual way. The other holds capability bets, phrased as conditionals: if the model can reliably do X by Q3, here’s what that unlocks and here’s what we’d stop building. That second list is how you stop being blindsided and start being early.
Treat model upgrades as launch events
When a new version drops, it’s easy to file it as a backend update and move on. Sometimes it’s a product moment, and the teams who treat it that way consistently move faster than the teams who find out from a changelog three weeks after the fact. The timelines are not generous either. OpenAI retired GPT-4o, GPT-4.1 and o4-mini from ChatGPT in February 2026 and GPT-5.1 the following month, and on Microsoft Foundry the 2024 release of GPT-4o retires in October 2026 with workloads automatically upgraded to GPT-5.1 in place. Whether the model underneath your product changes is often not your call. When it changes is sometimes not your call either.
Why this is more urgent with agentic AI
Agentic systems, meaning models that plan, use tools and act across multiple steps, are advancing quickly enough that whole categories of hand-built orchestration logic are becoming redundant almost as fast as teams can ship them. We’re seeing it in our own work and in what clients bring us: elaborate coordination layers built in good faith six months ago that the current generation of models handles natively.
The product leaders doing well in this environment have a particular skill, and building more scaffolding is not it. They know exactly which scaffolding to remove, and when to remove it, which is a harder discipline than it sounds because it means retiring work your team was proud of.
Your feature roadmap tells the team what to build. A capability roadmap tells them what to watch for and gives them the standing permission to act on it. Running only the first one leaves you planning with half the picture. If you’re working out how to frame any of this for your board, the capability layer is usually the part that makes the timeline credible, and it’s close to how we work with product teams on this problem.
Serar Serar is Head of Product and Delivery at Restive. He works with engineering and product teams to close the gap between strategy and execution.
Frequently asked questions
What is a capability roadmap?
A capability roadmap tracks what your underlying technology can do over time, running alongside the feature roadmap that tracks what your team is committing to build. For AI products it maps expected model capability against the product work you would start or stop if that capability arrives.
How is AI product management different from traditional product management?
Traditional product management assumes the technical foundation stays fixed between releases. AI products sit on foundation models that improve independently of your roadmap, so part of your product’s value changes without you shipping anything. Planning has to account for capability shifts you don’t control.
Should we build workarounds for current AI model limitations?
Often yes, provided you label the workaround as scaffolding rather than as product, and review it at every model release. The risk is not the scaffolding itself. It is forgetting which parts of the product are scaffolding and carrying them for years after they stopped being needed.
How do you plan a product roadmap when AI models keep changing?
Run two layers. Keep the committed feature roadmap as normal, and add a capability layer written as conditionals covering what you would unlock or retire if specific capabilities arrive. Pair it with a routine evaluation habit so you find out what the model can do before you build around it.
What is agentic AI and why does it affect product planning?
Agentic AI describes models that can plan, use tools and act across multiple steps rather than responding to a single prompt. It affects planning because orchestration logic teams build by hand is increasingly handled natively by the models, which shortens the useful life of that work.
Related articles
Real outcomes, for real Australian organisations.
How we built AI-powered personalisation and retail media for one of Australia’s largest supermarket chains.