"AI support agent: GA in Q3." The line sits on a roadmap slide somewhere in your company right now. It looks like every other commitment made on that slide in the last twenty years, and it's the only one on the page structurally unable to keep its promise.
The feature will ship. Whether it works, for whom, and how often is not a date. It's a distribution. An AI agent's quality moves with the model version, the data it reads, and the prompt behind it, so the same feature behaves differently every run. A classic roadmap has no cell for a moving target.
Most product teams handle this by pretending. They bolt AI features onto a delivery roadmap built for fixed scope, then spend every review explaining why "done" slid again. The fix is not a better estimate. It's a different planning format.
Why the classic product roadmap breaks for AI agents
A feature-and-date roadmap encodes three assumptions. Scope is fixed before the build starts. Progress is linear, so 80% built means 80% done. And done is binary; the feature works or it doesn't.
Deterministic software earned those assumptions. An export button behaves the same on every click, so once it passes QA it stays passed. AI agents break all three at once.
Scope isn't fixed because capability isn't known upfront. You discover what the agent can do reliably by building evals and testing against real cases, not by writing a spec. Progress isn't linear because the last mile is the whole project; getting an agent from 70% to 90% task success routinely takes longer than getting it from zero to 70%. And done isn't binary because the feature keeps changing after launch. A model upgrade can lift quality overnight or quietly break a prompt tuned for the old behavior.
A roadmap promises a fixed outcome on a date. An AI agent delivers a distribution of outcomes on that date. Presenting the second in a format built for the first is how done turns into a recurring argument.
There's a second break, less discussed: the roadmap's audience changed. Your roadmap used to be read by humans in a quarterly review. Now part of its audience is coding agents and AI copilots reading your planning docs as context. A Gantt chart in a slide deck is invisible to them. A structured markdown doc is not.
Quality bars and eval readiness as roadmap milestones
The format survives non-determinism when milestones stop being features with dates and start being thresholds with gates.
Instead of "launch support agent, Q3," the milestone reads: the agent resolves 70% of tier-1 tickets with under 2% harmful responses, measured on a 300-case eval set. Ship when the bar is met. The date becomes a forecast, and the bar becomes the commitment. Stakeholders can hold you to a bar. They can only be disappointed by a date.
This reorders what you plan around. The critical path for an AI feature is rarely the build; a working prototype often exists in week one. The path runs through:
- Eval readiness: the golden dataset and scoring method exist before the build, because without them "is it good enough" is a vibe, not a decision.
- Data availability: the agent needs access to the tickets, docs, or usage history it reasons over, and getting clean access often takes longer than the feature.
- Quality gates per stage: internal dogfood at one bar, limited beta at a higher bar, GA at the highest. Each gate is a measurement, not a meeting.
The classic sequencing craft still matters here; goal-oriented roadmaps have been arguing against feature-and-date lists for a decade. The product roadmapping guide on Product Map, built with contributors Roman Pichler and Phil Hornby, covers those formats; the shift for AI features is wiring a measurable quality bar into every milestone those formats produce.
How Product Map plans now: one LLM-friendly doc, no roadmap
Our own planning at Product Map stopped looking like a roadmap about a year ago. Not as a philosophy decision; the artifact stopped earning its maintenance cost. Every model release moved the ground under a quarter-long plan, and we were updating a picture of the work instead of the work.
What replaced it is a small set of markdown docs in our git knowledge repository. One file holds a now/next/later list, a few lines per item. Behind each "now" item sits a ready-to-build PRD: the user problem, the scope boundary, acceptance checks, and guardrails for anything model-powered. Engineering picks the doc up directly, and so do the coding agents; the same file is the context a human reads and the prompt an agent builds from.
That's the property worth copying: the doc is written to be LLM-friendly. Plain markdown, one topic per file, explicit constraints, no information living only in a diagram. When a PRD is ready, an engineer can hand it to a coding agent and get a first implementation the same day, which means the planning artifact and the build instruction are now the same document.
Planning itself became a review cadence, not a ceremony. When a model update changes an agent's behavior, we edit the doc and the git history records the decision. Nobody re-layouts a timeline.
The honest caveat: we're a small team, and this works partly because everyone reads the repo. At 40 teams you still need a communication layer over the docs for execs and customers. But the source of truth should be the buildable doc, with the roadmap view generated from it; most companies have it backwards, maintaining the slide and improvising the spec.
Communicating a probabilistic AI roadmap to stakeholders
The hardest audience for a probabilistic plan is a deterministic-minded exec. They fund roadmaps to get predictability, and "it's a distribution" sounds like an excuse. The translation rule: commit to dates for what you control, commit to bars for what you don't.
You control process milestones. The eval set exists by March. The beta opens to 50 accounts in April. Those get dates, and you should hit them. You don't control when the agent crosses 90% task success, so the bar gets a confidence statement instead: on current trajectory, likely May, and here's the curve of eval scores over the last six weeks moving toward it.
Report trajectory, not percent complete. "The agent is 80% built" is a meaningless sentence for an AI feature. "Resolution rate went from 61% to 68% in two weeks against a 70% GA bar" tells an exec exactly where the work stands and lets them see the slope themselves. When quality regresses after a model change, say so with the same chart; a stakeholder who has been reading eval curves for two quarters treats a dip as information, not a crisis.
A now/next/later roadmap for AI features with quality gates
If you keep one visible roadmap format for AI work, make it a now/next/later cut where every item carries its gate:
- Now: features in active build against a defined quality bar. Each shows the bar, the current eval score, and the stage gate it's driving toward. Nothing enters "now" without an eval set.
- Next: features in eval and data prep. The work here is building the golden dataset, securing data access, and defining the bar. This column is where AI features earn the right to be built.
- Later: bets waiting on capability or evidence. Some items sit here explicitly tagged "revisit at next model generation," which is a real planning state in 2026, not a parking lot.
The format keeps the sequencing conversation stakeholders need while refusing the false precision of dates on distributions. Movement between columns is a measurement event: an item leaves "next" when its eval set exists, and leaves "now" when it clears the GA bar.
You don't have to draft this alone. The product strategy and roadmap AI agent on Product Map builds a now/next/later cut from your product context and pressure-tests the sequencing, so the version you bring to stakeholders already has the gaps argued out.
FAQ: planning with AI agents
Do AI agents need a roadmap?
Yes, but the unit changes. You still sequence bets, allocate the team, and tell stakeholders what's coming. What dies is the feature-with-a-date row. The durable roadmap for AI work sequences quality gates and learning milestones; the dates attach to process steps you control.
How do you estimate AI feature timelines and set dates?
Estimate the parts with known shape: data access, eval construction, integration, and the first working version. Forecast the quality climb from measured trajectory, the way you'd forecast a conversion curve, and give ranges tied to eval evidence. Put hard dates only on gates you control, like "beta opens when the eval set is complete in April."
What replaces the PRD when AI agents build the feature?
The PRD survives; it gets shorter and machine-readable. Ours at Product Map are markdown files with context, scope boundaries, acceptance checks, and guardrails, stored in the same repo the coding agents read. The spec and the build prompt converge into one document, which is also why plans stay current: updating the doc is updating the work.
Which AI agent helps you plan a product roadmap in 2026?
Use one grounded in your own product context rather than a generic chat. Product Map's strategy and roadmap agent shapes a six-month plan, flags strategic gaps, and stays anchored to your goals; pair it with the roadmaps guide to pick the format before you generate the plan. Then treat every output as a draft for your judgment, because sequencing bets is still the PM's call.
