The dos and don’ts of creating your product roadmap

You wouldn’t start a cross-country drive without a roadmap (or GPS), and neither should you attempt product development without one. 

A product roadmap is what connects the near-term product changes to the mid-term strategic milestones and the long-term vision. It communicates the sequencing of priorities and helps you plan all your product-based initiatives.

But many leaders are confused about what goes into a product roadmap. Ultimately, there is no right answer: different types of roadmaps suit different companies. 

They can show lots of detail or very little; they can be intentionally scrappy or highly organized with color-coding, iconography, team associations, and more. We’ve seen them printed on ten-foot-wide poster paper and contained on a simple Google Sheet. 

While there is no “best way of making a roadmap,” there are a few dos and don’ts that can guide you in crafting your roadmap document.

The 💜 of EU tech

The latest rumblings from the EU tech scene, a story from our wise ol' founder Boris, and some questionable AI art. It's free, every week, in your inbox. Sign up now!

The dos of building a roadmap

Let’s start with the dos.

Do clearly categorize specific roadmap initiatives. Based on our experience, we’ve realized that all product development activities can be placed into one of three categories:

• Innovation (making progress towards the vision)
• Iteration (getting better results from what you’ve already built)
• Operation (maintaining your product and running your business)

If possible, on top of categorizing each initiative, communicate the allocation target for each category to remind the audience the level of investment that was agreed upon.

Do paint a picture far enough in the future that it helps other teams to plan accordingly. For example, marketing may need to start working on communication plans for a large product release well in advance.

Do clarify the rationale behind the work you’re planning on doing. The problems you are solving, the value you are attempting to create, and the key outcomes you are trying to deliver are often more important than the features you currently intend to build.

Do leave room for plans to shift. Development timelines are notoriously difficult to predict in advance. As you experiment and validate assumptions through customer discovery, you will want to be able to react to what you learn, and the roadmap should allow for that.

The don’ts of building a roadmap

And now the don’ts, which are just as important as the dos.

Don’t try to predict development plans so far ahead that you’ll almost certainly change them before you get there. Offering this false precision is a common way to erode trust between product and the rest of the company.

Don’t worry about providing the same level of fidelity for every team. It’s okay for the roadmap to have a “ragged edge” in which some items are better understood than others, or some teams’ plans extend farther into the future than others.

Don’t make commitments that are unnecessary or that are unlikely to actually be met. Generally speaking, it’s better to avoid feature-date pairs unless there’s a specific business reason the date is as important as what actually ships.

Don’t get in the habit of playing roadmap Tetris to force as much in as possible. It’s far better to under-commit and over-deliver than vice versa, and you’ll need some buffer to accommodate the ripple effects when development doesn’t go according to plan or critical feedback comes in.

The dos and don’ts of communicating the roadmap

Building the roadmap is only the first step. After that, you need to share it with all the stakeholders. Here are some dos and don’ts for how to most effectively communicate your roadmap.

Do share it with your executives first, because if you get buy-in from leaders in the organization, they can help build agreement and excitement about its contents with the rest of the employees.

Don’t present it to the whole company at once. Each major group within the company will have different needs and concerns.

By presenting to each group separately, you can best address these needs and concerns and help everyone get what they need out of the presentation. We recommend having separate meetings for each of the following groups:

• Engineering, QA, Architecture
• Sales and marketing
• Account management, customer success, and customer support
• Everyone else not in those groups (HR, finance, etc.)

Don’t be boring. Your presentation quality matters tremendously, and it’s your job to make your presentation engaging. Use charts and other visuals.

Do create a system for answering questions and getting feedback. Some of this can be done in the presentation meetings. However, some people don’t feel comfortable asking questions or offering feedback in front of others, so also consider conducting anonymous surveys after the presentations.

One more do and don’t

We’ll leave you with one final do and one don’t.

Do dedicate the time and resources to creating a roadmap. It’s one of the most important documents guiding your company’s actions and initiatives.

But don’t stress about making a “perfect” roadmap. The best roadmaps evolve and develop with the company and serve to spark the right conversations about priorities.

Whether you opt to build a highly detailed, organized roadmap with color-coding and more, or a broader, intentionally rough one, following these dos and don’ts will help ensure that you craft and share your roadmap in an effective way.