Chapter 6: Building Your Roadmap

Ali Süleyman Topuz

“A roadmap is not a promise. It is a hypothesis about the best sequence of work, held with enough conviction to act on and enough humility to revise.”

The Roadmap as Translation

The work of the previous three chapters assessing readiness, analyzing demand, building a budget is diagnostic work. It answers the questions of where you are, what you need, and what you can afford. The roadmap is the answer to a different question: in what order do you do the work, and by when?

That question is harder than it sounds. AI transformation involves at least two parallel streams of work: building production systems that deliver near-term value, and making foundational investments that enable future systems. These streams interact with each other foundational work unlocks use cases, use case development reveals gaps in the foundation in ways that make sequencing genuinely complex. They also involve different types of uncertainty: the near-term work is uncertain because building AI systems is harder to estimate than traditional software; the long-term work is uncertain because the technology, the market, and the organization will change in ways that cannot be predicted.

A good AI transformation roadmap navigates this complexity without pretending it does not exist. It makes deliberate sequencing choices, communicates them with enough specificity to guide execution, and builds in the adaptations points that allow the plan to be updated as learning accumulates. It is not a Gantt chart, though some of its content can be expressed as one. It is not a feature backlog, though it contains many specific work items. It is a translation from the strategic intent established in the demand and budget analysis to the ordered, resourced, time-bounded plan of work that will execute against it.

This chapter describes how to build that plan: which frameworks structure the sequencing decision, how to populate each time horizon, how to communicate the roadmap to different audiences, and how to make it adaptive without making it unstable.

What an AI Transformation Roadmap Is Not

Before describing what a good AI roadmap contains, it is worth clearing away three common but flawed approaches that consume significant planning energy and produce roadmaps that fail in predictable ways.

The feature wishlist. The first flawed approach is building the roadmap by aggregating all of the AI ideas from the demand analysis and arranging them in priority order. This produces a list, not a roadmap. A list does not account for sequencing dependencies the fact that the analytics capability requires a data pipeline that has not been built, or that the field mobile AI requires the onboarding assistant infrastructure to be in place first. It does not account for learning the team will know things after building the first system that will significantly change how they approach the second. And it does not account for the foundational investments that are prerequisites rather than deliverables. A feature wishlist treated as a roadmap is the most common cause of the “AI feature graveyard” described in Chapter 1.

The overly precise long-range plan. The second flawed approach is attempting to plan AI transformation in the same level of detail across all time horizons specifying Q3’s work items with the same precision as Q1’s. Long-range AI plans are almost always wrong in their specifics, not because the planners were careless but because AI transformation involves genuine uncertainty about what the technology can do in your specific context, how customers will respond to each feature, and what foundational work turns out to be necessary. Treating a twelve-month-out plan item with the same level of commitment as a six-week-out plan item leads to organizations that cannot adapt when not if the specifics turn out to be wrong.

The top-down mandate. The third flawed approach is producing the roadmap at the leadership level and presenting it to the engineering and product teams as a fait accompli. AI transformation requires the buy-in and judgment of the people doing the work. Engineers who understand the technical constraints need to validate that the sequence is executable. Product managers who understand customer behavior need to validate that the use cases are well-specified. When the roadmap is produced without this input, the execution team discovers the gaps the unstated dependencies, the infeasible timelines, the missing data during implementation rather than during planning.

The Three Horizons Framework

The most effective structure for an AI transformation roadmap organizes work into three distinct time horizons, each with different levels of specification, different types of deliverables, and different management approaches.

The near-term horizon (months 1–6) is the execution horizon. Work in this horizon is fully specified: defined use cases with documented requirements, known data sources, assessed technical approaches, and allocated team time. Near-term items should be scoped conservatively sized to what the team can confidently deliver in six months, including the time required for evaluation, iteration, and operational launch. This horizon is where the roadmap functions most like a traditional project plan: the team knows what they are building, and success is measured against specific, observable milestones.

The mid-term horizon (months 7–18) is the strategy horizon. Work in this horizon is directionally specified the use cases are identified and prioritized, the foundational dependencies are understood, and the resource requirements are estimated but the detailed specifications are not yet written, because they should be informed by what the team learns in the near term. Mid-term items should be held with enough conviction to resource for and plan toward, but with enough flexibility to be adjusted as near-term results arrive. This is the horizon where the investment in foundational infrastructure begins to pay off, enabling use cases that were not feasible in the first six months.

The long-term horizon (months 19–36) is the vision horizon. Work in this horizon describes the transformed state the organization is building toward the capabilities that will exist, the customer experiences that will be possible, the operational model that will be in place but it is not specified in implementation terms. The long-term horizon is the destination that gives direction to the near- and mid-term sequencing decisions. It also communicates to executive stakeholders and to the organization what the transformation is for: not a series of features, but a fundamentally different way of operating.

The three-horizon structure serves two purposes simultaneously. It provides the specificity needed to execute the near-term work without pretending that twelve-month-out specifics can be known today. And it provides the narrative coherence the story of where the organization is going and how each piece of work fits into it that keeps teams motivated and aligned across the full duration of a multi-year effort.

Populating the Near-Term Horizon

Selecting the right first AI project is one of the most consequential decisions in the transformation roadmap. The first project establishes the team’s initial sense of what AI development feels like in their specific context, the organization’s initial confidence in AI as a strategic direction, and the template architectural, operational, evaluative that subsequent projects will build on. Getting it right matters more than getting subsequent projects right, because the learnings from the first project cascade forward.

The criteria for a strong first AI project differ from the criteria for the highest-impact AI investment. The highest-impact investment may require data infrastructure that does not yet exist, team capability that has not been built, or organizational change that has not yet happened. The strongest first project is the one that maximizes learning and confidence while delivering real value, at a level of complexity that the current team and infrastructure can handle without being rescued by luck.

Four criteria define a strong first AI project. High data readiness: the data required to build and run the system is available and in a usable form without significant preparation. This removes the largest source of schedule risk from the first project data problems are notoriously unpredictable in their resolution time. Clear success criteria: there is an unambiguous definition of what good looks like, measurable from the output of the system. This makes evaluation tractable and learning concrete. Contained failure mode: if the system underperforms or fails, the consequence is manageable it does not directly harm customer relationships or expose the company to liability. Genuine organizational value: the use case should address a real pain point that real people in the organization will notice and appreciate. A first project that is technically successful but that nobody uses teaches the wrong lessons about what AI can do.

Using these criteria, map the candidate use cases from Chapters 3 and 4 against each dimension. The use case that scores highest across all four criteria not the highest-impact use case overall is the right first project. High impact at high risk is not the appropriate profile for a first project. High learning, high confidence, genuine value is the appropriate profile.

After the first project is selected, populate the remaining near-term horizon with one or two additional use cases that can begin development after the first project is sufficiently advanced typically when the first project has reached a stable production deployment and the team has the bandwidth to take on new work. These should build on the infrastructure and operational patterns established by the first project, reinforcing the shared foundation rather than starting fresh with each new use case.

One common mistake in near-term horizon planning is filling it too densely. The instinct, once the use case list is built and the scoring is done, is to start as many use cases as possible in parallel to accelerate the transformation. Resist this instinct. Parallel AI development projects share engineering attention in ways that are particularly costly: debugging a retrieval quality problem in one system while simultaneously building the prompt architecture for another produces worse outcomes on both than sequential focus would. In the near-term horizon especially, depth beats breadth. One well-built, well-evaluated, well-documented production system teaches the team more than three half-finished projects, and it produces the organizational confidence that sustains investment in the subsequent horizons.

Populating the Mid-Term Horizon

The mid-term horizon is where the transformation begins to look like transformation rather than a collection of AI features. It is the horizon in which the infrastructure established in the near term enables use cases that would not have been feasible at the start, in which organizational capability begins to compound, and in which the relationship between AI investment and business outcome becomes visible in the data.

Populate the mid-term horizon with the use cases from the demand analysis that scored high on impact but lower on near-term feasibility the ones that require data preparation, infrastructure investment, or organizational change that will be completed during the near-term horizon. Sequence them so that the foundational work they depend on is completed before the use case development begins, with a buffer of at least four to six weeks between the completion of the foundational dependency and the start of the use case work. Foundational work reliably takes longer than planned, and buffer protects the mid-term schedule from near-term delays.

The mid-term horizon should also include at least one capability demand use case something the organization genuinely cannot do today that AI would make possible. These use cases typically require the most foundational investment and carry the most implementation risk, which is why they belong in the mid-term rather than the near-term. But they are also the use cases that produce the most durable competitive differentiation, which is why they should not be deferred to the long-term horizon. The mid-term is the right time to begin the data infrastructure and architectural work that makes capability demand use cases possible, even if the full realization comes later.

Plan for explicit learning reviews at the boundaries between the near- and mid-term horizons. The review should ask: What did we learn from the near-term work that changes how we should approach the mid-term work? Which mid-term items should be accelerated, deferred, or re-scoped based on what we now know? This review is not a sign of weak planning it is the mechanism by which a three-horizon roadmap stays aligned with reality over time.

The Foundational Work Track

Every AI transformation roadmap should contain two tracks, not one. The first track is the use case track: the specific AI systems being built and deployed. The second track is the foundational work track: the data preparation, infrastructure investment, team capability building, and operational infrastructure that the use case track depends on.

The foundational work track is frequently absent from AI roadmaps because it does not produce visible deliverables that can be demonstrated to customers or boards. Nobody shows the vector database migration or the evaluation framework build at a product review. But the use case track cannot progress faster than the foundational work track enables. Organizations that invest exclusively in the use case track and treat foundational work as something to be done when it is immediately needed end up building each AI system from scratch, making the same infrastructure mistakes repeatedly, and never accumulating the shared capabilities that make each subsequent system cheaper and faster to build.

The foundational work track should be planned for explicitly and resourced separately. For most B2B SaaS companies beginning AI transformation, foundational work will consume 30% to 40% of the total AI development capacity in the first year, declining to 15% to 25% in the second year as the foundations mature. This allocation is not waste it is the investment that makes the use case track increasingly productive over time.

Key items in the foundational work track for most organizations include: data audit and preparation for the priority use cases, vector database setup and initial document ingestion, LLM API integration patterns and shared service layers, evaluation infrastructure for systematically measuring output quality, prompt management and versioning systems, and AI-specific monitoring and alerting. Not all of these need to be built before the first use case begins, but they should all be planned for and resourced within the first year.

Sequencing for Learning

The most important sequencing principle in AI transformation roadmaps is to sequence for learning before sequencing for impact. This is counterintuitive most planning frameworks tell you to do the highest-impact work first but it is the right approach for AI because the uncertainty in AI development is qualitatively different from the uncertainty in traditional software development.

In traditional software, the primary uncertainty is implementation complexity: will it take three weeks or six weeks to build this feature? The domain is understood, the tools are known, and the unknowns are mostly execution unknowns. In AI development, there is an additional category of uncertainty: will the AI system actually work well enough for this use case? Can the available data support the required performance? Will customers use it in the way the product team imagined? These are not execution unknowns they are knowledge unknowns, and the only way to resolve them is to build and operate a production system.

Sequencing for learning means deliberately choosing early projects that answer the most important knowledge unknowns for the subsequent roadmap. If your mid-term roadmap includes a customer-facing AI feature that requires high reliability, sequence an earlier internal AI feature that builds the evaluation and monitoring infrastructure required for high-reliability systems. If your mid-term roadmap includes a RAG-based analytics capability, sequence an earlier, simpler RAG application that tests the retrieval quality on your specific data before committing to the more complex use case. Each early project is not just delivering its own value it is generating the knowledge that validates or refines the subsequent plan.

Managing Risk in the Roadmap

Every AI roadmap carries risk technical risk (the AI system will not perform as expected), data risk (the data will not support the required performance), organizational risk (the team will not adopt the system), and timeline risk (the work will take longer than estimated). Managing these risks is not about eliminating them that is not possible it is about distributing them in a way that prevents any single risk from derailing the transformation program.

The most important risk management technique in roadmap design is sequencing risk away from the critical path. If a high-risk use case one with significant data uncertainty or unproven technical approaches is on the critical path to a major business milestone, a single problem can delay not just that use case but everything downstream of it. When possible, place high-risk use cases in parallel with the critical path, or give them enough lead time that problems can be discovered and addressed without affecting the downstream sequence.

Technical risk is best managed through early prototyping. Before committing a use case to the production roadmap especially a mid-term use case with significant technical uncertainty invest one to two weeks in a proof-of-concept that specifically tests the riskiest assumption. Can the available data support the required retrieval quality? Does the model produce outputs of sufficient consistency for this use case? Is the latency achievable within the user experience constraints? A cheap, early test that answers these questions is worth far more than a detailed implementation plan for a system that turns out to be technically infeasible.

Data risk is managed through the use-case-level data inventory from Chapter 2, applied to the full roadmap rather than just the near-term items. For every mid-term use case, identify the data requirements and the current data state, and build the data preparation work into the foundational track well before the use case development begins. The most common source of mid-term roadmap delay is not engineering capacity it is discovering, at the moment development begins, that the data required is not yet ready.

Organizational risk the risk that internal teams or customers will not adopt the AI system is managed through early engagement and through deliberate design choices that make adoption easy. For internal systems, involving the team that will use the system in the design process, not just the launch, reduces adoption risk significantly. For customer-facing systems, the trust design principles from Chapter 4 transparency, clear explanations of AI behavior, easy override paths are the primary levers.

Communicating the Roadmap

A roadmap that cannot be communicated effectively to the people who need to act on it or fund it is not a useful planning artifact. AI transformation roadmaps need to be communicated to at least three different audiences, each of whom needs a different version of the same underlying plan.

For the executive team and board: the relevant view is the strategic narrative the three-horizon picture that shows where the organization is starting, what it will have built by the end of each horizon, and how that trajectory connects to the business outcomes they care about (revenue, churn, competitive position, cost structure). Numbers matter, but the narrative matters more. The executive view should answer: what does the organization look like differently in eighteen months, and in three years, as a result of this investment?

For the product and engineering teams: the relevant view is the sequenced delivery plan the specific use cases in each horizon, the foundational dependencies between them, the team allocations, and the milestones that define success for each item. This view should be detailed enough to support sprint planning in the near-term horizon and directional enough to support capacity planning in the mid-term. The engineering view should answer: what are we building, in what order, with what resources, and how will we know we are succeeding?

For customer success and sales teams: the relevant view is the product capability timeline what AI features will be available to demonstrate to prospects and customers, when, and with what specific capabilities. CS and sales teams need to know what is coming well enough to manage customer expectations and to incorporate AI capabilities into their customer conversations. They do not need the foundational work track or the detailed technical sequencing they need the customer-facing deliverables and the rough timeline.

Producing three versions of the roadmap from a single underlying plan requires discipline but is not difficult with the right tooling. The underlying plan captures all of the detail. The three communication artifacts are projections from that plan, emphasizing the information most relevant to each audience and omitting what they do not need.

One additional communication discipline is worth naming: the roadmap should be published and visible, not kept in a planning document that only the leadership team can access. When the engineering and product teams can see the roadmap including the foundational work track, the dependencies, and the milestones they make better day-to-day decisions. They can flag when a decision in a near-term sprint has implications for a mid-term dependency. They can raise when a technical choice is inconsistent with the architectural direction the roadmap implies. An invisible roadmap cannot be validated by the people closest to the work.

Making the Roadmap Adaptive

An AI transformation roadmap should be a living document. The near-term horizon should be reviewed monthly against actual progress and updated to reflect what has been learned. The mid-term horizon should be reviewed quarterly, with specific attention to whether the foundational dependencies are on track and whether the assumptions behind the mid-term use cases remain valid. The long-term horizon should be reviewed semi-annually, primarily to assess whether the vision it describes is still the right destination given changes in the technology landscape, the competitive environment, and the organization’s own strategic priorities.

The discipline required to keep a roadmap adaptive without making it unstable is the discipline of distinguishing between plan revisions that reflect learning and plan revisions that reflect impatience. Learning-driven revisions changing a mid-term use case because near-term results revealed an assumption that was wrong should be welcomed and executed quickly. Impatience-driven revisions changing the roadmap because progress feels slow or because a compelling new idea has appeared should be treated with more caution. Every change to the roadmap has a coordination cost: the teams aligned to the previous plan need to re-align to the new one, and frequent changes erode the organizational confidence that a stable roadmap builds.

A useful protocol: treat the near-term horizon as firm (changes require explicit justification and a clear owner for the coordination work), the mid-term horizon as directional (changes can be made at the quarterly review based on learning), and the long-term horizon as adaptive (the destination evolves as the landscape evolves). This protocol allows the roadmap to be updated when updating is genuinely warranted, without allowing it to become a constantly shifting target that the team cannot plan against.

The quarterly roadmap review should be a structured meeting, not an informal conversation. It should examine four questions in order. First: did the near-term items complete on schedule, and if not, why? Second: what did the near-term results teach us that changes how we should approach the mid-term items? Third: are the mid-term foundational dependencies on track, and if not, what does that imply for sequencing? Fourth: has anything changed in the technology landscape, competitive environment, or organization that should update the long-term vision? Answering these four questions in order produces a coherent update to the roadmap rather than a set of disconnected changes driven by whoever has the most energy in the room.

When the roadmap review surfaces a proposed change to a near-term item moving an item out because it is taking longer than expected, or moving an item in because an opportunity has appeared require the person proposing the change to write down the specific learning or event that justifies it and to name what is being de-prioritized to make room for it. This two-part discipline prevents changes that are rationalized rather than evidence-driven, and it makes the opportunity cost of every change explicit rather than hidden.

Key Takeaways

• An AI transformation roadmap is a sequenced learning and delivery plan, not a feature wishlist or a Gantt chart. Its purpose is to translate strategic intent into ordered, resourced work while preserving the adaptability needed to update based on what is learned.
• The three-horizon structure near-term execution (0–6 months), mid-term strategy (7–18 months), long-term vision (19–36 months) provides specificity where it is needed and flexibility where it is required. Each horizon is managed differently: near-term is firm, mid-term is directional, long-term is adaptive.
• Every roadmap requires two tracks: the use case track (the AI systems being built) and the foundational work track (the data, infrastructure, and capability investments those systems depend on). The foundational track is frequently omitted and frequently responsible for use case delays when it is.
• The right first project is not the highest-impact use case it is the use case that maximizes learning and confidence at manageable risk. Four criteria define a strong first project: high data readiness, clear success criteria, contained failure mode, and genuine organizational value.
• Sequence for learning before sequencing for impact. Early projects should resolve the knowledge unknowns that would otherwise create risk in mid-term projects.
• The roadmap requires three communication artifacts tailored to three audiences: the strategic narrative for executives, the sequenced delivery plan for engineering and product, and the customer-facing capability timeline for CS and sales.
• Built-in learning checkpoints monthly near-term reviews, quarterly mid-term reviews, semi-annual long-term reviews are what make a roadmap adaptive without making it unstable. Distinguish learning-driven revisions (welcome them) from impatience-driven revisions (scrutinize them).