Your Roadmap Has an Assumption Limit

Most roadmaps contain more uncertainty than the teams delivering them can reasonably absorb. The problem is not uncertainty itself. Product work will always involve bets. The problem is allowing one initiative to depend on five uncertain things all becoming true at the same time.

This is becoming more visible in AI products. A team may assume that customers want an agent to complete a task, that they will grant it access to sensitive systems, that the model will perform reliably, that usage costs will remain acceptable and that enough capacity will be available when demand arrives. Each assumption can sound reasonable in isolation. Together, they make the roadmap item much less credible.

Recent developments make the pattern hard to ignore. AI services are restricting access when demand outgrows available capacity. Companies are competing for training data as if it is a core supply constraint. Agents are asking for access to calendars, inboxes and payment methods while security incidents keep reminding customers what that access can cost them. At the same time, model capabilities can be copied, distilled or overtaken faster than most annual planning cycles.

Yet many roadmaps still represent an initiative as one neat bar across a quarter.

I think every roadmap has an assumption limit. A team can investigate several unknowns, but it cannot responsibly scale an initiative while all of them remain unresolved. Beyond a certain point, the roadmap is no longer a plan. It is a collection of dependencies disguised as confidence.

I have seen the same issue outside AI. Consider a company launching a new self-service purchasing flow. The business case may depend on customers understanding the offer without help, accepting a new pricing structure, completing implementation themselves and generating fewer support requests. If conversion disappoints, the team will struggle to identify which assumption failed. Worse, it may optimise the interface while the real issue is pricing or implementation complexity.

The solution is not a larger risk register. Those tend to become administrative documents that acknowledge uncertainty without changing the order of the work. The roadmap itself should show how uncertainty will be reduced.

For the purchasing flow, I would first test whether customers understand and accept the offer in a manually supported process. If they do, I would test whether implementation can be completed with limited assistance. Only then would I invest heavily in automating the full journey. This sequence may look slower than building the complete flow immediately. In practice, it avoids spending a quarter learning that several unresolved problems have been bundled into one release.

The same logic applies to an AI agent. Before committing to broad integration work, establish whether customers will delegate the task at all. Before forecasting attractive margins, observe real usage patterns and their cost. Before promising autonomy, determine where customers require approval. These are different questions and should not be hidden inside one delivery milestone.

This also changes how I discuss roadmap confidence with stakeholders. I do not want teams labelling an item high confidence because engineering knows how to build it. Technical feasibility is only one assumption. Demand, behaviour, economics, access and operational support can each invalidate the outcome while the software works exactly as designed.

Product leaders should therefore ask a simple question during planning: how many important things must be true for this initiative to succeed? If the answer is long, the initiative needs sequencing before it needs staffing.

A good roadmap does not remove uncertainty. It prevents the organisation from multiplying uncertainty faster than it can learn.