Ask A Good Product Manager

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.