3 Ways To Structure Your Roadmap

This post ‘3 Ways To Structure Your Roadmap’ is a guest post from the folks at ProductPlan. 

There is little consensus on the correct way to structure product roadmaps. Product managers hold wildly different views, for example, on what areas roadmaps should focus on, what level of granularity they should go into, and what timeframes they  should cover.

And why are these questions so important to you as a product manager? Because ultimately your goal in developing a product roadmap is to create a document that can help you better communicate your strategy to the various constituencies whose help you’ll need to bring your product successfully to market.

Always Put Strategy First

Before I delve into a discussion of three options for structuring your roadmap, I want to make a suggestion that will hold true for your roadmap no matter what type of format you use or level of detail you include: You should always start with strategy. Only after you’ve fully fleshed out your high-level strategy should you begin moving onto the details of execution.

Here’s what this process should look like.

Roadmap Image

Start with Product Vision

Whether you’re creating this vision yourself or it’s been handed to you, this is where you start in developing your product.

One way to start thinking about product vision is to ask questions such as, “What would the most successful outcome of launching this product ultimately look like in the market?” Or, “What will the product do for our customers, for our company, and for the industry?”

Then Determine Your Product Goals

From your high-level vision, you can derive specific goals for your product. These might be increasing adoption, improving customer satisfaction, reducing churn, gaining more market share, etc.

It will be these high-level goals that will drive how to build your product roadmap.

Next, Build Your Product Roadmap

Now that you have a clear vision for your product, and you’ve turned that vision into specific measurable goals, you can start determining how to translate those goals into actionable initiatives on your roadmap.

It’s important here to reiterate that the product roadmap is a strategic document — it should serve as a high-level execution plan to help you prioritize your goals and communicate to your constituents how you plan to achieve them.

Your roadmap is not simply a list of the features you’ve decided should be included in the product. That feature list, or your backlog, will come separately, after you’ve built the high-level strategic plan into your roadmap.

Finally, You’ll Develop Your Backlog

After you’ve built a roadmap that lays out your strategy for developing the product, it will be time to translate that high-level plan into the specific tasks, features and other details — your backlog and release plan — you’ll need to complete to make the product a reality.

All of this might sound obvious, but you’d be surprised how many products are developed using a bottom-up approach instead — starting with a detailed list of features, without any strategic plan or high-level goals for the product.

Successful product managers work top-down — starting with strategy — and then, only when they’ve determined why they need to develop the product in a given way, they begin working down into the execution details.

3 Ways to Structure Your Product Roadmap

Now that we’ve discussed the universal guideline for beginning the roadmap development process, here are three ways you might want to structure your product roadmap.

  1. Theme-based product roadmap

Product Roadmap Themes


Themes are a great way to keep your product roadmap strategic and high-level, and they work well for presenting big ideas to your constituencies.

With a theme, you group together common elements into a larger strategic goal. For example, a theme for your software might be to “Enable Customers to Complete Their First Purchase Faster.”

Now, the specific deliverables under that theme might include improving support for mobile devices, swapping out your credit card processor, and so on.

In other words, without having to go into a lot of detail about specific features, you can use a theme-based roadmap to roll up a series of related initiatives into a high-level theme that will help your product deliver customer value.

Themes are an especially useful way to present your roadmap to executives, to help them quickly understand where you’re going with the product and why — without bogging them down discussing specific details

  1. Product-line-based product roadmap

Product Roadmap Multiple Products


You can also organize your roadmap by product line or by product category.

For example, let’s say your product has a web-based version and a mobile version, grouping those different versions into separate roadmaps might get cumbersome and inefficient.

But if you’re keeping your roadmap strategic and high-level, you can easily group those different categories into a single roadmap. That’s because strategically you will be using the roadmap to track and prioritize many of the same goals for the different versions of the product.

In fact, when you group your various products in a product line, or related products in a category, into a single product roadmap you may even find synergies among them that you wouldn’t have discovered if you were treating each product in a silo on its own roadmap.

  1. Timeline-based product roadmap

A typical timeline-based roadmap is organized by months or quarters. Like theme-based roadmaps, timeline-based roadmaps are also typically used when presenting to executives — because executives want to know when to expect a release or when your development team will be ready to show them a demo or reach some other internal milestone.

There are instances when having dates on your roadmap isn’t advisable — such as for customer-facing roadmaps.

Interestingly, you can also create a timeline-style roadmap but then suppress the dates themselves. This can be an effective way to track of and communicate the priorities of your various initiatives, but without focusing on or committing to specific delivery dates. This is one of the features in our visual roadmap software — where you can build a product roadmap in a timeline-oriented format, and then turn off the dates.

Whether you show dates depends on the audience for your roadmap.

Other Key Things to Build into Your Roadmap

Finally, here are a few more thoughts to help you build the most effective product roadmaps and, ultimately, to give your products the best chance of success.

Your product roadmaps should be visual.

So many roadmaps today are built in spreadsheets or other non-visual applications. But people are visual, so you are likely going to have difficulty communicating something clearly and persuasively to your stakeholders if you present it as a long, text-based list.

The most compelling roadmaps are visual. Whether you use Microsoft® PowerPoint® or visual roadmap software, whenever possible you should develop a visually oriented roadmap.

Your product roadmaps should be accessible and easy to update.

With cloud tools and real-time collaboration now the norm for many business functions, there is a movement to make product roadmaps living documents — as opposed to the static documents they’ve been historically.

We believe strongly in this approach at ProductPlan, particularly for teams in agile development or software development generally, where the pace of change demands roadmaps that can be adjusted and re-prioritized easily and frequently.

You want to make sure that the latest information on your roadmap is always accessible to everyone, and even in a self-service manner, so for example your executive stakeholders will be able to find the roadmap online anytime and view it.

This means the tool you use to develop your roadmap needs to be easy to update. Making changes to a static PowerPoint-based roadmap can take hours. You’ll benefit from maintaining your roadmap in a product designed specifically with flexibility in mind — ideally web-based product roadmap software that makes it easy both to access across the web and to update with simple drag-and-drop features.


Jim Semick is the founder of ProductPlan, software for helping product teams share their product roadmaps. Jim has helped launch such products as Citrix GoToMyPC, GoToMeeting and AppFolio. He’s a frequent writer and speaker on product management.

Product Management Training