The Nearsighted Roadmap

Roadmaps allow us to set clear goals of where we want to be in the future, but we are terrible at accurate estimates. Here I discuss a near-sighted roadmap that accounts for terrible estimations, yet allows you to see what is coming.

Avoiding long-term roadmaps

At GitLab, we have avoided any long-term roadmaps. Rather, we have established a vision and iterated towards that in releases planned no more than two months out. That works well, but has two downsides. First, we can’t commit to shipping something at a particular time. It’s either the coming release or “some time in the future”. Second, it makes us susceptible to distractions. Quick wins are likely to be prioritized over long-term investments, as it’s hard to evaluate the impact that this has in the future.

A larger vision is important, but so are intermediate steps or things we simply don’t want to do now, but have to do before we realise our larger vision. At GitLab, we ended up creating a “Coming soon” category.

Introducing the near-sighted roadmap

A near-sighted roadmap is worked out for the near future and is progressively less precise the further out into the future. To be able to deal with concrete issues both in the present and the future, this means that the scheduling of future issues is less precise, not necessarily their content.

It’s preferable that scheduled items further away are bigger things. If you’re near-sighted, you’re less able to see small objects the further they are away. The same should go for planning, so that you’re not just moving things into the future, but rather focusing only on big things in the future. This will prevent you from future discounting.

The content of big things should be respectful of when they are planned to happen. I mentioned that big things that are far away shouldn’t necessarily be imprecise, but take note that the further something is away, the more likely it is subject to change. In particular items that have a high dependence on other things are likely to be disrupted and should be kept vague until closer in time.

The nearsighted roadmap should be driven by a vision. The vision worked out into concrete items.

Implementation

The easiest way to implement the nearsighted roadmap is to create labels or milestones through which you move the individual items. You can create one for the next months, the next quarter and one for the half year after that.

For instance, for a project with a monthly cadence (like GitLab), one could create milestones for the concrete releases (Jan, Feb) and labels for the future after that. For instance, Next for the three months following the milestones that exist, and After for the six milestones beyond that.

After shipping January, the March milestone is created from issues with the Next and so on.

In the coming weeks, I’ll be rolling out an example of the nearsighted roadmap at GitLab. I’d love to hear your answer your questions and hear your comments. You can find me here or on Twitter.