How to create realistic engineering roadmaps

In my last post I argued that long-term roadmaps quietly drag down engineering productivity. The case there was largely subtractive: the further out you plan, the more the plan deceives you and the people relying on it.

However, to stop planning entirely is not a serious answer. Engineering organizations need some sense of direction because finance needs to forecast hiring, sales needs to know what they can promise, and finally, customers would like to know upcoming features. So, let’s ask the following question instead: How do we design a roadmap that’s honest about the future?

Most long-term roadmaps fail. They provide the same level of confidence and details for a six week plan as a six months plan. They refuse to admit that the second plan is more likely to be wrong although they look uniform. That uniform appearance is the illusion of certainty.

Often, engineering leaders argue that you need better estimation. However, we’re not going to estimate our way out of a problem that's fundamentally about communication. To fix this, we should make the uncertainty visible by putting it on paper and communicating this with all stakeholders.

Why your roadmap looks like a weather forecast that only says "sunny"

Weather forecasters have an interesting relationship with uncertainty. When you check their forecasts, it tells you there’s a 70% chance of rain on Tuesday and scattered showers possible next week. The further out the prediction, the more probabilistic language they use. Nobody finds this confusing. Nobody complains that the meteorologist is hedging. We accept that long-range forecasts are less certain than short-range ones because the forecasters tell us so.

Engineering roadmaps almost never do this although they should communicate more uncertainty the further you plan features. Steve McConnell described this nearly three decades ago as the "cone of uncertainty." Early in a project, estimates can be off by a factor of four in either direction. That cone narrows as the work progresses. Most roadmaps are drawn as if the cone doesn't exist, as if everything were already in the narrow end.

Obviously, stakeholders react to what they see. When a roadmap presents Q4 with the same visual confidence as Q1, executives plan accordingly. So, how can we solve this?

Three horizons, three confidence levels

Let’s first stop pretending that all parts of the roadmap deserve the same treatment. Split it into tiers, and let each tier carry a different level of detail and confidence. Here’s a tiered approach that works well to communicate confidence levels for different time horizons.

Tier 1: The next 4 to 6 weeks (high confidence, ~80–90%)

Specific work items, named owners, real dates. This is the tier where commitments belong. The reason commitments work here is that the feedback loops are short. If something is going to slip in the next month, you'll know within two weeks and can adjust. The work has been broken down enough that the unknowns are small and stakeholders can rely on it. 

Tier 2: The current quarter (medium confidence, ~50–70%)

Let’s focus on outcomes, not features. For example, "Reduce onboarding drop-off" rather than "Build the new welcome flow with the checklist component." Instead of focusing on a solution, start focusing on a problem. In tier 2, some of these problems will be solved, but some might take longer to solve or won’t be solved. Publish these problems as a set of bets, not a delivery schedule.

Tier 3: Six months and beyond (low confidence, ~20–40%)

Let’s focus on direction, not destination. For example, “We believe enterprise customers will need stronger audit and compliance tooling" or "We expect the platform team to invest heavily in cost reduction next year." These are hypotheses about where the world is going, framed so that everyone (engineers, executives, sales) knows they're hypotheses. Anything more specific than this is called planning theater.

In summary, the tiers serve different audiences and answer different questions. 

• Tier 1: “What are we doing right now and when will it be done?" 

• Tier 2: “What problems are we trying to move on?" 

• Tier 3: “Where are we heading?" 

If you try to only use tier 1 to answer all roadmap questions, you end up again with the false-certainty problem. 

Use probability ranges, not point estimates

With the tiers in place, the next move is borrowing from people who forecast for a living.

Daniel Kahneman and Dan Lovallo wrote about reference class forecasting: the best predictor of how a project will go is how similar projects have gone before. If your team's last three big features each took around five months, the three-month plan for the next one might be too ambitious.

Troy Magennis and Vasco Duarte have been arguing for years that probabilistic forecasting based on historical throughput beats deterministic estimation based on story points. The Monte Carlo approach is mechanically simple: take how many tickets your team has actually closed per week over the last quarter, simulate the next quarter ten thousand times using that distribution, and report the result as "80% chance of finishing between March 1 and April 15." The math is easy but the cultural change is much harder.

By approaching planning like a forecaster, we can change our message from "ship X by March 15" to "we are highly confident that we ship feature X between March 1st and April 1st." This message allows stakeholders to plan accordingly and keep in mind some buffer time. This changes your planning from a fixed date being the truth, to a date range being the truth.

What changes when the roadmap stops pretending

The interesting effects of confidence-tiered roadmaps aren't really about planning. They're about how people behave around this new type of planning.

The first thing that changes is the questions stakeholders ask. When you have a Q3 item listed at 40% confidence, an executive’s question changes from “are you on track?” to “what would shift this item from 40% to 80% confidence?” That’s a whole different conversation, one that’s much more productive than trying to find something or someone to blame for a delay.

The second effect is counterintuitive: trust goes up instead of down. There's a fear among managers that admitting uncertainty will affect team confidence. The opposite happens. Stakeholders who've been burned by overconfident roadmaps before learn quickly that calibrated predictions are more valuable than confident-sounding ones. After two quarters of "yeah, that 80% item shipped on time, the 40% item slipped two months as expected," you've earned a kind of credibility that no amount of polished Gantt charts can buy.

The third effect is harder. Some leadership cultures genuinely don't want this. They want the comfort of clear commitments, even though the commitments are fictional. Unfortunately, moving to a confidence-tiered roadmap system can require political work like explaining why the new format is more honest. Not every organization is ready, but framing it carefully helps: false certainty doesn't reduce risk, it just transfers risk from the people making the predictions to the people relying on them.

The point isn't less planning. It's honest planning.

Confidence-tiered roadmaps don't mean planning less. When you implement this correctly, it might mean more planning. It’s important to plan the right amount of detail for each horizon. Each time you complete a sprint, you start adding more details to tier 2 items, moving them to tier 1. It also means you can start shaping tier 3 items based on what you’ve learned building a new feature in the current sprint that shapes the direction of a tier 3 problem. Therefore, a team’s planning load can increase but it becomes a lot more predictable.

Yet, moving to a tiered-planning system is mostly cultural. The mechanics are easy: three sections, different levels of detail, and explicit confidence ranges. What's hard is convincing an organization that has been trained on confident-looking roadmaps that calibrated predictions are more valuable than confident ones. The organizations that figure this out stop burning quarter after quarter on the gap between what their roadmap promised and what was actually possible to know.

In short, your roadmap shouldn’t be a contract, but it should become a forecast.

Want to learn more about managing software projects? Check out Pluralsight's Managing Software Projects learning path. It dives into the details of building project plans and running software projects with more clarity, less stress, and greater confidence.