Roadmapping — Part 1: A living document

8 min readOct 27, 2023

A roadmap can serve as a primary communication tool to all stakeholders about what’s been done, what was planned, what is in jeopardy, and what is on the immediate horizon.

This post was originally published on Roadmap Weekly.

What is a roadmap?

A roadmap is a living document; it’s something that should continue to change and be updated as more information becomes available. A roadmap should also reflect your team’s current and past work.

There must be more than quarterly or yearly planning or a set-it-and-forget-it approach. As a product manager, review your roadmap at least weekly and adjust as new information becomes available.

A roadmap can serve as a primary communication tool to all stakeholders about what’s been done, what was planned, what’s in jeopardy, and what is on the immediate horizon. Milestones, priorities, blockers, and risks can all be shown on a roadmap. Now, you have to be careful because there is such a thing as having too much information in one place. That’s why I suggest multiple ‘layers’ to your roadmap (something we’ll cover in a future post), and if done right, you’ll only have to maintain this information in one place. With only the necessary information being seen by each stakeholder.

The stakeholders

So, let’s talk about the stakeholders of your roadmap. There are quite a few, and their concerns are many, but they can be split into two primary categories.

Let’s first split our stakeholders into two groups: internal and external.

Internal stakeholders — Often need to see much further into the future and, depending on who they are, be involved in the planning process. Think of Engineering and their input on the complexity of certain features or problems, helping you decide what to prioritize and understand the effort associated with each. Also, internal stakeholders may be more flexible and understanding when priorities on your roadmap change.

External stakeholders — These could be customers, and they’re usually more interested in what problems you will solve for them. I suggest limiting the details here and focusing on the few key initiatives that will impact them the most. i.e. ‘Significant improvements to account management and billing’ may be enough detail without going into the particulars of what exact features are being added until you’re 100% committed.

Here are a few categories of internal and external stakeholders and how your roadmap may benefit them.

Your Customers — Regardless of who your customers are, it can be helpful for them to know what areas of your product are a priority. A frustrated user who wants better account management might stay if they know improvements are coming.

Your Managers — Your manager is juggling your team’s priorities with those of others. They may also be able to see alignment issues or help bring joint initiatives together, but only if they have a good picture of what their teams are doing.

The Board — Depending on the company, your team’s initiatives may be excluded from the board presentation. Still, your manager will need your roadmap to share relevant details with executives.

Engineering — This team should be highly involved in planning your roadmap from day one. You’ll want to avoid surprises here. Without engineering involved, how will you size up opportunities and understand the complexity of each idea?

Design — The same could be said for design because many solutions require pre-planned user experience solutions. Design often works ahead of engineering on solving particular UX or design problems, so they’ll have to know well in advance what’s being built.

QA — Have a feature that’s going to require additional testing? Your QA team will want to know about it to anticipate the added workload.

Sales — An upcoming feature may seal the deal with a new client. Roadmaps can help your sales team close deals, but they can also help ensure they don’t over promise or set the product direction for you. If you don’t make the product roadmap, your sales team might do it.

Marketing — Budget allocation, marketing materials, conferences, joint marketing efforts. Your marketing team has their roadmap, key initiatives and events they need to plan around, sometimes years in advance. Your roadmap can inform them of what’s coming and help them build their plan. I do recommend waiting to promote features until well after the initial launch. Ideally, they’ve been beta-tested or soft-launched at least a few weeks in advance; this will help manage expectations during delays and give your team time to work out any issues before broader adoption.

Customer Success / Support teams — Developing a new feature? These teams may need to write up additional user documentation, adjust their help manuals, or build a new onboarding flow. If they know what’s coming, they can plan around it and ensure they also leave time for their part of the process.

How far into the future?

The size and stage of your company or product largely dictate how far into the future you have to look. If you’re an early-stage startup, you’ll likely only be planning a quarter into the future for your detailed roadmap, with a longer-term, less granular vision of what’s to come further in the future. Other considerations would be the industry you’re operating in. Heavily regulated industries with additional compliance concerns and approval processes may have a very stringent roadmapping process encompassing the next two years or more. There’s no one-size-fits-all all.

Different types of roadmaps

A well-structured roadmap integrates crucial elements such as product milestones, feature prioritization, and a realistic timeline. It acts as a comprehensive blueprint, guiding the product team through the intricate development and deployment process.

There are different levels of Roadmaps, and these take the form of different timelines and levels of detail:

Strategic Roadmap — This high-level roadmap outlines the product’s long-term vision and objectives. It typically covers 12 months or more and focuses on the broader goals and initiatives the product aims to achieve. Strategic roadmaps are primarily used to communicate the product vision and direction to executives, stakeholders, and high-level decision-makers.

Product Line Roadmap — A product line roadmap is a more focused roadmap that outlines the strategic plans for a specific product line or a group of related products. It provides a cohesive view of how different products within the same line or family will evolve. This type of roadmap helps align the development efforts across multiple products and ensures consistency and coherence within a product portfolio.

Technology Roadmap — Technology roadmaps focus on integrating specific technologies and technical capabilities into product development. They outline the adoption of new technologies, upgrades, or infrastructure changes required to support the product’s long-term goals. Technology roadmaps help align product development with the latest technological trends and advancements.

User Story Roadmap — This type of roadmap emphasizes the user experience and customer journey, highlighting the specific user stories and personas that will be targeted in each phase of the product’s development. It helps you understand the user’s needs and preferences, ensuring that the product features and functionalities align with the end-user requirements and expectations.

Release or Feature Roadmap — This type of roadmap zooms in on the specific features, enhancements, or updates that will be delivered in each product release or iteration. It usually covers a shorter time frame, typically three to six months, and provides a detailed plan for the upcoming releases, including the features, functionalities, and improvements that will be included. Release or feature roadmaps are essential for the development team and help plan and prioritize tasks for each development cycle.

Development Roadmap — Similar to a release or feature roadmap, this is the most granular view and usually exists in a planning tool like JIRA with more detailed Epics and tickets for each feature.

The Lifecycle of a Roadmap

Planning next quarter’s roadmap starts after this quarter’s roadmap is committed to, but already knowing what you’ll be working on a few quarters ahead of time is good. Roadmap planning is a continuous process. Every week, when you check in on this quarter’s roadmap, you can also update the next quarters or put placeholders in position for a year from now. Adding these details weekly as things happen helps reduce the chances something will be forgotten. They may not be added to a roadmap; they could live in JIRA as Epics or a spreadsheet. Regardless, ensure you’re grooming the backlog like anything else; otherwise, it will get far too cluttered.

During the development phase, the development roadmap continues to take shape. Your development roadmap will get more detailed as you get closer to each sprint or release (it may only look a few sprints ahead). As this happens, if things are taking longer than expected, you’ll adjust timelines on your feature roadmap to reflect what’s happening in development accurately. Remember, the development roadmap delineates the specific tasks that need to be accomplished to complete the feature, the feature roadmap focuses on the release, and your other roadmaps should be more strategic, focusing on the problems you’re solving.

These strategic-level roadmaps typically only need to be updated during the current cycle if market dynamics and customer needs evolve and the product team needs to recalibrate strategies and priorities. This flexibility is crucial for ensuring the product remains relevant and competitive in a constantly shifting landscape and to continue delivering on what you’ve promised your external stakeholders.

Strategies to keep your roadmap flexible

Focus on outcomes, not solutions — It’s common for solutions to change, but the problems you’re solving are still there regardless. Focusing on the problem and the outcome you’re looking for is a great way to add flexibility to your roadmap. We learn as we build things, and as you’re making a feature, you may change it; you want to keep as much of that flexibility as possible.
Communicate that things could change — Be open, especially internally, that things could change, priorities might shift, and communicate roadmap changes so stakeholders stay in the know.
Don’t overcommit — Doing a few things well is better than failing at everything.
Don’t work on everything all at once — let past work and learning help inform future work, and get value sooner by limiting the amount of work being done simultaneously
Build in buffer time — This is especially helpful when planning your release roadmap or anything that gets shared externally.
Regular roadmap reviews and adjustments — Remember, the roadmap is a living, breathing document. You should update it as more information becomes available.
Only schedule one feature version at a time — The first version of your feature will rarely be perfect the day it launches. A learning period needs to happen after a feature launch, and you need to allow for this time before working on the next version of that feature.

Conclusion

In product management, a dynamic product roadmap is an indispensable compass, guiding teams through the twists and turns of your product evolution. By understanding the importance and purpose of this powerful tool, you can navigate with clarity and purpose, ensuring your product teams survive and thrive in a dynamic and ever-changing landscape.

This post was originally published on Roadmap Weekly.