# How to Build an AI Roadmap That Survives the Next Model > An AI roadmap commits to dates only in the near term and to outcomes in the long term. The Now-Next-Later format, assumptions to record, how to prioritize. *Tags: ai, roadmap, planning, product* --- > [!info] Quick Definition > An **AI roadmap** is a product plan that separates what is committed to with dates (concrete features in the near term) from what is committed to with outcomes (user problems in the long term), because the capabilities of models change in months. Its goal is that a new model version doesn't make the whole plan obsolete. ## Why does a traditional roadmap fail with AI? A twelve-month roadmap of features and dates assumes the underlying technology stands still. With AI it doesn't. Pmtoolkit sums it up this way: a single model release can invalidate a twelve-month feature roadmap. Something deferred because the model was unreliable can become trivial months later, and a feature committed to with a date can stop being needed without anyone deciding so. The problem isn't planning too little. It's committing in the wrong place. What changes with technology is the mechanism for achieving something; the user's problem often stays the same for years. That is why the fix is to commit to the problem and leave the method open. ## How should an AI roadmap be structured? Pmtoolkit proposes outcome-anchored horizon planning: each item is tied to a user outcome, not an implementation, and the plan gets less specific the further ahead it looks. | Horizon | What is committed | Review cadence | |---|---|---| | Now (0 to 3 months) | Features with an owner, a date and a success metric | Weekly | | Next (3 to 9 months) | An outcome and two or three candidate approaches, without choosing one | Monthly | | Later (9 to 24 months) | Only a user outcome | Quarterly | This resembles Now-Next-Later, with one important difference: each column holds a different type of content. Teresa Torres puts it this way: solutions in Now, opportunities in Next and outcomes in Later. Elezea considers this format well suited to an AI-assisted world, because it lets the how change without changing the why. Pmtoolkit gives an example of all three levels around one outcome. In Now: cut report generation for analysts from 40 minutes to under 5, with a templated export by March 15. In Next: reduce time to first report, with three candidates (templated export, a natural-language query layer or scheduled digests). In Later: analysts produce the weekly report without a data team in the loop. If an executive asks for feature dates far in the future, Pmtoolkit's suggested answer is to give the outcome and the date of the next review: "We are committed to this outcome and will review the approach in Q3." It also notes that strategy is tested in Later: if an outcome can't be tied to a validated market need, the problem is product-market fit, not the roadmap format. ## Which assumptions should you record? For each item in Next and Later, write the assumptions that hold it up, one line each. Pmtoolkit proposes three categories: - **Model capability:** what the model must do reliably, and the reliability bar. - **Cost curve:** the inference price the product's numbers assume. - **Regulation:** the specific pending rule that could restrict the feature. Illustrative example: "the model summarizes contracts with an error under 5%" or "the cost per query stays below one cent." Reviewing assumptions is different from reviewing progress: the first asks whether the bet still makes sense, the second whether the work is on schedule. According to Pmtoolkit, an assumption review can surface problems before outcome metrics do. When a new model ships or an assumption breaks, revisit the initiative with the new evidence. If you use RICE, check which of the four factors changed. Pmtoolkit warns that a new capability does not automatically raise confidence: re-score only where the evidence supports it. ## How do you prioritize under AI uncertainty? RICE scores reach, impact, confidence and effort; ICE scores impact, confidence and ease. GetWidget argues that RICE, ICE and WSJF miss two risks specific to AI: - **Does the data exist in usable form?** A feature can have high impact and still be unworkable if the data doesn't exist or can't be used. - **What happens when the system is wrong, and how fast can you undo it?** If the error is cheap and easy to correct, the bet is different from one where the failure is unrecoverable because it affects money or health. As a practical rule, reversible initiatives with a low cost of error can start before irreversible ones, even when they look less valuable on paper: you learn faster and risk less. One warning about using AI to prioritize: Pmtoolkit accepts that a model can summarize tickets, group requests or find drop-off points, but says the team must stay responsible for the ranking. A model can count 200 export-bug tickets; it can't weigh them against a migration the team knows about. ## How do you put conditions on milestones? A useful milestone has an owner, a deliverable, an evidence threshold, the decision to be taken when it is reached, the consequence if it isn't, and a review date. VarenyaZ agrees that an AI plan should include decision gates and work to stop or revise initiatives that fail to meet the criteria. The evidence threshold is the most useful part. Illustrative example: "the pilot works" says nothing; "70% of tasks complete without correction over two weeks on 200 real cases" says when to continue and when to stop. The same goes for dates and expected benefits: treat them as assumptions subject to evidence, not as facts. ## Example Illustrative example: a shopping platform wants to reduce the time it takes to find products. In Now, the team commits to a natural-language search feature with a four-week pilot, an owner and an evidence threshold. In Next, the problem is "users can't find size variants," with two candidate approaches: embeddings or an assisted filter. In Later, the outcome is "find the right product in fewer than two searches." When a cheaper model appears, the team reviews the cost assumption, not the whole plan. The two Next approaches are re-scored, and one moves up. ## Common mistakes - Committing to feature dates that depend on a model capability that doesn't exist yet. - Putting solutions in all three columns of the roadmap. - Prioritizing by impact and effort alone, without asking about data or the cost of errors. - Defining milestones without an evidence threshold. - Not recording assumptions, so nobody knows what would invalidate the plan. - Raising an initiative's confidence just because a new model shipped, without evidence. - Treating the roadmap as a fixed commitment instead of a plan that gets reviewed. ## When NOT to use it When the team has a single AI initiative and a clear deadline, a horizon roadmap can be excessive; a list of milestones with thresholds is enough. Also when leadership needs firm date commitments for contractual reasons. In that case, commit to a minimum scope and make explicit which assumptions could force a change. To decide which initiatives deserve a place on the roadmap, review [[ai-product-strategy|AI product strategy]] and [[ai-feature-roi|AI feature ROI]]. ## Sources - [Pmtoolkit, Roadmapping When the Model Changes Every Six Months](https://pmtoolkit.ai/learn/strategy/roadmapping-under-model-uncertainty) - [Elezea, Product roadmaps: how the best product teams plan for uncertainty](https://elezea.com/2026/04/product-roadmaps-how-the-best-product-teams-plan-for-uncertainty/) - [GetWidget, AI Use-Case Prioritization Framework](https://getwidget.dev/blog/ai-use-case-prioritization-framework/) - [VarenyaZ, AI roadmap (glossary)](https://varenyaz.com/glossary/ai-roadmap/) --- Source: https://www.fernandoux.com/en/wiki/ai/ai-roadmap/