Priya Raman leads a seven-person engineering team inside a mid-market logistics company. Her group already had a vision, written in a single sentence on a sticky note above her desk: "Use AI to cut the time our internal users wait for answers and to catch problems before customers feel them." It was a good vision. It was also, by itself, completely useless on a Monday morning. Her engineers did not know what to build first. Her director kept asking when something would actually ship. Two people quietly started competing pet projects. The vision was inspiring and the team was capable, and yet nothing moved, because there was no sequence. What Priya needed was a roadmap: a plain statement of what comes first, what comes second, what each step depends on, and how she would know it worked.

Why a vision needs a roadmap

A vision says what you are trying to achieve. A roadmap says in what order, with what resources, and managing which dependencies. Without that second document, Priya watched the predictable failures pile up: the team felt overwhelmed by too many ideas with no priority, her director grew impatient waiting for value, dependencies went unmanaged so people started initiatives before the prerequisites existed, and nothing learned in an early project ever informed a later one. Budget and capacity planning stayed ad hoc, decided in whatever meeting happened to be running.

A strong roadmap fixes exactly those problems. It creates clarity on what is first, second, and third. It sets realistic timeline expectations so leadership stops asking "is it done yet?" every week. It surfaces the prerequisite investments - clean data, training, infrastructure - before they become blockers. It builds in early wins that create momentum. And, Priya's favorite benefit, it gives a manager a defensible way to say "no, that is not on the roadmap" when a new shiny idea threatens to derail the quarter.

It helps to be clear that a roadmap is not a detailed project plan. The roadmap spans roughly twelve to eighteen months in quarters and milestones, with later phases deliberately fuzzy and early phases specific; it exists to guide sequencing and to align stakeholders, and its audience is leadership, the team, and anyone affected. A project plan covers the current three months in week-by-week tasks, owners, and resources; it should be quite specific, and its audience is the people doing the work. Priya keeps one roadmap and writes a fresh detailed plan for each phase as she reaches it.

The five parts of Priya's roadmap

Priya built her roadmap around five elements, and every initiative she considered had to be expressible in all five.

Phase structure. She organized the work into phases of roughly two quarters each. Each phase had to be a cohesive set of related initiatives, build toward the vision, include at least one quick win for confidence, include some capability-building work like training, and be completable with the resources she actually had.

Initiative prioritization. Within each phase she needed to know which initiatives to pursue and in what order, using a real framework rather than gut feel. This is where RICE came in, and the worked example below shows exactly how she scored hers.

Dependency management. For every initiative she asked what must be true first. Before her team could build an AI churn-warning model, they needed eighteen months of clean historical ticket data. Before they could draft customer-facing replies with AI, legal had to review the approach. Making dependencies explicit is how she stopped people from starting initiative B before the ground for it existed.

Resource allocation. She estimated team time, budget, and her own attention for each phase, and she was honest that most teams underestimate this and end up burned out with three half-finished projects. When the numbers showed she could not do everything in eighteen months, that was not a failure of planning; it was the planning working.

Success metrics and milestones. Every phase and major initiative got a measurable target tied back to the vision, plus dated milestones. "The internal answer-bot drafts replies for 40 percent of routine questions, cutting median wait time from 4 hours to 1.5 hours, rolled to 10 percent of users by end of month 2 and 100 percent by month 4." Vague metrics like "the team is more productive" were not allowed, because you cannot tell whether you hit them.

Worked example: prioritizing initiatives with RICE

Priya had five candidate initiatives and capacity for maybe two in her first phase. Rather than argue about them, she scored each with RICE. RICE multiplies Reach, Impact, and Confidence, then divides by Effort, giving a single comparable number.

• Reach: how many people or cases this touches per quarter.
• Impact: how much it moves the needle per case, on a simple scale where 3 is massive, 2 is high, 1 is medium, 0.5 is low.
• Confidence: how sure she is of her estimates, as a percentage.
• Effort: total person-months of work.

The formula is (Reach x Impact x Confidence) / Effort. Here is how her five initiatives scored.

• Internal answer-bot for routine support questions: Reach 400 questions/quarter, Impact 2, Confidence 80 percent, Effort 3. Score = (400 x 2 x 0.8) / 3 = 640 / 3 = 213.
• AI-assisted exception triage for the ops team: Reach 250, Impact 2, Confidence 70 percent, Effort 2.5. Score = (250 x 2 x 0.7) / 2.5 = 350 / 2.5 = 140.
• Churn-warning model flagging at-risk accounts: Reach 120, Impact 3, Confidence 40 percent, Effort 6. Score = (120 x 3 x 0.4) / 6 = 144 / 6 = 24.
• Auto-drafting customer-facing replies: Reach 600, Impact 2, Confidence 50 percent, Effort 4. Score = (600 x 2 x 0.5) / 4 = 600 / 4 = 150.
• AI documentation search across the knowledge base: Reach 300, Impact 1, Confidence 85 percent, Effort 1.5. Score = (300 x 1 x 0.85) / 1.5 = 255 / 1.5 = 170.

The ranked order came out: answer-bot (213), documentation search (170), auto-drafting replies (150), exception triage (140), churn model (24). The churn model, which Priya's director had been most excited about, scored dead last - not because it lacks impact, but because low confidence and high effort crush the score. That number gave Priya the language to push back: "It is our highest-impact idea, but we are only 40 percent confident and it needs eighteen months of clean data we do not have yet. Let us earn that confidence first." The documentation search, an idea nobody had championed, jumped to second because it is cheap, high-confidence, and broadly useful. RICE did not make the decision for her; it made the trade-offs visible and the conversation with her director about evidence instead of enthusiasm.

Choosing the criteria you score on

RICE is one scoring model, not the only one, and it is worth understanding the criteria underneath it so you can adapt them to your own domain. Any credible prioritization asks the same five questions. How much business impact does this have, meaning how far does it move the objectives you are actually accountable for? How feasible is it with the skills, data, and resources your team has today? What dependencies does it carry, and are those prerequisites in place? How confident are you that it will work, which drops sharply as the number of unknowns rises? And what is its learning value, meaning does doing this teach you something that makes the next initiative smarter?

That last criterion is the one managers most often leave out, and it is why Priya kept the cheap documentation search in Phase 1 even though its raw impact was modest. It taught her team how their people actually phrase questions, which directly improved the answer-bot. If you would rather not use RICE, the common alternative is a simple weighted scoring model: rate every initiative from 1 to 5 on each criterion, weight the criteria according to what matters most in your context, and rank by the total. The mechanism matters less than the discipline of scoring on stated criteria rather than on whoever argued loudest in the meeting.

The phased roadmap with quarters and milestones

With RICE scores and dependencies in hand, Priya laid out three phases across eighteen months. Notice that the order is driven as much by readiness and learning as by raw score.

Phase 1, Q1 to Q2 (months 1 to 6): foundation and quick wins. Initiatives: the AI documentation search (cheap, high-confidence, a fast visible win) and the internal answer-bot (highest RICE score). Capability work: the whole team takes a short prompt-engineering and evaluation course in month 1. Dependency to clear: the knowledge base must be cleaned and tagged before search is useful, scheduled for weeks 1 to 4. Resources: 2 engineers at roughly 60 percent, Priya at about 20 percent, and $18,000 for tools. Milestones: documentation search live to the team by end of month 2; answer-bot drafting replies for 40 percent of routine questions by month 5. Metrics: median internal answer wait time down from 4 hours to 1.5 hours; team satisfaction with the tools above 70 percent.

Phase 2, Q3 to Q4 (months 7 to 12): expand and build capability. Initiatives: auto-drafting customer-facing replies (now that legal has reviewed the approach during Phase 1) and AI-assisted exception triage for ops. Capability work: an advanced workshop on evaluating model output for accuracy and fairness. Dependencies: Phase 1 tooling stable; legal sign-off complete; exception data from the ops system standardized. Resources: 3 engineers, an external ML contractor for two months, $30,000. Milestones: auto-draft suggesting replies to 30 percent of customer messages by month 9, with a human approving every send; triage suggesting a resolution path for 50 percent of exceptions by month 11. Metrics: customer response time down 30 percent; exception handling time down 25 percent.

Phase 3, Q1 to Q2 of year 2 (months 13 to 18): scale and tackle the hard one. Initiative: the churn-warning model, now that the team has eighteen months of clean ticket data and has built real confidence with models. Capability work: shift roles so more senior engineers move from routine support tooling toward strategic work. Dependencies: clean historical data accumulated; team comfortable with model evaluation from Phase 2. Resources: 2 engineers, an external partner, $25,000. Milestones: churn model achieving 80 percent precision on a holdout set by month 16; embedded in the account dashboard by month 18. Metrics: at-risk accounts flagged at least 30 days before renewal; account-team time spent on proactive saves up by a measurable margin.

The shape of this roadmap tells a story. The exciting churn model that Priya's director wanted on day one is deliberately last, because the data and team-confidence dependencies it needs are exactly what Phases 1 and 2 produce. Sequencing for readiness feels slower at the start but executes faster overall, because nobody is fighting bad data or an untrained team halfway through.

The same shape in other domains

Priya's roadmap is an engineering roadmap, but the structure travels. It is worth walking through two other domains, because seeing the same five elements in unfamiliar work is what makes the pattern portable to your own.

Consider a manager who leads data and analytics for a mid-market retail company with a team of six, and a vision of using AI for demand forecasting, inventory optimization, and customer insights over eighteen months. Her Phase 1, months 1 to 6, is foundation and quick wins: train two or three people on AI and machine learning concepts as a light lift, apply AI to data cleaning as a medium-impact and high-feasibility confidence builder, and assess data quality for forecasting because that assessment is a prerequisite for everything in Phase 2. She may well discover she needs better data governance before forecasting is even possible. Resources are two people full time, a contract trainer, and around $25,000 for tools and training, and success means the team is trained and confident with one small AI project shipped and the data-quality assessment finished. Phase 2, months 7 to 12, is capability and early value: AI-powered demand forecasting, now feasible because the team is trained and the data is clean, plus a reporting dashboard so the forecasts actually get used. That phase depends on the foundation being complete and on business stakeholders agreeing how they will use forecasts; it costs three people, possibly an external machine-learning specialist for three months, and about $40,000, and it succeeds if forecast accuracy improves 15 percent and 80 percent of planners use it in decisions. Phase 3, months 13 to 18, is expansion and scale: inventory optimization built on top of forecasting, and customer segment insights informed by what the forecasting work taught them, at two people and roughly $35,000, targeting inventory carrying costs down 10 percent and time-to-decision on new product investments down 40 percent.

Now consider a very different setting: an operations leader in a manufacturing plant with 200 factory workers and a small engineering team, whose vision is AI for quality inspection, predictive maintenance, and production optimization. Phase 1, months 1 to 6, is a pilot on one product line for AI-assisted visual quality inspection, paired with deliberate change management and worker communication because anxiety on the floor is high. Its dependencies are camera hardware and a model trained on the plant's own historical defects; it needs one engineer full time, a part-time change manager, and around $60,000 for cameras and model development, and success is defined as the AI detecting 85 percent of the defects human inspectors catch with worker satisfaction with the pilot above 70 percent. Phase 2, months 7 to 12, scales quality inspection to all product lines using Phase 1 learnings and starts a predictive maintenance pilot, which depends on the quality AI working reliably and on collecting six or more months of sensor data; at 1.5 engineers and $40,000 it targets 80 percent accuracy in predicting equipment failures and unplanned maintenance incidents down 25 percent. Phase 3, months 13 to 18, adds AI-driven production scheduling that uses both the quality and maintenance signals, for one engineer and $25,000, aiming at throughput up 12 percent.

That manufacturing roadmap works for reasons worth naming out loud. Phase 1 is built around building trust with workers, because change management, not technology, is the real constraint in that plant. The sequence lets learning compound, since what the team learns about quality data directly informs predictive maintenance. The resource allocation is honest about a small engineering team. And every phase has a clear, measurable outcome, so nobody has to guess whether it worked.

Dependencies and the capacity reality check

Priya's first draft tried to do everything at once, and the dependency map saved her from it. She walked backward from each initiative asking "what must be true for this to succeed?" The churn model needed clean data; auto-drafting needed legal review; triage needed standardized exception records. Each of those answers turned into a Phase 1 prerequisite rather than a Phase 2 surprise. When a dependency shows up, it does not just delay an initiative - it tells you what to actually do first.

It helps to know the kinds of dependency you are hunting for, because managers reliably spot one or two and miss the rest. There is prerequisite work, as in standardizing your response templates before you can automate support. There is data readiness, as in needing eighteen months of clean historical data before you can predict anything. There is infrastructure, as in upgrading a data pipeline before real-time predictions are possible. There is team capability, as in engineers needing training on prompting and evaluation before they can build with these tools. And there is organizational alignment, as in legal and compliance review before anything customer-facing launches. Priya ran each initiative against all five categories and wrote the answers directly into the roadmap, because a dependency that lives only in a manager's head is not managed.

She also ran a blunt capacity check. Her team had about 20 percent free capacity this quarter on top of existing work. That math meant one major initiative plus supporting work, not two. To do two at once she would need to add a person, pause some existing work, or extend the timeline, and she made that trade explicit to her director instead of quietly overcommitting and missing dates. A roadmap that assumes unlimited resources is not optimistic; it is a credibility risk waiting to detonate. Under-estimating capacity has three reliable consequences, and Priya had seen all of them: burnout, when initiative work is piled on top of existing jobs; incomplete initiatives, when too many things start and nothing finishes; and poor quality, when everything is rushed. When you find yourself short, you have four options and only four. Extend the timeline, which is realistic. Get additional resources, which is sometimes possible. Reduce or pause other work, which is often what is actually necessary. Or accept lower quality and incomplete initiatives, which is the risky one nobody should choose by accident.

Finally, she resisted the urge to race from pilot to scale. She built explicit learning time into Phase 1: pilot the answer-bot with 10 percent of users for six weeks, hold a real retrospective in week 7, then decide whether and how to scale. Skipping that step is how teams scale a tool that has a fundamental flaw nobody has noticed yet. The question to ask of any Phase 1 is what you are genuinely uncertain about and whether this phase will resolve it. If Phase 1 is only executing something you already know how to do, you may have designed around the wrong risk, because the real risk is usually implementation friction, team adoption, or data quality rather than the technology itself. The healthier framing is a hypothesis: "we think this will cut response time by 20 percent, so we are piloting with 10 percent of users for six weeks to find out before we scale."

When dependencies rewrite the plan entirely

Sometimes the dependency map does not just reorder a roadmap, it replaces the first phase completely. Picture a finance and planning organization whose early roadmap drafts wanted everything immediately: build AI forecasting models, automate the close process, and implement predictive budgeting. Each of those carried a dependency that had not been examined. Forecasting models need clean historical data with consistent definitions going back eighteen months or more. Automating the close needs documented procedures, and the procedures were inconsistent across departments. Predictive budgeting needs integration with multiple source systems, and IT was already overloaded.

The honest reality check produced a Phase 1 that contains no glamorous AI work at all. Months 1 to 3 go to standardizing general ledger definitions across every department. Months 2 to 4 go to documenting close procedures and automating the standard ones, which needs good process rather than AI. Months 1 to 6 go to data governance, ensuring there are 24 months of clean historical data. Only after that does Phase 2 begin, with forecasting models from month 7 because the data is finally consistent, and predictive budgeting from month 9 because the integration is finally in place.

To a leadership team impatient for AI, that plan looks slower. It executes faster, because nobody spends Phase 2 fighting bad data and undocumented processes. Being able to explain that trade convincingly is one of the more valuable things a manager can do with a roadmap.

Five ways roadmaps fail

Priya kept a short list of roadmap anti-patterns and checked her draft against it before sharing anything.

The do-everything-immediately roadmap. This is the plan that lists every possible initiative with no sequencing and no regard for capacity: customer support, recommendations, process automation, fraud detection, and hiring, all in the first six months. The team is overwhelmed, nothing is done well, there is no time to learn from early work, and prerequisites go unmet, so you end up with three partly finished projects instead of one finished one. The fix is ruthless prioritization: pick the two or three highest-impact initiatives for Phase 1, do them properly, and plan the rest for Phase 2.

Ignoring resource constraints. This is the roadmap that commits a team already at capacity to five major initiatives. Existing work does not politely pause while you innovate, so something breaks: people burn out, quality suffers, initiatives get too little attention to succeed, and your own credibility takes the hit when committed dates slip. The fix is to state available capacity plainly and put the trade in front of leadership before you sign up for it.

No clear dependencies. This is the roadmap that says "launch AI inventory forecasting in Q2" without noting that it requires clean supplier data from a Q1 cleanup project that is already running late. You reach Q2, the initiative stalls, blame starts circulating about which team missed its date, credibility erodes, and no learning happens at all.

Skipping the learning phase. This is treating Phase 1 as nothing more than a quick win and racing to scale. A pilot goes live in month 3 with ten users, and by month 6 the decision is made to roll out to hundreds, on the basis of three months of thin evidence. You scale a system whose fundamental problems have not surfaced yet, Phase 2 fails expensively, team confidence collapses, and every subsequent initiative meets more resistance. Building an explicit retrospective between pilot and scale feels slower upfront and is faster overall.

Metrics that do not measure anything. "Success is that the team is more productive" cannot be evaluated, which means you cannot tell whether the initiative worked, leadership cannot judge whether to keep investing, you cannot learn what is working, and nobody is accountable. Replace it with something with a number and a source: productivity up 15 percent measured by initiatives completed per person-month, response time down from 4 hours to 2.5 hours measured by ticket timestamps, quality defects down 20 percent measured by defect rate per unit produced.

Keeping the roadmap alive

Priya treats the roadmap as a living document, not a contract carved in stone. Every quarter she asks four questions: are we learning what we expected, have conditions changed, should Phase 2 shift based on what Phase 1 taught us, and does any new information change our priorities? She shares the roadmap openly with her director and the affected team leads, and she listens for the signals: "this is realistic" means she got it right, "this is too slow" or "too fast" means the timeline needs adjusting, "we need X first" means she missed a dependency, "we do not have those people" means she needs to cut scope or extend. A good roadmap evolves as you learn and as conditions change. A bad one is a prison you locked yourself into.

She also planned for what comes after the last phase. From month 19 onward the roadmap does not stop; it changes character. The systems built in the first eighteen months need maintaining and monitoring for both improvements and emerging issues, quarterly learning retrospectives ask what is working and what to adjust, and new initiatives emerge from those learnings rather than being predetermined today. Writing that sustaining phase into the roadmap prevents the common failure where an organization treats month 18 as a finish line and quietly lets everything it built decay.

She also builds responsible-AI work directly into the phases rather than bolting it on. Phase 1 includes a bias check of the historical ticket data and a defined escalation path for when the AI produces a bad answer. She reserves roughly 10 percent of team time for investigating and learning from failures, and she runs blameless retrospectives when something goes wrong so the team surfaces problems early instead of hiding them. The roadmap is, above all, a communication tool: if her director and her engineers understand it and support it, it is working.

Planning the responsible work into the phases

Because responsible AI is easy to promise and easy to defer, Priya made it occupy real space on the roadmap rather than living in a values statement. Phase 1 carries two explicit items alongside the tooling: a bias audit of the data the team intends to use, and team training on responsible AI so that everyone can recognize a fairness problem when they see one. She also wrote a gating dependency into the plan in plain language: before any AI touches real work, bias testing and a fairness assessment have to be complete. Written as a dependency rather than an aspiration, it cannot be quietly skipped when a deadline gets tight.

The roadmap also reserves capacity for things going wrong, which is different from hoping they will not. Beyond the 10 percent of team time set aside for investigating failures, Phase 1 includes actually defining the escalation protocol, meaning who is told, how quickly, and what happens next when the AI produces a bad outcome. Budgeting time for genuine blameless postmortems, rather than a quick round of blame and a return to the backlog, is what turns an incident into an improvement.

Finally, communication is scheduled, not improvised. Priya's roadmap includes regular updates to the team about what is happening, why, and what is coming, and it includes honesty about uncertainty: "we do not know yet whether this will work, which is exactly why we are testing it." Where customers are affected, the roadmap names what changes from their point of view and why. Vague optimism creates cynicism; a manager who says out loud that a phase is an experiment earns the credibility to be believed when she says a later one is a commitment.

Terms worth keeping straight

• Roadmap. A strategic plan showing major initiatives, sequencing across phases, dependencies, and success metrics. Priya's spans eighteen months; many span up to three years.
• Phase. A period of roughly six to twelve months representing a cohesive set of related initiatives and a milestone on the way to the vision.
• Initiative. A discrete body of work with clear objectives, a timeline, and success criteria, such as implementing an AI customer support assistant.
• Dependency. A prerequisite that must be satisfied before an initiative can succeed: data cleaned, team trained, infrastructure in place, stakeholders aligned.
• Quick win. An early initiative with high feasibility and tangible value, chosen deliberately to build team confidence and demonstrate progress.
• Readiness. The organization's actual capability to execute, covering team skills, data quality, infrastructure, and cultural openness.
• Learning phase. A period where an initiative runs at small scale specifically to validate assumptions and surface challenges before full deployment.

Practice and Reflection

Reading a roadmap someone else built is not the same as building one. Set aside an hour and work through these five exercises for your own domain.

Sketch the phase structure. Lay out three phases of roughly six months each, eighteen months in total, that would move your vision forward. Phase 1 is usually foundation plus a quick win plus learning; Phase 2 is usually capability building and expansion; Phase 3 is usually scale and more advanced capability. For each phase, list three or four major initiatives, the dependencies that must be satisfied first, and the success metrics for the phase.

Map the dependencies. Take your top three initiatives and walk backward from each. What data, infrastructure, training, or organizational change has to happen first? How long does each prerequisite realistically take? Given those answers, when can the initiative itself actually start?

Estimate the resources. For Phase 1 only, estimate the people you need and at what skill level and for how long, the budget for tools, training, and outside expertise, and the amount of your own management time this will consume. Compare that against what you genuinely have available. If it does not fit, decide now whether you are cutting scope or extending the timeline.

Define the metrics. For each phase, write two or three success metrics covering three angles: the business outcome, meaning how this moves your objectives; adoption, meaning whether people are actually using it; and quality or reliability, meaning whether it works as intended and what problems are emerging. Then check that you can genuinely measure each one, because a metric you cannot measure tells you nothing about whether you are succeeding.

Tell the story. Write a one-page narrative of your roadmap that begins "over the next eighteen months, here is how we move from where we are to our vision," and covers phases, key initiatives, dependencies, and expected outcomes. Then ask the real test question: could you present this page to your leadership and have them both understand it and back it?

Finally, take two minutes on a smaller reflection. Think about the past week of your work and find one decision, task, or conversation where having a roadmap would have changed what you did. What would you have done differently, and what would the outcome have been? That connection between the concept and your own week is where the learning actually lands.

Related Lessons

A roadmap sits in the middle of a chain of strategy work, so several other lessons connect directly to this one.

• Developing an AI Vision for Your Domain creates the vision your roadmap operationalizes. If your phases feel arbitrary, the usual cause is a vision that was never specific enough to sequence against.
• Measuring AI Impact and ROI defines how you track whether roadmap initiatives are actually delivering the value you promised, turning the milestones in your phases into evidence.
• Communicating AI Strategy Upward uses the roadmap as your primary communication tool with leadership, which is how a document meant for sequencing also becomes a document that buys you time and resources.
• Developing Team and Department Policies matters because policy work belongs on the roadmap itself. Governance and usage policies are often a Phase 1 prerequisite rather than a later nicety.
• Leading AI Transformation supplies the change-management practice around the roadmap, since the roadmap is the structure through which that change is actually managed.

Key Takeaways

• A roadmap operationalizes a vision. The vision says what you are trying to achieve; the roadmap says in what order, with what resources, and managing which dependencies. Without it, capable teams stall.
• Sequence for readiness and learning, not just impact. The most exciting initiative often belongs last, because the data, training, and confidence it needs are exactly what earlier phases produce.
• Prioritize with RICE, not enthusiasm. Multiplying Reach, Impact, and Confidence and dividing by Effort gives one comparable number that exposes when low confidence and high effort sink a beloved idea, and surfaces cheap high-value wins nobody championed.
• Make dependencies explicit. Walk backward from each initiative asking what must be true first; every answer becomes a Phase 1 prerequisite instead of a Phase 2 surprise.
• Run an honest capacity check. Most teams underestimate effort. If the numbers say you can do one initiative, do one well rather than three badly, and make any trade explicit to leadership.
• Build in learning time. Pilot, hold a real retrospective, then decide whether to scale. Racing from pilot to full rollout is how a hidden flaw becomes an expensive one.
• Use measurable milestones. Tie every phase to a specific, dated, business-linked target so you can actually tell whether it worked.
• Keep the roadmap alive. Reassess each quarter, share it openly, fold responsible-AI checks into the phases, and treat it as a communication tool whose job is alignment.