Plenty of engineering roadmaps are backlogs with dates on them. They say what the team will build and roughly when, and never why those things, in that order, move the business forward. When priorities shift, as they will, a roadmap like that falls apart, because nobody can work out from it what to drop.
The engineering leader's job is to translate the company's strategy into technical work the team understands well enough to make good decisions without them in the room. It's one of the most useful things a manager does, and one of the least taught.
Where the translation breaks
Strategy arrives in business language: grow revenue, enter a segment, reduce churn, cut cost. Engineering work is described in the language of systems, such as services, schemas, migrations and latency. Roadmaps tend to fail in the gap between the two, in one of two directions.
Too literal. Leadership says "we need enterprise customers", and the roadmap becomes a checklist of single sign-on, audit logs and role-based access, with no theory of which of them unblocks a deal. The team ships the lot and the sales pipeline barely moves.
Too abstract. The roadmap stays at the level of themes like "improve reliability" or "scale the platform". They sound strategic and give engineers nothing to sequence or say no to.
A useful roadmap sits between the two: specific enough to act on, with enough reasoning attached that it can adapt.
Outcomes before output
The most useful shift is to frame the roadmap around outcomes, the change you want in the world, instead of output, the thing you'll build. "Ship the new billing service" is output. "Halve involuntary churn from failed card payments" is an outcome. The outcome defines success, and it lets the team find a cheaper route than the one you first pictured. Retrying failed charges on a better schedule might get most of the way without a new service at all.
For each strategic goal, ask what would have to become true for it to succeed. Those conditions organise the roadmap, and the features follow from them. When reality changes, you re-derive the features from the conditions instead of defending the old list.
The idea has limits. Some work is legitimately output-shaped, such as a contractual deliverable or a compliance requirement. And an outcome the team has no way to influence is a wish.
Name the trade-offs
A roadmap is a sequence of bets, and each one costs something. Say what.
- What you're not doing. Richard Rumelt's Good Strategy Bad Strategy (2011) describes good strategy as a diagnosis, a guiding policy and a set of coherent actions, and counts a long list of goals with no choice between them among the marks of bad strategy. Write down what is deferred and why. A roadmap's non-goals are often its most informative section.
- What speed costs. If you're optimising for a launch date, say which scope or quality you're trading for it. If you're putting a quarter into platform work, say which features it displaces.
- How reversible each bet is. Jeff Bezos's distinction, from Amazon's 2015 letter to shareholders, between one-way doors (expensive to undo) and two-way doors (cheap to undo) tells you where to spend your deliberation. Move quickly through the second kind and slow down for the first.
Every item needs a reason
To check the translation, pick any item on the roadmap and ask an engineer why it's there. If the answer is "because it's on the roadmap", the translation failed. A good answer ties the work to an outcome and a trade-off: "it unblocks the enterprise deals in the pipeline, and we chose it over the reporting work because three of those deals are waiting on single sign-on."
That reasoning is what lets a team correct course on its own. When a customer escalation or a competitor's launch changes the picture, engineers who know why the work is there can reorder it sensibly instead of waiting to be told.
Where this sits in the standard
Translating business goals into technical direction is competency SV-1, engineering strategy, in the Strategy & Vision domain of the EMA Competency Framework. The SV-1 unit of the Body of Knowledge covers outcomes, Rumelt's kernel and writing the strategy down. The SV-3 unit on roadmapping covers the balance between feature work and platform investment that every roadmap has to strike.