Roadmaps are usually the key strategic document for Product and Engineering organizations, listing the priorities and guiding execution.
The true value of a roadmap is secured by applying a combination of a strong process to reach agreement about the contents and a solid adherence to that agreement. The end result is a documented roadmap. The document explicitly clarifies to all relevant stakeholders the high-level areas where the organization will focus its efforts.
When properly created and leveraged, I find roadmaps to be an excellent tool, and use them often.
The Basics
A roadmap is basically a list of the projects, features, or themes that your teams will work on in the following months, quarters, or years. It will look something like these simple examples:
An example of a product roadmap created in Excel
An example of a roadmap created in ProductPlan
These simple examples convey the basic ideas clearly enough: the work that teams will focus on is visually laid out in a time sequence, illustrating the relative priorities and the approximate duration of each effort. Actual roadmaps can get quite a bit bigger, as they may reflect the work to be done by many teams.
I much prefer using a full-featured tool like ProductPlan to create and modify my roadmaps, but if you don’t have access to such a tool, Excel will do the job.
In a Bit More Detail
Roadmaps list the product priorities and guide the creation of the software. They are not intended to be a detailed breakdown of all the work, as such details are listed elsewhere. Nor are they set in stone. It is likely that, as the work proceeds, a roadmap will occasionally need to be edited to reflect new realities and priorities. Although lacking detail, a roadmap should provide a clear focus. Each person and each team should have a good idea of what they are expected to deliver.
There are many ways to prioritize the work that comprises a roadmap (which is worthy of a separate post). A comprehensive process will synthesize a range of inputs, such as: customer feedback, the company’s vision, product metrics, market opportunities, competitive analysis, opportunity costs, and great ideas. The trick to producing a good roadmap is to figure out what matters most and prioritize that first. There will always be more work than can be done in the time by the available resources, so one key point is to reject the less important work.
“Focusing is saying no.” – Steve Jobs
Pro tip: Whatever process your organization uses to create a roadmap, ensure that there is clear alignment among the stakeholders and a commitment by them to support the resulting roadmap.
The Power of a Good Roadmap
A well thought out roadmap, properly discussed and with the agreement of all stakeholders, is a powerful tool.
- It represents the fleshing out of the organization’s vision by providing specific items and features that should be implemented.
- It explicitly presents the best thinking as to where product and engineering teams should focus their time and energy.
- It provides goals for which you can create OKRs and other planning aids. It aligns the teams with the priorities.
- It can provide insights about how you should structure and staff your teams.
- It helps clarify dependencies and prerequisites, without going full-Gantt, like waterfall project management (more on this later).
If you are familiar with Stephen Covey’s Big Rocks analogy, then the items on the roadmap are the biggest rocks, the things that matter the most and should be worked on first. These are the items that need to be clearly specified, prioritized, and communicated to all stakeholders.
The Roadmap as Communication
A roadmap is used to communicate priorities to product and engineering teams. But it should also be used to communicate those strategic priorities across the entire company and with other key stakeholders, such as company boards and investors. Properly created and utilized, a roadmap is the key strategic document for the entire company.
A roadmap should regularly be shared (and discussed) with internal stakeholders. Since it represents the enactment of the company’s vision, it can inspire and align the employees and management behind the goals. It can also ensure that everyone in the company is aware of and prepared for the work that has been planned.
However, use caution when sharing a roadmap directly with outsiders and customers. Much like your internal financial information or raw company metrics, you should be selective in what you expose. If you overshare, your customers may try to unduly influence your direction, question what you intend to change, or rely too much on approximate dates. If you do share this sort of forward-looking information externally, ensure that you do so with a proper safe-harbor disclaimer, warning viewers that the information may change.
Set in Stone?
Despite the significance of a roadmap, it should not be set in stone. It needs to reflect the best, latest thinking of the organization regarding its priorities. So, it makes sense to adjust a roadmap on something like a quarterly basis or when critical new information becomes available.
But a roadmap should not be constantly changed, tweaked, and adjusted. An organization that constantly modifies its roadmap will, at a minimum, lack focus and be inefficient in its use of resources. In the worst case, repeated changes can indicate a lack of strategic direction. A roadmap loses most of its value when an organization does not actually maintain its commitment to it.
To be clear, determining priorities is hard and planning software projects is difficult. So, some change is expected. Strong organizations recommit to refined roadmaps, while weak organizations continually tweak and question their uncertain roadmaps. It’s not much of a roadmap if it isn’t leading you in the right direction.
What Is the Right Level of Detail?
To be useful as a strategic document, a roadmap should contain high-level information, without becoming bogged down in the details. As shown in the examples, the features listed are relatively large and span approximate time frames. It should be easy, perhaps through a click or hovering, to get a high level description of a feature. All other details should have external links and not clutter up the roadmap.
A roadmap with easily accessible information
If you are using some form of the agile methodology, it is tempting to break the work listed on the roadmap into sprints and to include story points for the work. Be careful. An assumption that you know all the necessary information ahead of time is a hallmark of waterfall planning. Gantt charts, which superficially look like roadmaps, plan out all the future tasks in lockstep. Gantt charts take a large effort to produce, as they attempt to predict both the high-level strategy and the low-level effort, but rarely do either well.
When you do begin planning the actual work and start determining the specific stories and effort, you may need to suggest adjustments to the roadmap based upon the information you have gathered. Larger projects may require multiple planning cycles and corresponding adjustments. Here are the pro tips:
- Ensure that your initial roadmap has some basis in reality, so that you are unlikely to need to completely modify it every time you begin detailed planning. Consistently poor or wishful planning will result in major roadmap changes.
- Do not attempt to put all of the details about the work or time scale into a roadmap. A roadmap is at a high level; use other documents for the details.
Roadmaps can be a Powerful Tool
A roadmap should be simple to understand but can be powerful and versatile. As with any tool, it can take some effort to master. A roadmap repays this effort by clarifying the organization’s vision, aligning the people, informing stakeholders, and assisting with the project planning.
Hopefully, this post has given you a little more insight into how to best leverage them.
The keys to unlocking the potential of a roadmap are as follows:
- Ensure that there is clear alignment among the stakeholders on the priorities listed in your roadmap.
- Maintain a strong commitment to your roadmap unless and until there is a compelling reason to change direction. Do not constantly tweak, adjust, or reorganize it.
Strong product-centric organizations demonstrate their ability to plan and execute through their roadmaps.