Published in


The Do’s and Don’ts of Product Roadmaps

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

The Do’s of Building a Roadmap

Let’s start with the do’s.

  • 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 do’s.

  • 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 the 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 Do’s 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 do’s and don’ts for how to most effectively communicate your roadmap.

  • 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 final don’t.

Rajesh Nerlikar and Ben Foster



ReadWrite is the leading media platform dedicated to IoT and the Connected World. We work with the industry's top technologies, thinkers, and companies to tell the stories that drive this world forward.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store

The latest #news, analysis, and conversation on the #InternetOfThings