Product Roadmaps
As the end of the year approaches quickly, some PM’s are going to be trying to creating roadmaps for upper management. It’s a fact of life, and sometimes it can’t be helped for whatever the circumstance. Ideally, you have a roadmap process you’ve been using throughout the year and nothing really changes for you.
I’ve got a pretty good method and format for creating these things now. After being bit in the ass one too many times, and really seeing how roadmaps can hurt organizations AND help them, I’ve found myself creating two types of roadmap: the internal and external. Before getting into the details of each of these, I’ll cover some general things.
I always prefer laying roadmaps out quarter by quarter. This is a broad view, and really defines that the roadmap is by no means a release plan. Release / iteration plans are derived from the content on the roadmap itself, so it can be more on the side of high-level.
The second major thing for me is, they change. Roadmaps are a critical part of the process, not the end result of some huge, year-long planning effort. They are liquid, and meant to be reviewed regularly. Obviously, if you have weekly management or product meetings, they aren’t coming out and getting changed that often…
Lastly is alignment. A great roadmap must be aligned from top-down. The business vision and objectives must be taken into account, along with all market data that has been gathered, and any new innovation steps the company feels is necessary to move the product and business forward by leaps and bounds.
The Internal
Essentially, this is for upper management, development, and maybe some members of the board, depending on their level of involvement and how comfortable the CEO is with providing this level of detail.
Creating this is relatively easy. Simply take a big block of the four quarters and put big squares in where the releases will (approximately) be. This will all be wrong, so just get it done. When you first start developing roadmaps, they really aren’t going to be right. They won’t probably be right even 6-8 months in, so you are much better off just getting the content down.
After you map out your release blocks throughout the year, check to ensure nothing looks wildly out of whack. Are you attempting to do 3 major releases in a single quarter, for example? Maybe 8 minor releases in a month? The reverse may also be true, depending on your situation - trying to do 1 minor release very other quarter, for example. These are all bad news, and indicate the roadmap should be re-evaluated.
After you have this down, for the internal version only, you’ll want to bullet out as many features (maybe all features) you have planned for each release blocked within the quarter columns. Remember, this isn’t a release plan or a requirements document so you can be more high-level. You really just want to offer a view of, “these are the features coming up.”
Remember, each feature you mark down will usually need more justification than, “I think it’s really neat!”
The External
On the external view of the roadmap, you want to stick to themes. No specific features really get mentioned within this stream - just prose-like descriptions of the releases you have mapped out. This affords you with the flexibility to send a roadmap out to Sales - it may even work work for board-level presentations.
The goal with this type of roadmap is to offer folks talking points and broad timelines about what the product will shape up to be throughout the year. It provides a great view, without going into detailed feature sets, about what “themes” you are looking to inject into the product(s).
