For a long time, we had a two dimensional roadmap – ie. a list of features and some release dates. It was quite hard to communicate any dependencies and how projects were prioritised so there was a general feeling that we were just rolling out one feature after the other.
A roadmap is really only useful if you know your destination, otherwise it’s just a bunch of ordered features, so the first question to ask is:
What is the destination that this roadmap takes our company/product to?
It’s quite likely there will be some competing goals here – maybe it’s to open up new markets, or maybe it’s to innovate in your existing market. You may need to focus on one goal, or a few, but it’s important to first understand your goals so that you can measure the impact of each project and make sure you’re getting closer to the destination.
The next question to ask is:
What’s the quickest route to the destination?
This is what roadmaps are all about – knowing your destination and planning how to get there most efficiently.
Once you understand the goals, then get your stakeholders in a room and chuck ideas up on a whiteboard. Rank each as high/medium/low impact – based on how close they get you to your goals. Then rank each as high/medium/low difficulty – based on how long they will take to deliver.
The high impact, low difficulty projects are a no-brainer
Now you can start to plan the roadmap against your goals. There will be dependencies between features and SDP (software delivery platform) projects needed to support customers, operations, billing etc – but you can prioritise the projects with high impact, low difficulties first, then the high/med and med/low projects etc.
Communicate the roadmap based on the goals
It’s good to keep your goals in front of everyone and show what goal each project is working towards. The roadmap below shows goals as ‘swim-lanes’, with release milestones marked along the top. Some people like to give each release a code-name – I like to give it a theme, which sets people’s expectations about what’s in the release (ie: yes – hooking up the twitter API is a great idea, we’ll look at it in the networking release).
This has become quite an effective template for visually communicating priorities between projects, how our roadmap is meeting our goals and how there are dependencies from release to release and between product and SDP.
If you’d like to have a play with your own roadmap, download this roadmap template for Microsoft Visio and fill in the blanks. Let me know how you get on via the comments section below.