Ask A Good Product Manager

Your product management questions answered

Are there any product roadmap best practice tools?

Posted on June 12, 2008 · 9 Comments

Question: What are good product roadmap tools?

Do you have suggestions for “best practice” product roadmap tools or literature for technology organizations attempting to develop product road maps with a business focus?

Answer from Ivan Chalif of The Productologist:
Whether you are planning a business- or consumer-focused product, the product roadmap process is basically the same–plotting features and/or releases on a timeline. Product Management tools that help PM’s collect, analyze, and prioritize features (Accept, Accompa, FeaturePlan, FocalPoint, and others) can be very useful and they usually provide a way to produce a product roadmap document, either as an export or in a report view. While tools like these are designed specifically to make it easier to create/manage products, I have found that the tools which you already use on a daily basis, like Microsoft’s Office suite (or whatever word processing/spreadsheet/presentation software you use) work just fine for creating product roadmaps, too.

Product roadmaps typically serve two purposes. First, the roadmap is a tool for the Product Manager or Product Management team to use to map out the product strategy over the course of the next few months or years. The roadmap keeps everyone on the same page and provides a wide-angle view of both features/defect fixes and the release schedule.

The product roadmap can also be used as a mechanism for communicating the product strategy or release schedule (more on the difference between those two later) to other business functions or even customers and prospects. There are many opportunities to share the product roadmap with folks inside and outside of the company and providing a glimpse into the strategy and/or schedule can help guide discussions about hiring, resource planning, and strategic alliances.

Let’s look at the second use first. When communicating with other departments, the executive team, or external folks, it’s important to keep the message simple and accessible. That means high-level information in a format that everyone can read. For this type of communication, the information should be the focus. That’s why I prefer to create product roadmaps for communication purposes in PowerPoint. Most times, I am discussing the roadmap with folks who don’t care about the nitty-gritty details of enhancements or bug fixes. They want to know what to expect from the product within the next 1-3 years. What is the strategy? Where is the product headed? PowerPoint provides an easy way to create timelines that highlight where releases fall or what the theme of each release will be.

Using a tool like PowerPoint also provides a lot of flexibility in how the data is presented. I frequently have to modify the roadmap to accommodate the interests or knowledge level of the audience I am presenting to. PowerPoint lets me easily modify both the format and data presented (switching from release themes to release dates is a good example of how you can quickly create different views of the roadmap). At StrongMail, we use product roadmaps created in PowerPoint to share product strategy with customers, prospects, and internal team members.

A product roadmap doesn’t have to be graphical, though. You can just as easily make the roadmap text-based using either Word or Excel (or as I mentioned earlier, similar applications in other office suites). Using a text-based format makes the data even more transformable because it can so easily be moved between mediums and is just easier to work with by its simplistic nature.

Now, let’s revisit the first use of product roadmaps. At MediaPlex, I created a product roadmap in Excel because it made prioritization of upcoming features easier. The roadmap was much more of a scheduling tool for Engineering, so it made sense to have the specific enhancements and defect fixes listed out in detail. Once they were prioritized, I just cut/copy/pasted them into the MRD template, added some additional details and voila, release planned!

When I was working at Digital Impact (now Acxiom Digital), we used a combination of PowerPoint and Excel to manage the roadmap. PowerPoint was used to plan the long-term strategy and release calendar while the focus and details of each product release were tracked in Excel. While this method lets you track and communicate a wider range of data, I don’t recommend it. It requires that you keep two separate documents in sync and sometimes one shows up without the other, and because the data in one document relies on the data in the other document, it can be a bit cumbersome having to switch back and forth between them, both when editing and presenting.

Lastly, here’s a note about communicating product strategy versus the product release schedule. Roadmaps can be used to share information with internal teams, external constituents or as a planning tool for the Product Management team, but whichever you choose, you have to figure out whether you are going to make the focus of the roadmap strategy or release calendar. If it is strategy, your timeline can be vague — quarters or years. If it’s release calendar, the near-term has to be pretty specific: exact date or month, but the future can be more nebulous.

Having said all of that, the choice about how to manage your product roadmap and what tool(s) you use to do that depends a lot on your Product team and the audience for the roadmap. Is your audience going to respond better to high-level data, such as release versions and dates or are they looking for granular details, like which exact features and fixes will be in a particular release?

You also need to consider how frequently you plan to update the roadmap. The more detail and complexity you add to the roadmap, the more difficult and time-consuming it will be to update. This is fine if you are only planning to modify the roadmap a few times a year, but if you are at a start-up and/or your product is in a fluid state, you will want to keep it relatively simple so that making changes doesn’t take as long (or longer) as the actual implementation.

And as a final consideration, determine whether you plan to have the roadmap stand on its own or if it needs to be accompanied by additional details and voice-over. Several companies — splunk, Borland, and even Microsoft — have started displaying their product roadmaps to the public by making it available on their websites. This level of disclosure requires that your roadmap be able to be understood even when you aren’t there to explain it.

Figuring out how you are going to use the roadmap is the first step to identifying which format and tools will best suit your needs. There is no right or wrong way and what you choose now may not be what you need in the future, so don’t get hung up on it too much. Think about it like your product. Evaluate the market need(s) and then create a solution that addresses those needs.

For more on Product Roadmaps, check out my blog post from August 2007: Building a Working Roadmap.

9 other answers so far ↓

  • I Wrote a Post for “Ask a Good Product Manager” » The Productologist // Jun 16, 2008 at 7:22 am

    […] […]

  • Gopal Shenoy // Jun 16, 2008 at 1:36 pm


    Great post. The concerns I have in sharing the product roadmaps with customers is that this invariably turns into a form of commitment that you will deliver what you show on the roadmap. Even though you may harp that this is not a commitment and only a future vision, a higher expectation gets set.

    Given that product roadmaps are nothing but vaporware, it needs to be dealt with caution, especially if the customer who it is being shared with is a large or influential customer. The person who you show it to could use it to plan his/her internal development and he/she could do her sell job to her management saying that you as a vendor is expected to be somewhere in 1-3 years. So what happens when you don’t get there in 1-3 years or get to some other place because the market winds have changed? It all ends up to be the vendor’s fault.

    So, my word of advice would be to avoid showing product roadmaps to external entities as much as you can. This is easier said than done in enterprise software segment if you have the American Expresses, Merrill Lynches or Walmarts of the world as customers, but in the SMB market, I have gotten away with talking in very general terms than mentioning anything specific.


  • Ivan Chalif // Jun 17, 2008 at 11:16 pm


    True, there are risks to sharing your product roadmap. I have had my fair share of uncomfortable conversations with upset customers, prospects, and even internal folks when the roadmap they saw previously changed and whatever their pet feature was fell out of the release it was targeted for. However, I feel that the benefits outweigh the negatives, as long as the PM tailors the roadmap discussion and presentation to the specific audience and the proper caveats communicated (even if the audience doesn’t hear it).

    That’s one of the reasons that I like having our roadmap in PowerPoint. It can easily be modified to suit the needs of the day.


  • Switching to Product Management » The Productologist // Jul 29, 2008 at 6:55 am

    […] […]

  • Marcus // Aug 4, 2009 at 9:48 pm


    Well done piece – very thoughtful and informative. I was actually searching for a template to present something internally, so I guess I should have contacted you directly!

    – Marcus

  • Vikram Subramaniam // Sep 12, 2009 at 9:58 pm


    I’ve been a product manager for a few years now and I’ve always found that managing my roadmap and pipelines in Excel or bug tracker has been a problem because (a) it’s a bit cumbersome to prioritize and (b) it’s hard to get a portfolio view to make sure that the roadmap is well-balanced.

    I ended up building something to suit my needs and it’s available now for anyone who wants to use it at

    Would love feedback and comments.

  • Amit Bhatia // Feb 18, 2011 at 11:02 am

    Nice article!


    I just reviewed your tool. It seems like micro solution for small website development companies. In India, number of these companies is countless. I feel this product has a good future. I can help you refine this product and may be we can build some business out of it. Please contact me through


  • Alan Hamlyn // Mar 11, 2011 at 11:03 am

    Hey Man,

    Great blog post, I was wondering if you had any easy to use, excel spreadsheets, or templates for product roadmaps.



  • Catherine Constantinides // Dec 13, 2011 at 12:48 pm

    Great post, for effective product road mapping and release managemenet, you need tools that are tied to the rest of the product development process and that provide full visibility.

    Check out OneDesk, it features product roadmapping capabilities that allows you to visually lay out cost plans and schedules.


    Catherine Constantinides
    OneDesk Inc.