Business Savvy Software

For a long time, we had a two dimensional roadmap – ie a list 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 its 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?
Its quite likely that there will be some competing goals here – maybe its to open up new markets, or maybe its to innovate in your existing market. You may need to focus on one goal, or a few, but its important to first understand your goals so that you can measure the impact of each project and make sure its getting you 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 prioritize the projects with high impact, low difficulties first, then the high/med and med/low projects etc.

Communicate the roadmap based on the goals
Its 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)

Roadmap template

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 comments.