The AI roadmap: how to unify feature requests and GenAI initiatives in one plan
Marc GasserSerial Founder · GTM & MarketingConnects AI with revenue operations and builds autonomous GTM systems for predictable growth.TL;DR
- AI initiatives don't belong in the same lane as classic features: they carry research risk. Run a two-lane roadmap – a delivery lane with commitments, an experiment lane with bets and kill criteria.
- In July 2024 Gartner predicted that at least 30 per cent of GenAI projects would be abandoned after proof of concept – over data quality, risk controls, cost or unclear business value. Exactly those four points belong in your roadmap as gate criteria.
- Prioritise with RICE (reach, impact, confidence, effort, by Intercom) – but take effort and risk from code reality instead of gut feeling. In brownfield, the existing code decides what counts as a “small” feature.
Key findings
- Roadmaps fail at AI because they treat experiments like delivery commitments. A model that never gets good enough isn't a delay – it's a research result and needs a kill criterion.
- RICE remains the most reliable prioritisation framework for mixed roadmaps – if confidence is set honestly. AI bets rarely start above 60 per cent.
- Outcome phrasing (“halve support response time”) holds up better under AI uncertainty than feature promises (“chatbot in Q3”), because it leaves the solution path open.
Why classic roadmaps fail at AI
A classic software roadmap lives on one assumption: what is planned can be built. For AI features that doesn't hold. Whether a model reaches the required quality is something you only know after trying – effort and result are only loosely coupled. If you schedule an AI feature like a normal feature with a release date, you promise something you don't control.
The data shows how expensive this mistake is. In July 2024 Gartner predicted that at least 30 per cent of GenAI projects would be abandoned after proof of concept – over poor data quality, inadequate risk controls, escalating costs or unclear business value. That is not an indictment of AI but of planning without gates: each of those four reasons could have been checked before the engineering investment.
How to unify features and AI bets in one roadmap
Lane 1: delivery. Classic features, integrations, tech debt. Commitments, capacity planning and the usual delivery discipline apply here. This lane carries the core business and must not be cannibalised by AI experiments.
Lane 2: bets. AI initiatives run as time-boxed bets with three mandatory fields: a success metric (how do we recognise quality?), a budget cap (how much experimentation can we afford?) and a kill criterion (when do we stop?). A bet that passes its gate moves into the delivery lane – only then does it get a date.
For ordering within both lanes, RICE remains the most reliable tool: reach times impact times confidence, divided by effort – a framework Intercom developed for its own product planning. With AI the trick lies in confidence: a bet without a validated data basis starts at 50 to 60 per cent, not 80. Set confidence honestly and you see immediately why a small, safe improvement often ranks ahead of the big AI moonshot.
RICE calculator: prioritise your next AI feature
A solid candidate for next quarter. Check the confidence: what is the cheapest validation before you commit engineering?
Move the sliders for reach, impact, confidence and effort – the score shows whether the feature belongs on the roadmap.
How to check the roadmap against code reality
The effort part of RICE is the biggest source of error in brownfield. Whether “AI summary in the ticket” costs three weeks or three months is decided not by the feature but by the existing code: data flows, legacy integrations, permission logic. This is exactly where code intelligence helps – estimating effort, risk and affected components against the real code instead of the memory of your longest-serving engineer.
Communicate the roadmap externally as outcomes rather than a feature list: “halve support response time” stays true whether the solution ends up being a RAG assistant or a better knowledge base. Feature promises (“chatbot in Q3”) force you to stick with a solution the experiment may refute. Outcomes give you the right to change the path without breaking the promise.
Recommendations
- Separate commitments from bets. Two lanes on one roadmap: delivery with dates, experiments with a success metric, budget cap and kill criterion. No AI initiative without those three fields.
- Set confidence honestly. Unvalidated AI bets start at 50 to 60 per cent. If confidence doesn't rise after a prototype, that is your kill signal.
- Estimate effort against the code. Before any prioritisation: pull affected components, dependencies and regression risk from the codebase. The gap between gut feeling and code reality is often a factor of three.
- Promise outcomes, not features. To C-level and customers the result counts, not the solution path. That way your roadmap survives even a failed experiment.
Scope & caveats
- The Gartner figure (at least 30 per cent abandoned after proof of concept by end of 2025) is a July 2024 prediction, not a measurement of your portfolio. Use it as a warning signal for missing gates, not a law of nature.
- RICE is an ordering tool, not an oracle: the scores are only as good as the estimates behind them. Treat the score as a basis for team discussion, not an automatic decision.
The takeaway
An AI roadmap is not a list of promises but a portfolio of commitments and bets – with gates in between. Pull effort and risk from code reality, promise outcomes instead of features, and you plan fast while staying credible.
Matching use cases from the library
From the article straight into practice: these use cases put the concepts to work with Teklens.
No new piece without you.
New articles, new interactive tools, new evidence – in your inbox first. And when you reply, we reply: you write directly with the authors, not with a no-reply.
No spam, no sharing, unsubscribe any time.