Fordel StudiosEvery quarter, the product team produces a roadmap. The roadmap contains the features that will ship this quarter and the ones that are "coming soon." The engineering team estimates the features. The estimates are wrong. The quarter ends with 60% of the committed features shipped and 100% confidence that the 40% that slipped were not the ones users needed most. The cycle repeats.
Nobody asks whether the roadmap was the right one. They ask why engineering cannot hit the plan.
What a Roadmap Actually Is
A roadmap is a structured representation of whose priorities won the internal negotiation. Sales wants the enterprise feature that will close the deal they have been chasing for six months. Customer success wants the quality of life improvements that would reduce their support load. The CEO wants the strategic bet that will differentiate the product in two years. Marketing wants the announcement features. Engineering wants to address the technical debt that is slowing everything down. The roadmap is what happens when these competing interests are resolved, usually by whoever has the most political capital rather than the clearest user evidence.
This is not a pathology. Competing stakeholder needs are real. The problem is when the roadmap is presented as "what users need" rather than "what we decided to build given the constraints we are operating under." The pretense that the roadmap reflects user research produces plans that cannot be challenged when user research says something different, because the plan is already the user research.
“A roadmap that cannot be changed by new evidence is not a plan. It is a political outcome that found some evidence to dress itself in.”
Engineering's Relationship to the Roadmap
Engineers often have the clearest view of which roadmap items are the right priority and which are the most important ones that were excluded. They see the support tickets. They hear the feedback in the bug reports. They understand which features are masking underlying stability problems that will eventually cause a larger failure than any single missed feature.
Most engineering teams have been trained to receive the roadmap rather than challenge it. The product manager sets priorities. Engineering executes. This division of responsibility made sense when engineering was purely about implementation. It makes much less sense in a world where the engineering team has direct access to user behaviour data, support tickets, and the performance metrics that reveal what users actually do versus what they say they want.
What Honest Roadmapping Looks Like
Separate the commitment layer from the intention layer. The commitment layer contains what will definitely ship this quarter: the features with approved designs, capacity-verified estimates, and no known blockers. The intention layer contains what the team intends to address but might not, depending on what is learned. This is honest. It is also much harder to defend to stakeholders who treat every roadmap item as a promise.
The organisations that do roadmapping well have stakeholders who understand that the roadmap is their best current view of the right priorities, subject to change as they learn. Building this understanding is a leadership task, not a process task. Someone senior has to repeatedly make the case that learning and adapting is a sign of intelligence, not of poor planning. Until that is the cultural norm, the roadmap will remain a negotiation document disguised as a plan.