Real-Time Roadmaps: from the illusion of control to risk-based reality

An introduction to a different kind of roadmap — one built on probability rather than false certainty, and drawn from the work you are already doing.

Every organisation has a version of the same meeting. Once a quarter, a roomful of capable people spends a day or two producing a roadmap: a tidy grid with time along the top, initiatives down the side and a confident bar for each one. It looks authoritative; it was made with a specialist tool or presented as a PowerPoint slide. Someone presents it to leadership, who all nod.

And almost everyone in that room (when asked privately, and promised discretion) would admit they do not quite believe it. They have seen this before. Within a few weeks, reality will have drifted from the grid; within a few months, the two will have almost nothing to do with one another. The roadmap will not be corrected. It will simply stop being mentioned until the next planning cycle produces a fresh one: equally detailed, equally authoritative, equally doomed.

This article is about what you give people instead. Not a better planned roadmap, a different instrument altogether. I call it the Real-Time Roadmap. Its most surprising feature is that you are probably most of the way to having one already.

Why the familiar roadmap lies

The timeline roadmap descends from the Gantt chart. That was a tool for a different era; built for work that is repeatable, predictable and fixed in sequence. For manufacturing, construction or work done so often before, the duration of each step is known from records. For that work, a bar chart is not a lie; it is a faithful picture of a future you can foresee, because you have lived it many times.

Product development fails all three tests. It is not repeatable — if a feature had been built before in exactly this form, you would copy it, not build it. It is not predictable — you cannot have reliable records for something never done. And it is not fixed in sequence — you often learn the right order only once you are moving, when the work, or a customer, tells you the thing scheduled for Q3 should not be built at all.

While the traditional roadmap is a good tool, it’s been forced into service in a world it was never designed for.

The damage shows up in two ways. The grid is organised around features and dates rather than problems and outcomes. It commits to building particular things long before anyone knows they are the right ones. It also asserts certainty: a bar in a quarter is a promise about a future that a product manager confidently says will happen.

Think of a printed itinerary versus a live navigation app. The timeline roadmap is the printed itinerary that says you will arrive at 5:12 p.m. It’s reassuring, precise and useful right until the first traffic jam, after which it is worse than useless. Not because having a plan wasn’t good, but because it keeps announcing a time that will not happen and offers no way to adjust. What you want, once you are on the road, is the thing that watches the traffic, reroutes around the jam and revises its estimate as it learns.

Probabilistic, not deterministic

Underneath the grid sits a belief worth naming, because everything that follows argues against it. Call it the deterministic mindset: the assumption that the future of a piece of work has a single, knowable outcome, and that planning means writing that one path down accurately.

It assumes the work will be the size you thought, that nothing more urgent will arrive, that the team’s pace will hold and that today’s priorities will still be right in three months. None of those assumptions is bad. Each is simply, reliably, false.

The honest picture is different. The future of a feature is not one outcome; it is a range, some outcomes likelier than others. It might land on the 4th, the 11th, or — if three things go wrong — the 25th. A single date picks one point out of that range and presents it as though the others did not exist. It is a forecast with its uncertainty deleted.

So the honest answer to “when will it be done?” is never a single date. It is a date with a probability: “we are about 85% likely to be done by the 18th, almost certain by the 25th.” We accept this everywhere else. No serious weather forecaster says “it will rain tomorrow”; they say “70% chance,” and you decide whether to carry an umbrella. We read probability without panic in almost every domain — except, oddly, in our roadmaps, where we still demand one confident number and then act wounded when reality declines to comply.

That shift, from a deterministic mindset to a probabilistic one that acknowledges variability and states it honestly, is the foundation on which the Real-Time Roadmap is built.

A short tour of flow

To build a roadmap on probability, you need a few instruments that many product organisations do not yet use. They come from a body of practice called flow. If the vocabulary is new, here is the minimum you need to know. If you want more, read the Kanban Guide or the Kanban Pocket Guide.

Flow is the steady, even movement of work through a system to a customer. The word people hear is “fast”; the word that matters is “even.” A motorway can have a high average speed and still be miserable, because it surges and stalls — and it can move at a steady, unspectacular pace and get everyone home on time. Good flow is the second kind. It is not haste but steadiness, and steadiness is what lets you make promises you can keep.

Now look at your board — the items started and not yet finished. Not a to-do list: each item costs something to start, and costs more for every day it sits there unfinished. It is a portfolio of live bets, each running up a bill while you wait to see how it turns out. A handful of plain measurements make it legible. We call these flow metrics, and there are four of them:

1. Work in progress (WIP) is the number of items started but not finished — a powerful measure, because it is the one you can change directly. A general insight from Little’s Law says that the more you have on the go at once, the longer each takes: attention is finite, and split across twenty items, each crawls. Therefore, the most counter-intuitive instruction in flow, and the most reliable, when you are in trouble, is to stop starting and start finishing.
2. Throughput is how many items you finish per unit of time. Throughput is the exact count of work items. This is the flow metric you need to forecast multiple items using a Monte Carlo Simulation (see below)
3. Cycle Time is the elapsed time between when a work item started and when a work item finished. This is the flow metric you need to forecast single items using an SLE (see below). Both Throughput and Cycle Time are facts about your own past, which makes them precious: they describe how your system genuinely behaves, not how you hope it will.
4. Work Item Age is the elapsed time between when a work item started and the current date. This is the quiet hero. Cycle Time is known only once something is finished — a postmortem on money already spent. Age ticks upward in real time on the work in front of you now. It’s the one signal you can act on while there is still something to do. An item aged far past where your work usually finishes is not just old; it is almost certainly in trouble, and the age is the alarm.

A few more useful definitions: A Service Level Expectation (SLE) derived from Cycle Times turns that history into an honest forecast for a single item: “85% of our work finishes within 20 days or less.” Note the probability and the range — a confidence level and a span of time. A time without a confidence level is just a wish.

Monte Carlo simulation is a mathematical technique used to model the probability of different outcomes in a process with inherent uncertainty. Instead of guessing a single fixed value, it uses computational algorithms to run thousands of random trials, generating a full spectrum of possible results and their likelihoods. Past data and performance are used to model possible future outcomes.

How the roadmap evolved

The Real-Time Roadmap is an evolution of things you are probably already doing.

The Gantt chart or grid we have already condemned: features as bars, each pinned to a quarter, asserting certainty about the unknown. Its two fatal properties — organised around features and dates, and certain about a future that is not — are exactly what the later steps exist to fix.

The evolution was the Now / Next / Later roadmap. The first real improvement was to throw the dates away. In 2012, Janna Bastow and Simon Cast, the British founders of the product tool ProdPad, replaced the grid of quarters with three horizons: what we are working on now, what is likely next, and what may come later. Its genius is in admitting that certainty decreases with distance. “Now” can be specific; “later” is deliberately vague, because you know little about the distant future and should stop pretending otherwise. And the columns are framed around problems and outcomes, not features with dates. It is a genuine leap, and for many teams it is enough. A big gap remains: it still does not answer “when?” with any rigour.

Your Kanban board is your roadmap

This next step is the move that changes everything. It is so simple it is easy to miss: your Kanban board is a roadmap already. It is a form of the Now / Next / Later roadmap. The items in progress are your “now.” The items ready to be pulled next are your “next.” The backlog behind them is your “later.”

The board is organised by exactly those horizons — but with a decisive advantage. It is not a separate artefact that drifts from reality, because it is reality. Nobody maintains it by hand; it updates itself as the work moves. Why keep a map alongside the territory when the territory can be read as the map?

Stakeholders will probably object immediately: a board is too granular — leadership does not want forty tickets, they want the shape of the year. Fair enough. But the answer is not to retreat to the Gantt chart. Rather, the board-as-roadmap is read at different altitudes by different people. A team reads individual items. A product leader reads a higher level — features, epics and outcomes, fed by the same flow data underneath. An executive reads a handful of big bets (you may call these initiatives or themes) with live forecasts and risk colours. Same roadmap all the way up, zoomed to the right resolution for the audience. The grid tried to serve everyone with one watered-down artefact and served no one; this serves each audience the same truth at the detail they need.

The evolution is to build your Real-Time Roadmap by layering on the tools defined earlier. If you run a flow system, you have already built every one. Add the workflow stages, and the roadmap shows not just what is in flight but how far along each thing is. Add WIP control, and it becomes honest about capacity: it can only show as much “now” as you can actually do at once, forcing the prioritisation a grid lets you dodge. Add your SLEs and continuous Monte Carlo forecasts, and it answers “when?”. Not with a fixed date but with a live probability for every item and feature, updating itself as the work moves.

Where genuine fixed dates exist — a regulatory deadline, a launch, a contractual commitment — lay the forecast against them for a live, traffic-light view: green where the forecast comfortably beats the date, amber where it is tight, red where the data says you will miss. In real-time, you are giving people insight into risk and the ability, with time, to act.

That is the Real-Time Roadmap: your board. Add in stages, WIP control, SLEs and forecasts if that helps you. It’s more insight as a single living object showing what you are doing, how far along it is, when it is likely to be done and where the risks are. All from real data, all updating itself. It is everything the timeline grid pretended to be and never was. And because it is the work, not a picture of the work, it cannot drift out of date.

Make it concrete. Picture a team building single sign-on for enterprise customers — letting people log in through their own company’s identity provider.

On the old roadmap, “enterprise SSO” was one bar in Q3, asserting a date nobody believed. On the Real-Time Roadmap, it is a small cluster of thin slices: a couple already shipped and live; one in progress, showing amber against the date sales have been quietly promising, because it has stalled on a security review that never appeared on anyone’s board. Two more in “next”; and the ambitious admin console is still in “later,” deliberately vague. A stakeholder sees at a glance what has shipped, what is moving now, what the live forecast says about the part with a real deadline, and what is uncommitted because it is too far off to pin down. No bar, no false date — just the actual work, its actual state, and an honest “when” for the parts that have one.

The roadmap that tells the truth about your priorities

The deepest payoff is not about dates at all. It is political, and it is where the Real-Time Roadmap really shines.

A traditional roadmap shows stated priorities — the order that leadership agreed on in the planning room. The Real-Time Roadmap reveals priorities — what the organisation is actually spending its capacity on right now. The two are often startlingly different.

Everyone has lived it: the roadmap says the top priority is the big strategic initiative, while the board shows most of the team’s capacity going to interruptions, urgent fixes and pushed-in work that appears on no roadmap anywhere. The plan and the real work have diverged, and only the board knows. This is uncomfortable — and the discomfort is the entire value, because you cannot manage a misallocation you cannot see. The Real-Time Roadmap drags the true allocation of your most precious resource, your people’s attention, into the light, where it can be discussed honestly.

While a traditional roadmap lets everyone keep believing the plan, the Real-Time Roadmap makes everyone confront reality. The second conversation is harder, though infinitely more useful.

Deciding at the last responsible moment

Because the roadmap is live and the forecasts are continuous, you no longer need to fix the whole order of work months ahead. You decide what to pull next at the moment you have the capacity to start it , which is the moment you know the most, having learned everything the work has taught you so far. Deciding later is not indecision; it is deciding with more information. The traditional roadmap forced you to commit to the distant future when you knew least. The Real-Time Roadmap lets you commit each thing at the last responsible moment, when you know most.

A discipline goes with this. Most teams let the small-and-urgent consume the day — the way unguarded meetings expand to fill a calendar — and then find no room left for the handful of bets that actually move the business. Reserve capacity for the important few first and let the small work settle around them. The Real-Time Roadmap is the first instrument that lets you see, in live data, whether the important things are getting the room they need or being quietly buried.

Reforecasting is not a failure

One last point, because it is the one most likely to trouble stakeholders. A probabilistic forecast changes as new data arrives. The forecast you give today will not be the one you give in two weeks. Mainly because at that time, two weeks of finished items will have flowed through. Your Throughput data will have new and potentially different data to model from. To a mind raised on fixed plans, this looks like failure: “you said the 18th, now you say the 25th — you got it wrong.”

It is not a failure. It is the forecast working as it should. Your navigation app revises its arrival time as the traffic changes, and you do not accuse it of lying — you are grateful it is keeping up. A forecast that never moved would be the suspicious one: it would mean you were ignoring everything you had learned. So reforecast often, and frame the changes for what they are — not broken promises. It is the honest narrowing of uncertainty as the work reveals itself. A forecast is a living estimate, not a promise carved in stone.

You are probably already most of the way there

The Real-Time Roadmap does not abolish the roadmap. It evolves it — through evolving a Now / Next / Later, through reading the board as the map, and finally by using the instruments of flow. It aims to tell the truth: what you are doing, how far along it is, when it is likely to land and crucially, where the risk sits.

It answers the question every stakeholder has always asked — when will it be done? — but honestly, as a probability. In doing so, it escapes the trap the traditional roadmap never could: it stops spending the organisation’s trust faster than it builds it.

And the best part is the one we began with: you are probably most of the way there already. You have a board. You almost certainly have a history of finished work, whether or not you have looked at it as data. Reading the one through the other is the whole move. You do not need a beautiful lie about the future. You can have a useful truth about it instead.

‍