An architecture roadmap covering three years is invalidated within six months by a change in product direction. How should roadmaps be built under uncertainty?
Show the full answer Hide the answer
The reframing
A roadmap under uncertainty is a sequence of options, not a plan. The purpose is not to predict what will be built; it is to ensure that whatever is built next is not blocked by something that should have been done earlier.
How to build it
1. Separate the near and the far explicitly. The next two quarters are commitments with dates. Beyond that, directions with triggers rather than dates. Presenting three years at uniform confidence is what makes a roadmap wrong and, worse, believed.
2. Sequence by dependency and by enabling value. Observability before optimisation. Contract testing before service decomposition. Deployment automation before increasing deployment frequency. Enabling work first, even though it has no direct benefit, because teams that sequence by visible benefit find every subsequent improvement harder than it needed to be.
3. Prioritise work that preserves optionality. Investments that make several futures cheaper — a clean interface, a decoupled data store, a migration capability — are robust to direction changes. Investments that only pay off in one specific future are bets, and should be labelled as such.
4. Attach triggers, not dates, to the far items. "We move rendering to an asynchronous path when any output type exceeds N seconds at p95." A trigger survives a change in direction; a date does not.
5. Note the irreversible decisions. Data model, tenancy, identity, shard key. These get more expensive with delay, so they belong earlier than their apparent urgency suggests — and a roadmap that defers them because nothing is forcing them yet is storing a much larger cost.
What a direction change should and should not invalidate
Should invalidate: work specific to the abandoned direction.
Should not invalidate: enabling capabilities, decoupling, observability, deployment safety, migration tooling. If a product change invalidates most of the architecture roadmap, the roadmap was a set of bets rather than a set of capabilities — and that is the finding worth acting on.
The maintenance practice
Review on trigger, not on calendar. A quarterly review that shuffles the same items is theatre; a review prompted by a direction change, a threshold being crossed, or an assumption expiring is a decision point.