Why the best roadmaps are team-oriented

There are many ways to build a roadmap, and some are better than others. I'm a firm believer in creating a timeline. Our stakeholders want to know when they can expect that feature, so without a timeline, roadmaps are not actionable. The first step most companies need to take to go from backlog-as-wishlist to an actionable roadmap is visualizing their work over time.

But even on a timeline, there are a few ways of non-ideal road mapping.

Gantt chart

Historically, Gantt charts have been the go-to tool for visualizing work over time. The X axis is time, and the Y axis represents work items. They are powerful in a project setting. But contemporary SaaS teams don't run projects– they build products. And shuffling around backlog items on a Gantt chart is not very productive. Managing a prioritized backlog in a Gantt chart tool is a horrible experience. No wonder we stopped doing that.

Horizontal backlog

The easiest product-style way of roadmapping is the horizontal backlog. Backlog items are prioritized and estimated. So, instead of visualizing the backlog as a list, I sometimes see teams visualize it on a timeline. The first item is estimated to take four days, so the first four days of the timeline are known. It's a simple approach that runs into its limitations very soon. Since there is only one path, every work item is on the critical path by definition. When one item starts slipping, there is a domino effect that messes up the plan.

Sprint mapping

Another, more common, approach is called Sprint Mapping. Jira tickets are assigned to sprints, and since we know how long each sprint takes, it's trivial to map this on a timeline. Feature X will be built in sprint 45. The drawbacks of this common approach are clear. We are horrible at estimating, and carrying over Jira tickets to the next sprint is more common than nailing the sprint commitment. Sprint mapping is where Scrum gets its bad name. A sprint map tells us how much time we'll burn over time. It says nothing about what will be delivered.

Product-oriented roadmaps

Sometimes, companies have a roadmap per product. That feels clean. Here is what we'll add to the mobile app in the coming year. The problem with this approach is, of course, that it leads to conflicting priorities. If there's a roadmap for the mobile app and one for the web platform, what should the engineers work on first? A roadmap per product is optimized for easy creation but is terrible for productivity. It passes the buck to the engineers.

Customer-oriented roadmaps

Another common approach is creating a roadmap for each customer or stakeholder. Here is what we'll build for Customer X in the coming year. It's the exact same issue as product-oriented, but on top of that, it makes clear promises to customers. And with conflicting priorities, there is a guarantee we can't keep those promises.

Team-oriented roadmaps

The single best way to visualize the timeline is to use teams as swimlanes. The X axis is time, and the Y axis represents the teams. Every team has a clear overview of its focus blocks, and leadership has a clear overview of what their teams will focus on. Teams are the best way to scale the organization because they allow a company to multitask without having conflicting priorities.

Actionable roadmaps should be team-based.