The classic AI roadmap failure is not missing a deadline, it is the roadmap itself: a Gantt chart that pretends model quality, data reality and user adoption are plannable like construction milestones. Then the pilot works, everyone celebrates, and the project dies anyway, because nobody planned the unglamorous bridge from a working demo to a monitored production system that real users trust. A useful AI roadmap is built differently: phases that end in decision gates rather than dates, an explicit pilot-to-production phase with its own budget, and pre-agreed rules for when to re-scope and when to kill. This article gives you that structure, with a miniature example.
Why most AI roadmaps fail on contact with reality
AI roadmaps fail in characteristic ways, and almost all of them trace back to treating a learning process like a construction plan.
| Failure | What it looks like | Root cause |
|---|---|---|
| Date-driven fiction | "Model live in Q3" promised before anyone has seen the data | Certainty planned where information does not exist yet |
| The eternal pilot | Demo works for a year; nothing is in production | No planned bridge phase, no budget for integration and operations |
| Gate-free drift | Project continues by default every quarter | No pre-agreed criteria for go / re-scope / kill |
| Static staffing | Same three people from exploration to operations | Phase-specific skill needs ignored in the plan |
| Zero-salvage kills | Cancelled project leaves nothing behind | Phases not designed to produce standalone value |
The phase structure, with realistic gates
Five phases cover the path from idea to operated system. The durations are typical ranges for a focused mid-size project, illustrative, not promises, and each gate is a real decision, not a status meeting.
| Phase | Typical duration | Key output | Gate question |
|---|---|---|---|
| 1. Framing | 1-2 weeks | One-page brief: problem, metric, data hypothesis, constraints | Is there a measurable problem worth a pilot budget? |
| 2. Data exploration & feasibility | 3-6 weeks | Data report, baseline model, achievable-quality estimate | Does the data support the target metric at acceptable cost? |
| 3. Pilot | 6-12 weeks | Working system on live data with a defined user group, measured against the brief's metric | Did the metric move enough to justify production cost? |
| 4. Productionization (the bridge) | 8-16 weeks | Integrated, monitored, rollback-safe system; trained users; operations handbook | Is the system reliable and adopted enough for full rollout? |
| 5. Operations & scaling | ongoing | Monitored quality, retraining cadence, next-use-case backlog | Quarterly: keep, extend, or retire? |
The pilot-to-production bridge nobody plans
Phase 4 is where AI projects actually die, precisely because it looks like a formality after a successful pilot. It is not: it is regular, hard engineering work, and it routinely costs as much as or more than the pilot itself. Plan these items explicitly, each with an owner and budget line.
- 1Integration into the real workflow: the pilot ran beside the process; production runs inside it, which means touching the systems people actually use (ERP, CRM, ticketing) and their owners' backlogs.
- 2Monitoring and alerting on model quality, not just uptime: a rolling labeled sample or proxy metric, thresholds, and a named person who gets paged.
- 3Fallbacks and degradation paths: what happens, per workflow step, when the model is unavailable or below threshold, and who decided that is acceptable.
- 4Human oversight and escalation design: who reviews what, at which confidence levels, and how their corrections flow back as training signal.
- 5User rollout and trust-building: training, a feedback channel, and an explicit adoption metric, a technically perfect system that users route around has failed.
- 6Compliance and documentation completion: model documentation, logging, and (where applicable) EU AI Act duties finished before rollout, not retrofitted after.
Resourcing per phase: the team changes shape
One fixed team across all phases either starves the early phases with process or the late phases with missing engineering muscle. Typical shapes, with the caveat that small projects consolidate roles into people rather than headcount.
| Phase | Core roles | Typical loading |
|---|---|---|
| Framing | Product owner, senior AI/data lead, key domain expert | Part-time, workshop-driven |
| Exploration | Senior data scientist/ML engineer, data engineer, domain expert on call | 1-2 FTE, senior-heavy |
| Pilot | ML engineer, data engineer, product owner, pilot user group | 2-3 FTE plus committed user time |
| Productionization | ML/backend engineers, MLOps/platform, QA, integration owners of touched systems | 3-5 FTE, engineering-heavy |
| Operations | Named system owner, on-call rotation, fractional data science for retraining | 0.5-1.5 FTE steady state |
When to re-scope, when to kill
Gates only work if the decision rules exist before the gate. Agree these at kickoff and write them into the roadmap document itself.
- 1Re-scope when the problem is real but the target is wrong: the metric moves, just not enough, and a narrower scope (fewer categories, one segment, human-in-the-loop instead of full automation) plausibly clears the bar.
- 2Re-scope when data supports a neighboring use case better than the planned one, the exploration report should say so explicitly.
- 3Kill when the ceiling is structural: achievable quality after honest exploration sits below the minimum the business case needs, and more modeling effort attacks noise, not signal.
- 4Kill when the metric owner is gone: if no stakeholder still wants the number moved, the project is organizationally dead regardless of technical health.
- 5Apply the two-re-scope rule: a project re-scoped twice without clearing a gate is a kill candidate by default, and the burden of proof flips to continuation.
- 6Harvest every kill: archive the data pipeline, the eval set and the findings report as reusable assets, and record the kill reason where the next team will find it.
A miniature example roadmap
An illustrative, condensed roadmap for the fictional returns-categorization project from our brief template article, showing gates and re-scope thinking in practice.
| Phase | Weeks | Gate decision (planned) |
|---|---|---|
| Framing | 1-2 | Brief approved; metric: categorization lag 6 weeks to under 1 day at >= 90% accuracy |
| Exploration | 3-7 | Baseline reaches 84% on the 10k labeled rows; gate says: proceed, but budget a labeling sprint to 25k rows |
| Pilot | 8-17 | 91% accuracy on live data with 2 category managers; purchasing confirms usefulness; go for production |
| Productionization | 18-30 | ERP integration, weekly quality sample, fallback to manual queue below 85% confidence; DPO sign-off |
| Operations | 31+ | Data-team lead owns; quarterly review; candidate follow-up: supplier-quality signals from the same pipeline |
