Tame Your Roadmap

67 Flares 67 Flares ×

Your role as a product manager means you’re putting a lot of thought in to the long term vision of your product. We all know that, counting up all of the minute details you’ve got your finger on that you know will need to be accomplished along the way, getting this all into one page in the form of a roadmap will simply not be easy.

Too often, a roadmap becomes a tangled mess of blocks, arrows, notations, and scribbles. When fully digested and understood, sure, it might accurately depict where you’re taking the product, but it generally looks plain scary or incomprehensible to the rest of your company.

In order to keep your roadmap under control, remember its purpose: Your roadmap is supposed to be a visual representation of your long-term strategy.

It’s equally important to remember what it’s not: It’s not a Gantt chart, or a detailed release plan. It’s not a promise of delivery, or a depiction of user numbers or revenue.

Instead, it’s a high level look at how your product strategy will align itself with the business strategy and help the rest of the business meet objectives.

Choose the right format

The format of a roadmap is loosely defined – and that means you can shape it to suit your own needs. This might be as simple as a table within a Word document with a list of items within each column, representing the expected delivery for each quarter. It might also be complex, detailed out in a heavily formatted Excel sheet.

When I started off in product management, my first roadmap was simple, and over time, I developed it into a much more functional version that allows me to update quickly. I’m happy to share copies of a roadmap template I’ve created and iterated on using Excel.

Get the right level of detail
The roadmap shouldn’t include every feature you plan on releasing along the way. When it boils down to it, you’re putting a feature into the mix because it makes up a larger piece of the puzzle. Assuming you’ve got your priorities in line, those large pieces should make up a series of blocks that represent a business objective or a strategic goal.

Resist the urge to cram every feature into it, even for the short-term representation.

Make it visual
Break your roadmap up into streams or sections so that it’s clear which areas are setting out to achieve various business objectives or cater to various key users.

Use symbols or colours to depict associations or statuses. Make use of various shapes to outline a flow, or introduce dotted lines to insinuate uncertainty. This doesn’t need to be (and shouldn’t be!) complicated, but should aid the presentation of the items on the roadmap as a whole.

Finally, don’t be afraid to toss it out and start fresh when an old format doesn’t suit your current needs.

Update:
Since writing this article, I’ve gone on to really tackle this. I’ve paired up with Simon Cast to build a product roadmap tool called ProdPad. It allows you to gather ideas from your team, flesh them out into specs, outline your products and your product lines, and put it all on to a product roadmap.

Best of all, it also has packages that will fit your company, whether you’re a startup or whether you’re part of a huge team with a big product portfolio. Have a look at our Plans and Prices.

, , , ,

  • http://twitter.com/sjors Sjors Timmer

    I often wonder if the roadmap is the right metaphor, and if working with levels of abstraction  (that you should validate) wouldn’t be a better idea

    for example:
    10 years: connecting graduates and companies seamlessly
    3 years: establish a community of enthousiast english, spanish and german students and the majority of  the ftse 500 companies
    1 year: an easy to set up, maintain and flexible platform that enables british students to connect with 20 british companies
    3 months: a strong presents on facebook and 50.000 members
    1 month: sign up process streamlined.

    Don’t you think that a roadmap of actual features becomes pretty much useless (and even dangerous) for a schedule further than 6 months ahead? 

    By using abstractions you create flexibility for the dev and design team to come up with the best solution available at the time of implementing and you’re not forcing them to live up to some idea that you had a year ago when things were different. Whilst still being able to validate if you are actually on the right track to meet your vision and your target

    • Anonymous

      Nice point Sjors. 

      I think your example is really a list of objectives, on a log scale. But then a whole pile of work is needed to reach those objectives e.g. 3 months: a strong presence on facebook and 50,000 members.  A developer or a designer can’t achieve that on their own. This is where I think a roadmap comes in:

      Given an objective, what are the components required to get there? This usually breaks across multiple disciplines (dev, design, marketing) and somebody needs to ensure that the separate disciplines are a) going to reach the same finish line together b) still aligned with hitting the subsequent objective and c) that the subsequent objective is still valid.

      So I think you can use a roadmap to help here but the objective should always be clear to dev/design teams as being given a list of specific features on their own obfuscates the underlying problem and makes it hard for team members to present better solutions or design for the longer-term.

      • http://svirsk.org Sjors

        Ok, let’s split my comment in two:
        1. I think Janna shared an amazing roadmap that is certainly very useful for planning up to 6 months ahead.

        2. Maybe my opinion is slightly skewed by working at a startup, but all the features that were meant to be build 6 months from the creation of the roadmap never saw the light of day and were always replaced by projects that turned out to be much more urgent. 
        If you can predict that ahead, that how can you still plan for after 6 months? should you put them on the same roadmap but use more abstract descriptions? Should your roadmap take a log scale after nine months? How do you guys deal with that?

        • http://www.erikssons.net Martin Eriksson

          As shiny as Janna’s template is I never roadmap in a calendar format. You run into two issues.

          1) You will inevitably over promise and under deliver as no software project has ever, ever, come in on time.

          2) You get more locked in to the roadmap and don’t allow for the responsiveness Sjors mentions above – where a new idea comes in as the top priority 2 months down the line. Sure you can move everything in your roadmap but it gets a bit complex and dare I say gannt charty..

          I instead focus on using backlogs at two levels of abstraction – one for the dev backlog with all the stories, bugs etc in it and one high level project backlog which forces you to prioritise every project relatively – and allows for change by inserting that new idea in the middle when necessary. This also makes the prioritisation discussion easier as you just have to push back and ask if this new shiny idea really is more important than the next thing on the backlog…

          • http://twitter.com/productnotes Steve McDonald

            Hi Martin
            I’m glad we’re grappling this topic.  On numerous occasions I’ve discussed the pros and cons of having a calendar format roadmap with other PMs where I work.  What I provide really does depend on the audience, and whether the team will be help over a barrel with the dates!

            I don’t suppose you have an example template of your two types of backlogs?

          • Jason Lorch

            Yes, templates please! : )

          • http://twitter.com/productnotes Steve McDonald

            Hi Martin
            I’m glad we’re grappling this topic.  On numerous occasions I’ve discussed the pros and cons of having a calendar format roadmap with other PMs where I work.  What I provide really does depend on the audience, and whether the team will be help over a barrel with the dates!

            I don’t suppose you have an example template of your two types of backlogs?

          • http://twitter.com/d8a_driven Bruce McCarthy

            I keep two lists as well. The published roadmap consists of high level themes like “improve checkout experience” and “help customers find things.” Many individual features can fit into those efforts and, if we do even a few of them, we can claim victory and on-time delivery. This roadmap is very simple. It’s a table of quarterly objectives.

            To manage project priorities, though, like Martin, I have a backlog of items associated with each theme/release. These are prioritized and we get to as many of them as we can in the time box.

          • http://www.prodpad.com/ Janna Bastow

            I’m really glad these points were raised! It was these comments (and everything else we learned from talking to awesome product managers) that led us to revamp how the ProdPad product roadmaps were structured.

            @dd00ef6e4d45ec6809f822691480e727:disqus to your point, we now have such templates baked right into our product roadmap tool.

            Thanks @Sjors:disqus, @smcllns:disqus and @bfgmartin:disqus for your feedback!

        • FrederickSanford

          100% agree. This man speaks the truth. Only the government should be making promises it can’t keep

    • Vanessa

      That sounds like a good idea to me. How would you change the template then?

  • http://twitter.com/sjors Sjors Timmer

    I often wonder if the roadmap is the right metaphor, and if working with levels of abstraction  (that you should validate) wouldn’t be a better idea

    for example:
    10 years: connecting graduates and companies seamlessly
    3 years: establish a community of enthousiast english, spanish and german students and the majority of  the ftse 500 companies
    1 year: an easy to set up, maintain and flexible platform that enables british students to connect with 20 british companies
    3 months: a strong presents on facebook and 50.000 members
    1 month: sign up process streamlined.

    Don’t you think that a roadmap of actual features becomes pretty much useless (and even dangerous) for a schedule further than 6 months ahead? 

    By using abstractions you create flexibility for the dev and design team to come up with the best solution available at the time of implementing and you’re not forcing them to live up to some idea that you had a year ago when things were different. Whilst still being able to validate if you are actually on the right track to meet your vision and your target

  • Fridge

    Hi.
    Random one sorry – the Excel template seems to be corrupted in some way. Had anyone else struggled to download it?

    • Normand

      Hi Fridge, once downloaded, right-click the Excel file, select properties and then click on “Unblock”. You should be able to open it.

      • LIMBOURG

        Hi, I only get xml files in the download, no Excel.

        • Awena

          I had the same problem. FIX: After you’ve download the file, try changing extension from ZIP to XLSX.

          • ritu

            Does anyone have an updated version of the excel template? Janna mentioned that she updated it.

          • Esquire

            I got the impression she ‘updated’ it by creating her own product that you can buy. :)

  • FashionJewelryForEveryone.com

    Love this article, got this forward by the QA Manager in our company. Downloaded the Template it is great, will forward the same to the PM on our project.

  • Bryan Chapman

    Thank you so much for sharing your Excel template. What a fabulous resource.

Limited spaces left, don't miss out on the product conference of the year!Get your tickets now!
67 Flares Twitter 13 Facebook 13 LinkedIn 36 Google+ 5 67 Flares ×