Every roadmap we are handed contains roughly twice as much work as the team can deliver in the time available. This is not a planning failure. It is what happens when a roadmap is assembled by collecting requests rather than by making choices.
Why roadmaps inflate
A roadmap grows because saying no is expensive and saying later is free. Nobody has to defend a item sitting in Q4. So the list accumulates, and by the time it is presented, every function can point at something of theirs on it. That is precisely what makes it useless: a plan everyone agrees with is a plan nobody has argued about.
The exclusions are the deliverable
When we run a definition phase, the artefact people remember is not the prioritised list. It is the second list — the one headed not doing, and why. That list is where the actual decisions live, and it is the one that gets quoted back to us eighteen months later.
A roadmap that contains everything is not a roadmap. It is a wish list with dates on it.
How to cut without guessing
Cutting well requires two numbers per item: effort, estimated by the people who will build it, and impact, modelled against a metric the business already reports on. Neither number needs to be precise. They need to be consistent enough to sort by.
Once every item carries both, the conversation stops being about whose idea is better and starts being about which quadrant something falls into. Most roadmaps have a long tail of high-effort, low-impact items that survive purely because nobody has ever put them side by side with the alternatives.
What it feels like
Uncomfortable, briefly. Then substantially calmer. Teams that cut properly stop context-switching, ship the remaining items faster than forecast, and — this is the part that surprises people — usually deliver more total value than the version of the plan that contained twice as much.