Field Note
Roadmaps are capital allocation

A technology roadmap is a capital allocation decision wearing a product-management costume. There, I said it.
It decides where money, executive attention, engineering capacity, vendor leverage, and organizational patience will go. The feature boxes are the visible part. The opportunity cost is the strategy.
Capacity is not interchangeable
Roadmaps often treat capacity as a generic pool. Put enough points or dollars behind an item and it moves.
Real organizations have specific constraints. The integration team may be the bottleneck. Security review may take longer than implementation. The only person who understands the pricing model may already be committed to another program. A vendor may release on its own schedule. Operations may have no room for another process change this quarter.
So two initiatives with the same estimated cost can create very different pressure on the organization.
A useful roadmap shows the constrained capabilities, not just the total effort.
Maintenance is already on the roadmap
Every system has work that does not appear in the strategy deck: upgrades, incidents, certificate changes, vendor deprecations, production support, data repair, and the slow accumulation of exceptions.
That work consumes capacity whether leadership funds it explicitly or not.
When a roadmap allocates one hundred percent of the team to new initiatives, it has not eliminated maintenance. It has decided that maintenance will interrupt the plan unpredictably.
The same problem appears with technical debt. A broad “pay down debt” line is hard to defend because it has no business consequence attached. Tie the work to release speed, incident risk, vendor end-of-life, support cost, or a capability the debt blocks.
Debt is easier to prioritize when it stops being a moral complaint from engineering.
Name what each item buys
For every meaningful roadmap item, I want a plain answer to four questions:
- What becomes possible?
- What risk or cost changes?
- What must the organization do differently?
- What are we not doing because we chose this?
The fourth question tends to improve the first three.
“Implement a new CMS” is an activity. “Let the content team launch and localize campaign pages without a storefront release” is an operating capability. The second version can be measured and compared with other uses of capital.
It also exposes whether the platform purchase is sufficient. Sometimes the technology is the easy part and the content operating model is the investment nobody scoped.
Avoid paying for the transition twice
Roadmaps get expensive when near-term work is planned without regard for the target architecture.
A company may fund a major implementation on a storefront it expects to replace, build integrations directly into a platform scheduled for retirement, or customize a temporary process until it becomes too expensive to remove.
Some temporary work is necessary. The business still has to operate during a transformation. The decision should be explicit: how much of this investment survives, how much is thrown away, and what risk are we buying down in exchange?
Temporary architecture is not automatically bad. Accidental temporary architecture is.
Revisit the economic assumptions
A roadmap should change when its assumptions change.
If a platform roadmap shifts, a vendor price increases, AI reduces the cost of a workstream, or a pilot disproves an integration approach, the sequence should be reconsidered. Continuing because the boxes were approved six months ago is not discipline. It is avoiding the decision.
This does not mean reorganizing the roadmap every week. It means naming the assumptions important enough to trigger a review.
The roadmap is the decision record
A credible roadmap shows what leadership believes is worth funding, in what order, and why. It should make tradeoffs visible enough that somebody can disagree with them.
If everything is priority one, the real allocation is happening through escalation, interruption, and whoever has the loudest meeting.
That is still a roadmap. It is just one nobody was brave enough to write down.