Who is the roadmap for?
The roadmap has an almost mythical status in software development. It is seen as the domain of the visionaries or a source of great evil, depending on who gets to influence it.
Its definition ranges from a typical Gantt chart to the post-modern Now/Next/Later format that pretends time and scope don't matter.
So, what is a roadmap? Or better: who is it for?
The roadmap originates in traditional project management. Back then, the project manager maintained a Microsoft Project file containing The Big Plan. The problem with such an overly detailed Gantt chart is that it's only valuable for the PM. Developers didn't care for The Big Plan. They cared about individual work items and received a Use Case or requirements document. These documents were written specifically for them.
Stakeholders didn't care for The Big Plan either. It was just TMI. Their product vision got clouded by low-level work items that meant little to them. "Why are we adding AspectJ to the Service Layer? How does that increase sales?"
Project managers would present a helicopter view of The Big Plan as part of the status report. This roadmap was at the highest level containing only top-level nodes of the Work Breakdown Structure. These were the outcomes the stakeholder cared about. The roadmap was a Gantt chart with milestones aimed squarely at the project's stakeholders.
Use Cases for the engineers, roadmaps for the stakeholders.
Simple.
And then Scrum happened, and planning went the way of the dodo.
We moved from The Big Plan to feedback-driven product increments and raised the bar for software development. It's hard to overstate the boost our industry got from the agile software development movement.
Yet the 2000s also saw the rise of an anti-management sentiment in our field. We started estimating in Story Points to obfuscate planning. Teams refused to slap a date on anything. Prioritization became the only acceptable tool.
That meant a significant shift for stakeholders: they lost their helicopter view. While they always kept some kind of roadmap, it was usually out of touch with reality. Instead, they got to look at Burndown Charts designed to sidestep all the questions they cared about. No progress reporting, no milestones, no "on schedule".
Simultaneously, our industry got a lot more complicated. Back in the day, the stakeholders were those that paid for the project. It was that straightforward.
These days, our environment isn't that simple. We no longer build pure projects; we build products. We've got constellations of self-organizing Engineering teams. We've got Product Managers and user research. Customer Success is an ever-louder voice. Our stakeholders have gotten a lot more heterogeneous.
And yet, one thing remains the same: they still want that helicopter view. They are still the roadmap's target audience.
I feel a lot of the online discussions around roadmaps have gotten purely academic.
We seem to like making things overly vague, theoretical, and complicated.
We talk about "strategy" and "outcomes". We'll throw around expensive words like "Possibility space". We deconstruct a straightforward communication tool into pointless technobabble.
Meanwhile, our stakeholders just want to know when they can get that thing they care about.
I'd love it if our industry embraced the straightforward roadmap once again: A tool for communicating the state and vision of our software development to our stakeholders. An answer to their When questions.
We need that kind of straightforward communication.