Roadmapping Under Model Uncertainty
Use a three-horizon roadmap and record the assumptions that could invalidate each bet as model capabilities change.
Roadmaps often track features and releases more precisely than business outcomes. When delivery speed increases, teams need to revisit whether planned work still supports the intended outcome.
Why the twelve-month feature roadmap breaks
Annual feature planning often treats delivery capacity as the central constraint. AI-assisted development can change that constraint for some teams, which makes prioritization and discovery reviews more important.
Faster delivery does not establish that the team is building something customers need. Review the intended outcome as well as delivery progress.1
The second force is model volatility. In an AI product role, a single model release can invalidate a twelve-month roadmap2. The feature you scoped for Q4 because the model could not do it reliably in January may be a prompt away by June. The differentiator you committed to may ship inside the next model version as a default capability. Feature-level commitments a year out were always optimistic. When the underlying capabilities change, those commitments may no longer fit the problem.
Keep the long-term outcome visible while reviewing the proposed implementation.1 You can commit to a user outcome for two years. The features that deliver that outcome can change with the technology.
Outcome-anchored horizons
My PM Interview's guide to AI roadmaps calls the fix outcome-anchored horizon planning: anchor every roadmap item to a user outcome rather than a technical implementation, then organize time into horizons that carry different levels of specificity, detailed where you have confidence and directional where you do not2.
The following three horizons provide a starting structure. Adjust the timeframes and review cadence to your product:
| Horizon | Timeframe | What you commit to | Specificity | Review cadence |
|---|---|---|---|---|
| Now | 0 to 3 months | Named features with owners and dates | High: scoped work, success metrics defined | Weekly |
| Next | 3 to 9 months | Approaches to an outcome | Medium: problem statements, two or three candidate solutions | Monthly |
| Later | 9 to 24 months | User outcomes | Directional: the outcome, the audience, why it matters | Quarterly |
For example, a Now item names a scoped delivery commitment: "reduce report-generation time for analyst accounts from 40 minutes to under 5, shipping the templated-export flow by March 15." A Next item names the problem and the leading approaches without picking a winner: "cut analyst time-to-first-report; candidates are templated exports, a natural-language query layer, or scheduled digests." A Later item is only the outcome: "analysts produce their weekly reporting without a data team in the loop."
The Later horizon is also where strategy gets tested. If you cannot tie a Later outcome to a validated market need, the problem sits upstream of the roadmap, in product-market fit, not in planning format.
When an executive asks for feature-level dates in the Later horizon, the honest answer is the outcome plus the review date. For example: "We are committed to X outcome and will review the approach at Q3." This makes the current uncertainty explicit.
Write down what would invalidate each bet
A horizon plan still fails if nobody notices when its premises expire. So every initiative on the Next and Later horizons gets a short list of assumptions that must stay true for the bet to make sense. Three categories cover most of them:
- Model capability. Does this need something models do reliably today, or are you betting a capability arrives? Name the capability and the reliability bar.
- Cost curve. Do the unit economics work at today's inference prices, or only if prices keep falling? Write down the price you are assuming.
- Regulation. Does the feature depend on a data use or deployment context that pending rules could restrict? Name the specific rule you are watching.
Then review the assumptions on the same cadence you review progress, monthly for Next and quarterly for Later, matching the table above. Progress reviews tell you whether the work is on schedule. Assumption reviews tell you whether the work still makes sense, and may reveal a problem before it appears in the outcome metrics.
Put the assumptions in the roadmap artifact itself, one line each, next to the initiative they protect. Keeping them alongside the work makes them easier to include in reviews.
When an assumption breaks, revisit the initiative with updated evidence. If you use RICE, check which estimates change: Reach, Impact, Confidence, or Effort. A new capability does not automatically raise confidence, and a competitor release does not automatically reduce reach. Re-score where the evidence supports it, then discuss the result alongside strategic priorities.
The second user stream: agents
Products used through APIs can serve both human users and AI agents. Agents may call tools through protocols such as MCP without opening the product interface.1 Assess whether this use matters for your customers before assigning it roadmap priority.
API-only usage will not appear in browser clickstream events. It needs measurement at the API layer, alongside the metrics used for human customers.
That has two roadmap consequences. The agent surface earns its own items: API coverage for the jobs agents actually perform, machine-readable documentation, error responses an agent can recover from without a human reading a stack trace. And it needs its own measurement plan, defined at the API layer rather than the client: calls per task, retry rates, task completion. PM Toolkit runs an agent surface itself, 17 calculator tools exposed over MCP and used from Claude Code and Cursor rather than the browser. Direct tool calls need server-side measurement; PM Toolkit tracks MCP usage through server-side analytics.
If your roadmap has zero items for the agent surface, that is itself a bet. Write it down as one: "we assume agent-driven usage stays immaterial for our category through 2026," and review it with the others.
Where AI belongs in the roadmapping process
Use AI to help organize evidence for roadmap reviews: summarize support tickets, group feature requests, and examine where usage drops off.1 Check the output against the source material before using it to support a decision.
Keep the team responsible for ranking. Asking a model what to build from customer feedback alone leaves out strategy, timing, technical debt, and context held by the team.1 A model can count the 200 tickets mentioning export bugs. Whether fixing exports beats the platform migration only your team knows about is a call the corpus cannot make for you.
This division of labor mirrors the broader pattern in the AI product management field guide: AI absorbs the production work, and the judgment moves up a level. Ranking roadmap bets is that judgment layer, applied quarterly.
FAQ
How far out should an AI product roadmap commit to specific features? In this structure, the Now horizon covers about three months, followed by approaches at 3 to 9 months and outcomes at 9 to 24 months. Adjust those windows to how much you know and how quickly the assumptions behind the work change.
Is this just Now/Next/Later with extra steps? It uses Now/Next/Later with two explicit practices: different commitment types for each horizon, and a scheduled review of the assumptions behind Next and Later work.
What do I tell an executive who wants feature dates for next year? Offer the outcome, the current leading approach, and the next review date. Explain what needs to be learned before committing to a feature and delivery date.
How do I measure AI agents using my product? For API-only usage, measure at the server: which tools or endpoints get called, calls per completed task, error and retry rates. Treat a rising agent share of total usage as a roadmap signal in its own right.
Does any of this apply if my product has no AI features? Yes. Outcome planning and assumption reviews also apply to products without AI features. Consider agent access separately if customers use your APIs that way.