A product roadmap represents your strategic plan to solve a problem for your market. The reason to share your product roadmap plan with stakeholders is to create transparency and alignment across your company. You want everyone to understand the plan so that they’re all working toward a shared goal.
But your roadmap does not represent an obligation or commitment to accomplish everything on it. When you share a roadmap, you are not making a promise—implicitly or explicitly—to deliver specific functionality by a certain date. You’re inviting stakeholders into your current strategic thinking and planning, which could change anytime for several reasons.
We’re writing this post primarily for people new to their product management careers. But we believe that experienced product professionals can also benefit from an occasional reminder that a roadmap is a plan, not a promise.
Your processes should serve your product, not the other way around
To illustrate the importance of this distinction, let’s try a thought experiment.
Imagine you coach an amateur basketball team in a 50-and-older league. You have a strict process for vetting new players. In addition to on-the-court tryouts, you insist candidates spend a few hours meeting with your current players and assistant coaches. The process reduces the chance that you’ll bring on a new player who doesn’t get along with the team.
One day, Michael Jordan walks into the gym during practice and asks to join your team. Both of your assistant coaches happen to be away for the week, and you have an important game this weekend. You can’t stick to your process and add Michael Jordan to your roster in time for the big game. Would you tell him to come back when your assistant coaches were available in a week?
A product manager treating the roadmap itself as the goal is like that basketball coach treating a tryout process as more important than welcoming MICHAEL JORDAN (!) onto the team.
The Risks of Treating the Roadmap as a Promise
As a product manager, your objective is to solve problems for your market in ways that generate profits for your company. The products you release are only a means of achieving your ultimate goal of bringing in revenue by solving customers’ problems. And your product roadmap is only a means of helping your company build and launch successful products.
Many product managers fall into the trap of viewing the roadmap itself as the end goal. After they’ve shared the roadmap with stakeholders, these product managers feel the need to deliver everything on the roadmap. To do anything else, they worry, will make them failures. Or worse, liars.
Accomplishing everything on your roadmap is not your objective as a product manager. If you fall into thinking that way, you expose your company to several strategic vulnerabilities. Here are a few examples.
You could be working toward a strategy that’s no longer viable
Product development takes time. As a product manager, you’ll often find that changing circumstances force you to pivot your strategy during the long process of bringing a product to market.
Imagine a competitor releases a product similar to the one your team is building. You can adjust your strategy and refocus your minimum viable product on a different market segment or on solving a slightly different problem. But if you’re feeling accountable to your current product roadmap, you won’t be able to weigh these essential strategic options.
You could miss a valuable business opportunity
There’s a flipside to the hypothetical we just discussed. What happens if you’re so rigid about carrying out the details of your roadmap that you’re unable to shift strategies when you spot an opportunity to capture new markets or new revenue?
Say you’re working on enhancements to your product when a competitor suffers a public embarrassment with a product similar to yours? Someone discovers a significant security vulnerability. Many of that competitors’ customers, particularly in a few regulated industries, contact your company for an alternative. Your product doesn’t have the needed security features, but you could develop them quickly if you adjust your priorities.
If you feel boxed in by the roadmap you’ve shared across your company, you could miss a significant opportunity to capture a new market and generate new revenue. Instead, you’ll be stuck completing minor enhancements, likely bringing in little new revenue.
You could lose the trust of your stakeholders
Insisting on sticking with your current roadmap priorities, even if circumstances change, can also undermine your team’s faith in your abilities.
Your role as a product manager includes making difficult strategic decisions to benefit your company, product, and customers. Suppose it becomes clear to your team that your rigid commitment to a roadmap plan is forcing the company into strategic missteps. In that case, you could lose those stakeholders’ all-important confidence and trust.
5 Ways to Make Your Product Roadmap Plan a Reality
When you draft a product roadmap, you can never be sure you’ll be able to execute exactly according to that plan. Company priorities change, and budgets change. Market opportunities and threats arise unexpectedly. Many circumstances out of your control could necessitate changing your roadmap.
But even if the product strategy you build into your original roadmap remains viable throughout the development process, you’ll want to follow some proven techniques for turning that roadmap plan into reality.
1. Make sure your team is aligned on strategy
When you’ve developed your product roadmap, you’ll want to share it with your key stakeholders in engineering, sales, marketing, customer success, the executive staff, etc.
Communicate to these stakeholders both what you’re planning to build and why doing so is a smart strategic plan. The more clearly everyone understands both the what and the why, the greater your chances of the whole team steering in the same direction.
2. Explain the plan vs. promise distinction
A key part of aligning your cross-functional team includes letting them know that the plans on the roadmap represent your current strategy only.
You’ll want to make that clear from the start of a new project that everyone needs to be open to the possibility that plans and goals can change. You’ll also want to tell your team that if you do need them to pivot, you’ll be there to explain why the changes are necessary and what they’ll mean for the product.
If you don’t clarify this, your team could easily fall into the same trap we’re warning you to avoid. Unless you tell them otherwise, your stakeholders will have every reason to assume the roadmap represents the final word on priorities, strategy, and resource allocation. Then, if you need to pivot your plans, you’ll find more resistance and reluctance from your team.
3. Stay in regular communication with your stakeholders
Because the product development process can take a long time, with teams across the company focusing on their tasks, it’s easy for stakeholders to lose sight of the big-picture strategy. Here’s where you come in.
Hold regular communications with your cross-functional team. Keep them up-to-date on the product’s progress and any new developments that could affect their work. Invite them to come to you with questions or concerns. Encourage communication among different teams working on the product—such as between marketing and sales—so that these teams feel more comfortable sharing knowledge with their coworkers.
Note: Communication across your company is especially important when something changes on the roadmap. You will want to create a process to keep all stakeholders informed about any roadmap updates.
For example, ProductPlan’s roadmap app integrates with Slack to ensure that anytime someone makes a change to a roadmap, all relevant stakeholders receive a notification through a dedicated Slack channel.
4. De-emphasize dates in favor of timeframes.
It’s worth reinforcing our main point once more. Your roadmap represents a window into your strategy, not a guaranteed delivery of a specific thing by a specific date.
One way to underscore that distinction for your team is not to place dates on your roadmap. You can build a roadmap that groups epics and themes into broad timeframes. Quarterly, for example. You don’t need to add deadlines for each roadmap initiative.
If you treat the roadmap as a commitment, your team is more likely to feel that same pressure. That’s another strategic risk. It could mean your team focuses on meeting a deadline rather than taking the time to build functionality in the way that will best serve the user.
Before you commit to completing work by a calendar deadline, you should think through an important strategic question: Do we even need roadmap timelines?
5. Hold yourself and your team accountable.
Finally, you’ll want a mechanism for keeping yourself and your coworkers on other teams accountable for making progress throughout the product development process.
Some companies create a Product Council meeting schedule. These are regular sessions involving representatives of various teams (sales, marketing, product, development) presenting their previous month’s progress to a member of the executive team.
Product Councils are great because they act as a forcing mechanism, encouraging all teams to make as much progress as possible on their responsibilities. Anytime in the development process, each team knows it’s no more than a few weeks from being asked to share its progress with a senior manager.
Treat Your Roadmap as a Current Best Guess
If you’ll allow us one more metaphor, let’s think for a moment about an actual roadmap for a long-distance trip by car.
Say you type a destination address into Waze or your smartphone’s native mapping app. The app brings up a route. It’s the fastest way there, according to traffic trends. You get on the road and follow those directions. But along the way, an obstruction on the highway forces the app to recalculate your best option, and it sends you on a detour.
Question: Did the app fail? Of course not. The app started with the best available information, set a plan, and then quickly changed course—literally—when circumstances suggested the original plan was no longer viable.
The same is true for your product roadmaps. They represent your current strategic thinking and a chance to share that thinking with your team. That’s all they are. When your strategy needs to change, no problem. Change the roadmap to reflect your new plan—and share that plan with your team.
