Roadmaps

Roadmaps are funny things. In my cynical experience, their whole purpose is to make people feel confident that things will go according to plan.

This might be controversial, but in my experience roadmaps are deeply flawed documents. Here is a partial list of some of the common problems:

They are jumbled compromises that don’t usually reflect a strategic product vision.
They are inaccurate, usually optimistic sometimes by 1000%.
Often things on the roadmap never get accomplished
The audience is unclear and contradictory
Naming is all over the place
Updates are irregular and poorly communicated

Despite my cynicism, I think roadmaps can serve an important function. I like to think about product development like a chess match. There are pieces on the board and you are playing against your competition. Sometimes, you will want to sacrifice a piece (feature or market or price) in order to gain advantage on a more important piece.

Over the past 10-15 years I have grown to prefer a different approach to roadmaps. Here is a short list of what I think is better.

Only 3 months long
Have a row for every single developer
Do it in a spreadsheet (not a fancy tool)
Audience is internal team only
Naming should be short. Don’t just tack 2.0 on the end of words.
Update every 2-4 weeks
Have fun release names

#7 is a personal one. I liked naming releases even if they were short. At Marketo we used Elements. Hydrogen, Helium. (In order) It was useful for figuring out when we would release functionality, but also it was amusing to have periodic tables on the walls. At Engagio, I used underwater creature names. Anchovy, Betafish, Crab, Dolphin. (One per letter A-Z) Again, it was fun and it helped conversations.

Roadmaps can help teams plan their next few months. A marketing team can schedule a webinar. Docs and QA can prepare for the upcoming functionality. Design teams can think ahead.

I know there are external roadmaps that are useful for analysts and investors. These should be other documents that focus on that one audience. Trying to have one roadmap that solves everyone’s problems is never going to happen.

Alignment is the key principle that roadmaps are supposed to solve. They shouldn’t be a locked in a concrete document that can not be changed. It is supposed to be a framework to get people talking about decisions and their implications. Disagreements often happen when working on these. (See post about disagreements) Many organizations have roadmaps, but not that many use them on a daily or weekly basis to guide their decision making.

Here are a few roadmaps I found lying around.