A winding road (CC BY-NC-ND 2.0
Massimo Marino)

Roadmap-related conversations exploded on various social media channels a few weeks ago. Jared Spool put up a post on Medium about a concept he learned from Bruce McCarthy – basing roadmaps on themes rather than features. (Although product managers have known this concept for a long time.) And Marty Cagan responded to the Jared Spool post with one of his own. Of course, product managers have written about roadmaps – and been on the ground making roadmaps – for a long time.

But a question on the PMHQ Slack channel piqued my interest most particularly. Someone asked: “What do you use for roadmapping?” The questioner turned out to be someone from outside the high tech/software space. She wondered how we managed our roadmaps in high tech and software.

I used the question as the springboard for a riff on the PM HQ chat board.

My attitude toward “roadmaps” and “roadmapping” for products is perhaps iconoclastic. And apparently idiosyncratic. But I hope the following practical advice will help you navigate the quicksand of roadmaps. Especially when you have to share with people external to the product organization.

What Is A Roadmap?

A common question when PMs get together is “what do you use for roadmapping?” This question can mean lots of things, but usually it means one of two:

1. How do you manage the list of features that you expect your developers to work on over the next period?
2. How do you present the list of features you are developing to outside stakeholders? Such as executives, other internal organizations, customers, or analysts.

Personally, I usually call #1 “the plan” rather than the roadmap.

If I’m going to share a roadmap with anyone other than dev, I make it in PowerPoint. I never want to put a) real or b) all the information in something I’m sharing externally. Not even to other people in the company, normally.

By “real” I mean “with all warts exposed.” For example, our internal plans use insider technical terms. Those depend on understanding our technology (not just the product). I don’t want to require or expect my stakeholders to make that leap.

I always sanitize what gets shared with others. And then I also move it “up a level” – or four.

When presenting a roadmap externally, I always show themes or “epics,” rather than features. I often present them as happening over a time period different from their actual schedule. If there interesting interim releases, I might show those as well.

There are quite a few constraints when putting these epics onto the roadmap. Usually I want them to be one or two words, maybe three. They need to be in non-technical language, and not domain specific. Often one box or epic on the roadmap will represent many “epics” or “features” or “chunks of value.” In our real plan, they are on their own schedules. Sometimes I separate out features that are part of the same epic because they help me tell a better story. For example, if I’m presenting to a customer who requested a specific feature, I might highlight it.

And if possible I don’t even give people that roadmap, the cleaned up one, I only present it to them. (This is often not possible.)

For example, my team’s current feature is “Staffing Requests Phase 4 – Replan/Route-To enhancements.” It’s an epic. But while it’s a meaningful name for the product org, it’s a terrible name to expose to outsiders. It would raise many more questions than it answered. So, for a customer, it’s called “Resource Management” or “Centralized Staffing.” And as such it’s combined with some other related epics that I also don’t mention. This combination of epics is a theme.

I also often will prune things off the roadmap for particular audiences. For example, if I know they don’t want some capability, I might not mention it. Or if I’m worried they’ll think it’s distracting us from their favorite thing. Or, to emphasize they are not our only customer, I might highlight a feature they don’t care about.

Roadmap Tools

There are many tools that position themselves as “roadmap tools” for product managers. Usually these are really about the first meaning I listed above – “the plan.” They aren’t oriented to “how do I present what I’m working on to stakeholders.”

In my ideal product management tool, I could make a roadmap I could actually share with stakeholders. It would start by supporting “public names” for features and themes. It would have the ability to buffer the expected delivery dates. I could edit, annotate, or hide any entries I wished. And it would put all that into a PowerPoint slide that I could load into a deck and update in real time. This is not a trivial set of things to support.

Software Is Different

The original question was from a software industry outsider. I thought it would be useful to compare software roadmaps with those of other industries. The first takeaway? Comparing a software company’s roadmap to a roadmap from another industry is apples to oranges.

Usually those other types of companies have products that obey the laws of physics, such as semiconductor makers or car manufacturers.

Conversely, software company roadmaps often present capabilities that are not even designed, much less built.

Here’s a thought experiment for you. How soon before they hit the showroom do carmakers release information about the features and capabilities of their next car models? It’s about a year if you think about it. How long does it take to get a new car feature that’s designed and developed for manufacturing to the showroom floor? The answer: about a year. When carmakers announce new features on cars, what they call their roadmap, they’ve already done all the design and development work on those features. They are not predicting the future.

How about semiconductors? Intel has a 1-2 year roadmap for its processors. How long does it take for a new semiconductor fabrication innovation to get from discovery and validation in the lab to being an actual feature on a chip that you can buy? Well, it’s about three years. Intel’s two-year roadmap is not predicting the future – they know and have proven the technology.

And even then the roadmap slips. Back in May of 2015, Intel said it would ship 10nm chips in calendar 2015. By July its roadmap had changed, with the 10nm chips pushed back to 2016.

Take action

Here are three things you can do today to improve the roadmaps you share with external people.

1. Focus your roadmap on themes, not features.
2. Use customer language in your roadmap, not technical or insider jargon.
3. Make sure you understand the desires, needs, requests, and pains of the stakeholders to whom you are presenting, so you can fit your presentation to their expectations.

How do you use roadmaps?

Do you have techniques for sharing the future for your external stakeholders? Do you have stories about how you finessed a difficult situation? Or have you accidentally set their expectations that you would deliver something impossible?