Everyone on a product team has a core set of artifacts that they produce in the pursuit of building products to solve problems.
Designers have mockups, prototypes, and user interface designs. Developers have code libraries and diagrams.
Product managers have roadmaps.
With all the talk of outcome over output, it’s tempting to believe that unless the artifact is an actual part of the product (user interface designs and codes) it’s just waste and you shouldn’t do it.
It’s true that product teams have produced artifacts that aren’t necessary. However, a well-functioning product team will identify those artifacts that help them build the right product in the right way.
So your next thought may be, we may need those artifacts, but they’re still waste, so you should spend as little time on them as possible, and you certainly should waste money on a specific tool to produce those artifacts.
You produce artifacts for a specific purpose, and to make sure that artifact fulfills that purpose, sometimes you may need to use a tool built specifically for that purpose.
Let’s look at product roadmaps to see how this works in practice.
A product roadmap is a living document that guides the direction of a product. It’s both a high-level summary and a strategic document that communicates what teams are building and why, with a clear strategic plan for execution.
You can use a product roadmap to communicate a broad overview of your product strategy to people, both inside and outside your product team. This means you’re clearly conveying what you are going to do and what you will not do.
Having those intentions clearly communicated helps you to avoid spur-of-the-moment requests and priority changes, or at least gives you somewhere to put those ideas.
If someone comes up with a “great idea” you can put that item in the Later column, and then remind the requestor that the items on the roadmap are options, not commitments.
The visual nature of product roadmaps aids conversations about your team’s current work and the efforts you may focus on in the future, along the way conveying the proper amount of uncertainty that comes along with product development.
Product roadmaps should provide a high-level overview of your product strategy and direction in a variety of time horizons.
Those time horizons are now, next, and later meaning:
Problems we are trying to solve right now
Problems we may try to solve next
Problems we could consider later
Product roadmaps convey information at a summary level to keep the focus on what problems your product team is considering when.
They shouldn’t describe all the in-depth information about those problems. That level of detail is intentional because frankly, the only problems you know much about are those items in the Now column.
Keeping information at a high level helps you communicate your intended priority and provides a basis for which you can discuss why you’re working on certain things now, and other things later.
Plus, stakeholders don’t always want or need in-depth information on everything. They prefer visuals they can absorb quickly and identify the areas where they need to dig into more information.
That level of detail also conveys the amount of uncertainty you have about anything not in the now column.
That’s not to say that you should collect and record detailed information about the things you’re working on, especially right now.
You just don’t use a product roadmap to communicate that information. That’s what backlogs and other artifacts are for.
That said, there will be times when you need to easily find the relevant details about the items on your roadmap.
Your product team can use a roadmap as a visual aid for your prioritization discussions and to establish alignment around what problems you’re looking to solve right now and ones you’ll consider solving in the future.
When you’re able to align your product team around your product roadmap, you increase the likelihood that you’ll be able solve the problems on it. Of course, it does you no good to get alignment just once. You need to continue aligning on the product roadmap, which is why it needs to be a living document.
Product roadmaps also help you communicate with stakeholders about where you’re at and where you’re headed with your product. It’s one of your most valuable tools in keeping stakeholders up to date on your product and ensuring alignment with the rest of the organization.
Because product roadmaps are intentionally high level, they are easy to consume, but also can leave a lot to the imagination. That’s why you can’t just send it and forget, although you certainly should make the roadmap easily accessible for key stakeholders.
You need to supplement the always available nature of a product backlog with regular discussions of the roadmap to your stakeholders. This is your opportunity to supplement the intentionally high level information on the roadmap with the necessary context.
Your stakeholders benefit by getting regular updates and the chance to get clarity on areas they are concerned about. You benefit from these sessions by being able to correct any misconceptions that come about when people look at your roadmap and to set expectations.
To make sure these sessions go smoothly, it’s helpful to use a consistent structure for your product roadmap and to make sure it reflects the most up-to-date information.
You want your product roadmap to be a simple and clear communication tool that provides a high-level overview of your priorities and evolves.
You want your stakeholders to look at it and understand it when they need to, and you want to keep it up to date as your product team makes progress or changes direction.
You also want to easily get to the more in-depth information about some items from the higher level view.
Fortunately, there are product management products built specifically to help you create, maintain and share product roadmaps.
These products provide a simple, user-friendly way to map your product’s journey from concept to completion — tracking progress, aligning on priorities, and ensuring effective collaboration throughout.
Product management software provides templates that help you create your product roadmap in the most common formats, but it also allows your product team to create a roadmap specific to your needs.
Since product roadmaps should be dynamic documents, product roadmap software makes it easy to add (or remove!) items, change direction, and re-prioritize your plan of attack. And because tool vendors build these platforms for change, those amendments are quick to make (way quicker than on Excel, Google Sheets or via Post-It notes!)
Product management software makes it easy to share your product roadmap with your product team, organization leaders, and other stakeholders.
Your product team can be involved at every stage, providing top-notch collaboration and crystal clear communication. Changes are easy to make so you can keep your stakeholders aligned and up-to-date.
It makes sense that you could use a tool specifically created for producing roadmaps to produce roadmaps, but do you have to?
One purpose of roadmaps is communication. In order for a tool to communicate information effectively, people have to access it. So why not create your roadmaps in tools that everyone has - such as a spreadsheet or presentation software?
In addition, these are common tools, so you don’t have a significant learning curve. You can focus all of your effort on creating your roadmaps, not learning the tool.
That sounds good in theory. That’s not necessarily what happens in practice.
Shaw Li surveyed a group of product managers about the tools they use for roadmapping.
He found nearly 50% of those he surveyed use common tools like Excel and PowerPoint. He also found that they identified common issues when trying to communicate roadmaps to more than a handful of people:
Creating roadmaps in a slide format can take a long time to create, and is difficult to maintain.
Spreadsheets are notoriously difficult for collaboration among multiple individuals. While these tools have commenting functionality, it’s difficult to follow.
Moving items around in a roadmap in either PowerPoint and Excel can be time-consuming.
In effect, one of the major benefits that comes with using PowerPoint and Excel - their flexibility can also be a major downside of using them to make roadmaps.
If the nature of these tools makes maintaining these roadmaps difficult, you’ll be less likely to keep your roadmap updated. You’ll be more likely to make rushed updates once someone asks for an update.
There’s another type of tool you most likely have sitting around and is tempting to use for roadmapping. These are tools that product teams probably already have in their tool stack - project management tools such as Asana, Monday, Jira, and others.
Think about it - your product team is already using these tools to track your backlog. Why not just keep everything in the same tool and use them for your roadmap as well?
These tools are purpose-built, but are not meant to create roadmaps. They were built to manage projects.
These project management tools turn the focus to dates and tasks and imply more certainty than actually exists.
They reinforce an output/delivery focus rather than an outcome/discovery perspective.
The result is many product roadmaps built using a project management tool contain timelines instead of time horizons.
That doesn’t mean you shouldn’t use a project management tool at all. You just shouldn’t use a project management tool for creating, maintaining, and sharing your roadmap.
In fact, one thing to look for in a roadmap tool is one that integrates with project management tools so that you can share the data between the two.
Hopefully, you’re convinced that you should use a fit for purpose product management tool for your roadmaps.
Chances are you currently don’t have one. You may even dread the prospect of having to find one.
That may be one reason you thought that you would just use a tool your team already had, whether it was a presentation software, spreadsheet software, or project management tool.
Don’t panic. Here is some time-tested advice you can follow to find the product management tool that will help you create, maintain, and share your product roadmaps.
The key is making your decision maker (usually a product leader) confident about:
Your recommended tool has definite advantages over what you’re using today.
The benefits you experience from switching outweigh the pain of the transition.
There is a significant part of your team that wants to use the new tool.
This five-step process brings that confidence and makes getting approval for a new product management tool easier.
Most product management software contains specific process assumptions built in. The tool makers do that so that they build something useful and avoid building a tool that can do everything, but does nothing very well.
A potential downside to this expedient, in the words of Ken Norton, is that tools become opinionated. They can force you down a certain path where the tool dictates your process, which may not be ideal.
To avoid this issue, work out your preferred product management process first, and then identify the most important problems you want the product management software to solve.
For product roadmaps, craft your preferred structure for the product roadmap - such as an outcome-based roadmap with now, next, and later time horizons. And decide the frequency you’ll update the roadmap and how you’ll use it to collaborate with your product team and communicate with your stakeholders.
The specifics of your process become the primary requirements you use to select your tool. This process acts as your guardrails to narrow down the tools you have to choose from.
Once you have your process figured out. Use the specifics of that process to identify tools that will support your process.
Along the way, consider what’s important to you, your team, and the product leader who ultimately has to decide to purchase and start using the tool.
Look at your current process and any tools you're using. Identify what your product team likes and doesn’t like. Think about what problems you need to solve. Those problems might be:
Does it take too long to build and maintain your roadmaps?
Do you want to track outcomes in time horizons instead of outputs in timelines?
Do you have multiple products with different roadmaps that you would like to see in a consolidated view?
Do you have different audiences that want to see the same information in different ways?
Do you need to share your roadmap with people who may not have your tool?
Try to find three tools that best fit your chosen product management process and address the problems you’re trying to solve.
Once you settle on three products to try, learn as much as you can about each of them by using them. Try each tool with a free sign-up, trial or demo.
When you use the tools, use them for real life situations. For the best comparison, see if you can use all three tools in parallel to compare how they handle the same situations.
You’re not looking for a new product management tool just for yourself. All the product teams in your company are going to use the tool.
Include other people who are going to use the tool in your search and evaluation process. Their involvement brings in other perspectives and it helps you try out any collaborative aspects of the tool.
Keep notes about what you learned. If you have clearly defined use cases, take notes on how each tool handles that use case, including screenshots. You may even want to think of it as if you were writing work procedures for using the tool. If the prospect of this turns you off for one tool, that may be a sign that the tool is not right for you.
You can organize your findings with a selection matrix that lists the various problems you're trying to solve and provides a place to show whether each tool solves that problem for you.
The above example uses a simple Yes/No/Maybe skill to note each tool’s ability to address a specific scenario.
Yes: tool specifically addresses that scenario
No: tool does not address that scenario
Maybe: functionality intended for a different purpose can address that scenario
You can also use a numeric scale and total up the columns to get an overall score. Although don’t make your determination based solely on the score. It’s best to keep an overall picture in mind of the capabilities of a tool.
In case you find that none of the tools you’re considering support a particular aspect of your process, you might change your process. It’s rarely worth the effort to expect a tool vendor to create custom code to fit your process.
Use the selection matrix to guide the conversations of the group and your recommendation. You may find it helpful to have each person involved in the evaluation score each option on the matrix individually, and then compare the results.
Once you’ve settled on the scores for each tool on the scoring matrix, establish an agreement on which tool you want to propose and why.
When you’ve decided on the tool you want to propose, reach out to people that may be resistant to adopting a product management tool. Show them your selected new tool and get their thoughts. Make note of the things they really like about the new tool and think about how you can address their objections.
Involving other people in the selection process helps you to gain support of influencers in the company who will back up your recommendation when it comes time to present it to the product leader.
It also helps to build support from people on multiple teams. Your product leader usually will not want to make a unilateral decision to switch tools. They’ll want support from their peers. Any work you do to include people from different functions in the decision will help your product leader build up that support.
The work you put into evaluating and selecting a product tool is certainly important. Often, the ultimate outcome of the decision rests heavily on how you present your recommendation to your product leader.
When it comes time to propose your idea to your product leader, make sure you make it as easy as possible for them to make an informed decision.
Here are some tips on how to make the presentation of your recommendation to your product leader as effective as possible.
When you craft your recommendation, consider the audience. Make sure you specifically address how the new tool benefits your business in general and your product leader in particular.
Frame your recommendation to match the goals of your product leader. Do they need to convince their peers or their boss to adopt the product tool? If so, consider how you can provide them the information and arguments they need to do that.
Understand your product leader’s goals and figure out how your tool recommendation helps them reach those goals. In effect, you want to address your product leader’s specific pain points.
Plan to present your recommendation face to face (live or via video). The fact that you’ve carved out time to present your recommendation shows its important to you. It also gives you the chance to observe reactions to get an initial sense on whether your product lead supports the idea or needs further convincing.
You also present face to face to help grab your product leader’s attention. To make sure you really have your attention, you need to craft your presentation based on your product leader’s preference for absorbing information.
If your product leader prefers some pre-reading, send them a write up of your recommendation ahead of time.
When your product leader likes to see summarized information, send a slide deck ahead of time and walk through it during the session.
And if your product leader hates reading altogether, don’t send any information ahead of time and prepare to discuss your recommendation during your presentation.
Provide your product leader with the information they need to make an informed decision and to discuss the new tool with other leaders in the organization.
Provide the information that supports your recommendation and derisks the decision for the product leader. That information may include:
Limitations of existing solution and affects of those issues
Tangible benefits - cost savings; positive impact on bottom line or other metrics
Intangible benefits - employee experience, customer service
How you will roll out the new tool
How the tool addresses any specific pain points the product leader has.
It’s your job to show your product leader the need to change the way people work, and help them understand how the new tool helps your team and the company succeed.
An effective way to convey all of that information is by crafting an interesting story that’s tied to your product leader’s concerns.
Data about a tool’s capabilities provide a powerful argument, but it’s even more powerful when it’s wrapped up in a story that ties those capabilities to your team’s and product leader’s pain points.
Let’s say that your product leader’s primary concern is keeping track of multiple product roadmaps for your organization’s different products. Explain how the tool you’re recommending easily produces a portfolio view of all those roadmaps without a lot of extra effort.
As mentioned previously, involve other people in your search and evaluation of a new product management tool. You’ll want to include those people when you present your recommendation to your product leader.
Their mere presence will convey a broader range of support for your recommendation. This will convey to your product leader that people who work for their peers also support your recommendation.
If you have other people help, present your recommendation, you’ll be able to convey multiple perspectives to answer your product leader’s questions.
There’s also value in making sure that people who weren’t directly involved in the evaluation know about the new tool. Spread the word about the tool you’re considering to get people excited about it and find out what objections exist so you can address those objections.
Purpose-built product management software makes building and maintaining product roadmaps much easier. When you don’t have to worry about how you maintain your product roadmap, you can focus on the information those roadmaps convey.
There may be a few things standing in the way of adopting a new product management tool. Hopefully, with the ideas in this post, selecting a tool and recommending it to your product leader doesn’t have to be one of them.