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 doâ€™s and donâ€™ts that can guide you in crafting your roadmap document.
The Doâ€™s of Building a Roadmap
Letâ€™s start with the doâ€™s.
- 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), and 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 of 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 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.
- 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 final 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 doâ€™s, and donâ€™ts will help ensure that you craft and effectively share your roadmap.
For more advice on product roadmaps, you can find Build What Matters on Amazon.