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

The Dark Knight, 2008

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

  1. They are jumbled compromises that don’t usually reflect a strategic product vision.
  2. They are inaccurate, usually optimistic sometimes by 1000%.
  3. Often things on the roadmap never get accomplished
  4. The audience is unclear and contradictory
  5. Naming is all over the place
  6. 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.

  1. Only 3 months long
  2. Have a row for every single developer
  3. Do it in a spreadsheet (not a fancy tool)
  4. Audience is internal team only
  5. Naming should be short. Don’t just tack 2.0 on the end of words.
  6. Update every 2-4 weeks
  7. 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.

Marketo 2009
2011 Marketo
2017 Engagio

This last one was fun because I could animate the bubbles to the left with each quarter that went by. It was meant for external consumption.

Maybe I focus too much on having fun. Maybe not. Your call.


One response to “Roadmaps”

  1. Amy Guarino Avatar
    Amy Guarino

    Glen — Great memories from the roadmaps. Thanks for sharing.

Whatya think?

%d bloggers like this: