Building and maintaining the product roadmap is a central part of your role as a product manager. Yet there is surprisingly little consensus about product roadmaps across the product management community. Opinions vary wildly, for example, about what exactly a product roadmap is, how to structure one, what to include in it, and which tools you should use to develop it.

In this post I will offer a few guidelines for how to structure your product roadmap in ways that can lead to the development of a successful product. But before we dive into these suggestions, I would like to start with two fundamental points about roadmaps — points I hope will make the guidelines that follow much clearer.

The top-down approach to product development works best.

For successful product development, I recommend a top-down product strategy. Product roadmaps fit very strategically into this hierarchy. Here’s how it works.

Start with your product’s vision — which you’ll derive from your company’s larger strategic objectives. Then translate that high-level vision into actionable goals. Next, turn those product goals into your product roadmap. Finally, move from your roadmap to your backlog.

Starting at the highest level, and working your way strategically down into the details, is the best way to stay focused and on track toward your main objectives — and to avoid losing sight of why you’re doing what you’re doing and getting lost in the weeds.

And speaking of getting lost in the weeds…

A product roadmap is not a list of features.

A list of features is just that — a list of features. The product roadmap, on the other hand, is a strategic document that represents your high-level goals for the initiative along with an execution strategy to communicate how you plan to achieve those goals.

A roadmap might include features, of course, but the features themselves are only a part of the execution plan.

Five Guidelines for Structuring Your Product Roadmap

1. Product Roadmaps Should be Flexible

You’ve got to be okay with uncertainty. You’ve got to be willing to embark on your product plan, knowing that you can’t possibly know everything at the outset — that you will hit surprises, challenges, and opportunities along the way. Your roadmap needs to factor in these uncertainties — and needs to be flexible enough to allow you to change course quickly when necessary.

To avoid making promises you can’t keep, make sure your stakeholders understand that the roadmap is not an end-all, be-all document. One way to do so is to show more granularity in the short term while keeping your initiatives high-level and your dates approximate in the long term.

Thinking in themes is another effective way to keep your roadmap flexible. For example, maybe you and your stakeholders have agreed to focus on increasing conversions from a particular target persona in the upcoming quarter. This area of focus becomes your theme, and you retain the ability to reprioritize specific features and fixes within that theme while keeping the overarching goal intact. Likewise, if an opportunity arises that was not originally on your roadmap but furthers your shared goal, you’ll have an easier time making a case to include it.

Finally, a flexible roadmap can be a headache if changes are not communicated promptly and effectively. Ensure your stakeholders always have access to the most up-to-date version of the roadmap, whether that means storing it on a shared wiki or using cloud-based software that automatically updates. Transparency is key to building alignment on product strategy, no matter how frequently you need to reprioritize.

2. Product Roadmaps Should be Deeply Rooted in Well-Thought-Out Goals

This might sound like a contradiction to the previous guideline — but it’s not. You can frequently reprioritize your backlog while still staying true to well-thought-out, agreed-upon goals.

Your specific roadmap priorities might need adjusting in light of new information — in fact, they almost certainly will at one time or another. But you should be prepared to adjust focus in your roadmap, reallocate resources or otherwise change direction only if doing so is in alignment with your product’s high-level strategic goals and vision.

As a product manager, it’s your job to make sure that you’re making decisions about what to do, and what not to do, for the right reasons. Even if a sales executive is loudly demanding the immediate inclusion of a new feature to close a deal, you still need to weigh the request in light of your organization’s strategic goals. Quick wins do not necessarily spell long term success. If the feature isn’t in line with your product vision, it’s okay to say no. Indeed, if you’re doing your job well, you’ll find yourself saying no quite often.

3. Product Roadmaps Should be Developed with Plenty of Input

You don’t need to craft your roadmap yourself. You shouldn’t. Silos rarely work for any business function, and for roadmaps they can lead to ill-advised plans and products developed without critical knowledge.

To successfully bring a product to market, or to update an existing product in such a way that benefits the customer and your company, you’ll need plenty of input from experts across a variety of teams and departments. That includes, for example, engineering, customer support, sales, and marketing.

Sales, for example, will have valuable anecdotes about their most recent wins, or their most important ones. They can also tell you about the features prospects and customers are asking for.

As for your engineers, the more you involve them in the creation process, the more ownership and responsibility they will take for their role, and the more creativity and enthusiasm they’ll bring to the project. Collaborating with your engineers, and soliciting their help, will make them feel more like a part of the process, and less like order takers simply being told what to do by a product manager.

Prabhat Jha, CTO of the Net Promoter Score platform InMoment adds, “Be sure to solicit plenty of user input. Some years ago I learned this the hard way. The software enterprise where I worked did not have a rigorous system in place for listening to customers. We had collaborated internally on our roadmap priorities and thought we knew our customer’s needs. We missed key features, though, and as a result, there was very little adoption of the first version of the product. We ended up having to do a second release very quickly in order to get traction.”

4. Product Roadmaps Should be Visual

Ultimately, a product roadmap is a communication tool — an execution strategy you will use to convey your product plans and goals to a variety of constituencies. And the best way to communicate a complex initiative is visual. If your roadmap is simply a long list of features presented in a spreadsheet, people’s eyes will glaze over.

Visual roadmaps make it easy for everyone in your strategy meetings to quickly understand what you are proposing and hoping to accomplish quickly.

Another valuable reason to make your product roadmap visual is that it forces you to be ruthless about which initiatives to include and which to leave out. Venture capitalist Guy Kawasaki’s “10/20/30 Rule of PowerPoint” instructs that PowerPoint presentations should have 10 slides, last no longer than 20 minutes, and contain onscreen text no smaller than 30 points. In addition to making the presentation more digestible for an audience, this exercise forces the presenter to distill both the whole talk and each individual slide down to its most essential elements.

The same is true for product roadmaps. If you use a visual tool for creating your roadmaps — such as PowerPoint or a visual roadmap software application — that exercise will force you to distill your plan down to only those initiatives that serve your product’s strategic goals and vision.

Looking at this from another angle, if your roadmap contains 1,000 initiatives, that probably means you haven’t done a good job of prioritizing and strategizing what needs to be included in your product. Indeed, if you do have a list of 1,000 initiatives, your document could probably be more accurately called a backlog than a roadmap.

5. Tailor Your Roadmap Discussion to Your Audience

You are likely going to show your product roadmap to many different constituencies, in many different meetings, throughout the development cycle of your product. Each constituent group will have a unique focus and set of priorities, and each meeting will call for you to delve into different aspects of the product roadmap.

There are a couple of ways of accomplishing this. You can create separate roadmap documents for each constituency, or you can use a single, general roadmap and zoom in to what’s important for each group. The important thing is that you provide your stakeholders context and show them how your plans will further their unique goals.

For example, for your sales team, you might want to highlight the aspects of your roadmap that are designed to bring them better-qualified leads — for example, a trial version of your software that can help to prequalify interested prospects.

Customer-facing teams also likely had input into the features that made it onto your roadmap in the first place. Be sure to communicate to them where their requests fit into the plan (or didn’t) and why.

However, when presenting the roadmap to your executives, you’ll want to focus on how the choices you’ve made will lead to increased revenue or grow market share.

And when meeting with your engineering team, you’ll want to focus both on the high-level themes and specific feature details and discuss how your engineers can help to make those product goals a reality.

In other words, you want to keep your product roadmap flexible enough that it can help facilitate a productive meeting at any level of detail needed, with any constituency group you are presenting to.  

Conclusion: Whatever structure your product roadmap takes, its main job is to communicate your strategy.

A product roadmap needs to communicate your strategy. It is your job to create your roadmap in such a way that it lays out a high-level execution plan for the product’s successful development and eventual launch into the market. It’s also your job to make sure all relevant constituencies understand the goals of the roadmap — and work with you to achieve them.

New things will always come up — cool ideas for new features, requests from executives for a shift in priority,  urgent demands from sales reps, and so on. The challenge for the product manager is to view each one as an opportunity to evaluate through the lens of strategy and goals and help drive a sound decision-making process.

That’s why you need to start with your product vision, and from there derive specific goals — and only after you’ve developed those goals, build your product roadmap. If you haven’t fully fleshed out your vision and strategic goals for the product, it’s too early to start building your roadmap.

About the author:
Andre Theus is the Vice President of Marketing at ProductPlan. He works closely with customers and prospects to build better product roadmap software. Prior to ProductPlan, he was a member of marketing teams at RightScale, Sonos, and Citrix. Andre received a master’s in computer science from the Cologne University of Applied Science in Germany.

Originally published June 28 2016, updated July 28 2020