This is the third in an ongoing series of blog posts originally published on the UserVoice Product Management blog.

One of the constant tensions that product managers around the world deal with on a regular basis is creating product roadmaps that align with the expectations and needs of all of their stakeholders – particularly the management or executive team whose understanding and agreement is essential to executing against the plan presented.  Many of the issues related to obtaining alignment with your senior leadership lie in educating them about the reasons why we plan the roadmap the way that we do, the underlying assumptions about how we will execute that roadmap, and ultimately building a culture that is agile in its approach to definition and delivery against the vision and strategy of the company.

What is Your Product Roadmap Anyway?

Roadmaps mean different things to different people:

• Sales sees the roadmap as a projection of value that they can sell to their customers or use to show renewing customers that the company has plans that they can count on for the future.
• Marketing sees the roadmap as a tool that they can use to plan when, where, and how to push new feature improvements and to grow the sales funnel by targeting prospects who can benefit from those features.
• Finance sees the roadmap as a projection of future efforts that will result in some prediction of ROI against the development work that’s being done now to bring about that future.
• The CEO sees the roadmap as his guide to what the company will look like in 12-24 months, and as a signpost to assess the success of the company in meeting market and customer needs – which leads directly to increased investment or value for existing shareholders.

But for a product manager, a roadmap is more often an exercise in divination – trying to collate and collect all of the available information, all of the tactical goals within the organization, all of the strategic plans discussed among the executive management team, and all of the market intelligence they can get. Out of this hodgepodge of information, data, and opinions is supposed to come this perfectly-constructed prophecy regarding the future of the company and of the product.

But let’s be honest – none of us are the Oracle at Delphi, going into a fugue state while we commune with the Product Gods who imbue us with mystical information about what our customers will want and need in a one- or two-year time horizon.  It just doesn’t work that way, and just as software development has adopted a more effective approach to building product through agile development practices, we need to educate our stakeholders that the bad, old ways of defining product roadmaps as a list of features with specific dates assigned well in advance just doesn’t work in the modern world.

It really can’t be said any better than Marty Cagan does on his Silicon Valley Product Group blog:

[T]his entire obsession we as an industry have with features is hurting far more than it is helping, and if we want to fix this problem we have to stop it at the source which is typically these feature request driven roadmaps.

Feature-Based Roadmaps Don’t Work

Objects on the horizon may be larger than they appear. Why don’t feature-based roadmaps work?  The answer is really quite simple – we don’t know what we don’t know.  When we engage our product and market ESP to try to predict where we’ll be and what our customers will need in 6 months, 9 months, 12 months, or even 24 months, we’re really doing nothing more than creating an educated guess.  This, in and of itself, isn’t a problem – but the roadmap that comes from this guess is never presented as such outside the product management team.  Customers see it and create expectations; investors see it and form beliefs about how they’ll affect the return; and this continues ad infinitum.

As Rich Mironov observes in one of his several posts on improving roadmaps: 

[C]ustomers should understand…that all projects more than 6 months away are subject to change.  ‘Time-from-now’ is a good measure of speculative risk.

This applies, however, not only to your customers, but also to your internal stakeholders – from your development team to your services team, from your support team to your marketing team, and throughout the organization.  The most important thing that a product manager can do to establish buy-in and alignment from those within the organization is to educate them on the uncertainties that exist and explain how those uncertainties grow as you move further out in a time horizon – as you move from projection to prediction to soothsaying.

I generally advise people to use some systemic approach like the following, stated clearly within the roadmap presentation or even directly on the roadmap slide/graphic/visualization itself:

• 0-1 month = Work in Progress = We know this will be delivered, and can use data-driven projections to provide a high level of certainty on delivery times.  Rough confidence level is 90%.
• 2-3 months = Committed Work = We know what we currently view as the priorities on the backlog, and have broad estimates that allow us to predict likely delivery, subject to future discoveries.  Rough confidence level is 75%
• 3-6 months = Tactical Plan = We have a strong idea of the themes that we want to tackle in this time frame and are actively engaged in problem definition and solution proposals that will be estimated and backlogged. Rough confidence level is 50%.
• 6-12 months = Strategic Plan = We have a set of thematic goals that we believe are likely to be important to delivering on the stated strategies of the company, but have not moved to problem definition or solution proposals.  Rough confidence level is 25%.
• 12+ months = Vision = We are setting thematic areas that we believe will be valuable to bring our vision of the future into being, but have not engaged in full customer discovery, problem definition, or solution proposals.  Rough confidence level is 10%.

Making it explicitly clear not only what each segment of the roadmap actually means, but what the likely confidence level of any projections based on those items helps others understand and level-set against those themes or features that fall within the category.  And explaining how things become more clearly defined, more certain, and more predictable as you get closer to actually delivering them is essential to moving the culture away from the feature-based roadmap and toward a theme-based view of the future.

Don’t fall into the trap of specifying dates for anything that’s not already a work-in-progress or that isn’t well-defined and well-understood.  Any attempt to set a date for something that’s outside the 1-3 month time horizon is not only a mistake, but is bound to fail.  Even within that 1-3 month time horizon, you’re still taking a risk in doing so – remember the confidence interval, at 3 months you’re still never more than 75% certain of the scope, scale, or timeline for delivery.  Instill this discipline in your teams and in your stakeholders and you’ll be astounded at how much the expectations change for your roadmap in general.

The Plan is the Plan Until It Isn’t Anymore

There’s a classic military quote attributed to German field commander, Helmuth von Moltke the Elder: “No plan survives contact with the enemy.”  This is just as true for product strategy and planning as it is for military engagements – but for us, we have “enemies” to be found in both time and the market.  Any product manager who’s been in their role for any period of time realizes quickly that all of the vision, all of the strategy, and all of the roadmap work in the world falls apart when you start actually validating and executing against those plans.

One particularly effective tool that I’ve used in the past to encourage management tobecome more agile is to ask them about prior roadmaps and see where things have shifted over time, where a project has been “kicked down the road” multiple times.  When you dig in on this, you’ll likely find that it’s some pet feature or solution that never got started because there was something “more important” in front of it each time – if you hear that, you’ve almost won.  This is exactly what we do in agile planning, and what we want to do in building alignment against roadmaps in the future.  We just want to make it part of the process and not merely a reactive response to some new information.

Because of this, we need to have regular, structured reviews of the vision, strategy, and roadmap for the company.  We need to take some time every month (or quarter, at absolute worst) to critically assess what the company has stated as its goals, its objectives, and its plans for the future.  These sessions need to be interactive, and they need to be data- and customer-oriented.  They should not simply be “head-nodding” sessions where senior management pats themselves on the back for how right they were while ignoring the plans that shifted due to market realities.

As Jenna Bastow at MindTheProduct notes:

If you review your roadmap on a monthly basis, you can add extra granularity to the areas that are more impending, shift around deliverables based on what you’ve learned about your team, the technology and the market in the last month or so, and deliver a roadmap that’s subtly different, but not a massive change from what the team was already bought into.

Review often, review with purpose, and review with flexibility and scale in mind.

It’s Not a Plan If Nobody Knows About It

Roadmaps often wind up being the product of back-room negotiations and meetings that involve only the management stakeholders in the organization.  These artifacts sit on the shelf and are discussed during company meetings and team meetings as though they are some kind of stone-etched commandments defining what “thou shalt do” to the teams responsible for execution.

Such a lack of transparency into the process, the discussions, and the outcomes leads to a feeling of powerlessness and lack of input on those teams.  They often feel as though their efforts, their insights, and their opinions, are being entirely disregarded by the people making the “actual” decisions, which leads to morale issues.

There are really two problems to focus on here: (1) ensuring that everyone in the organization has access to the product roadmap, and (2) making certain that everyone in the organization has input into the product roadmap.  Assuming that we ourselves or the management team are the only ones who can represent the customer and can provide input and feedback on what’s important is a mistake that many rookie product managers make – and their products inevitably suffer because of it.

The primary reason we want the product roadmap to be visible to anyone in the organization is that it represents the plan of execution against the company vision and strategy.  This is something that everyone in the company has a stake in, and something that everyone should have a clear insight into – when the roadmap is “hidden,” the narratives about where the product is going, when, and why, are now outside of the control of the product manager and directly in the hands of the rumor mill, office grapevine, and subjective opinions of every employee not “in” on the plan.  As Dan Radigan of Atlassian puts it: “Post the roadmap online and keep it current so the team has a single source of truth.”  Having one location that’s managed by the product team provides that single source of truth for all questions, criticisms, and corrective suggestions from anyone in the organization.

However, equally important to the transparency in the outcome is transparency in the process.  Everyone in your organization, from the most junior intern working as an admin assistant to the elder system architect who was there from day one, has insight into your product, your market, and your company as a whole.  Not all of those insights will be genius, and not all of them will be actionable, but by ignoring, obscuring, or implicitly devaluing their input, you and the management team are taking a major risk of missing out on some insight that flips the tables and resets the plan. Often the most interesting, innovative, and creative problems or solutions come from the people you’d least expect.  Be open, be transparent, and be surprised.

Strategies for Achieving Organizational Alignment

Assuming that we have a transparent process, a transparent outcome, a flexible and thematic artifact, and regular reviews, there’s still often a question of how to drive to general consensus on what should be where, when things should become priorities, and how to “manage up” when we’re dealing with our roadmaps.  To this end, there are a few things that we, as product managers, can do as we’re preparing for the reviews and discussions, to leverage our leadership through authority.

Get Commitment Before the Big Meeting

Whether it’s roadmap discussions, strategic planning, or another major decision that’s going to require consensus or a group decision, it’s always important to make sure that you know the likely outcome before you walk into the room.  Meeting and reviewing your plans ahead of time with each major stakeholder allows you to gauge their response, anticipate their objections, and even make modifications before the meeting that will result in their agreement during the meeting. Knowing who the players are and what they want to get out of the discussion before everyone is in the room together is a solid strategy no matter what the discussion – but particularly important for roadmap planning.

Use Your Facilitation Skills

As a product manager involved in roadmap planning, we need to leverage every tool in our belt when engaging in meetings and driving consensus.  The absolute most important skill in these discussions is managing the meetings themselves – keeping people on-topic, keeping to the agenda for timing and topics, and pushing tangential conversations and discussions to other venues.  A roadmap meeting is not the place to bring up a new product feature or goal; that needs to happen before the meeting, so the required research can be done to vet and prioritize it appropriately.  A roadmap meeting is not the place to vent and point fingers at other departments for missing goals or deliverables.  It’s a place to verify the goals, prioritize the efforts, and ensure that as things move from less certain and less defined to more certain and more defined.  Know the goals, and ensure that people are moving toward them.

Educate As You Go

Even in the most nimble startup in the world, not everyone is going to understand the reasons that we as product managers do things the way that we do.  Not everyone is going to “get” why themes are more important than features, why prioritization is something that must be flexible and responsive to the market, and why individual opinions simply aren’t as compelling as actual customer data.  If we, as product managers, want people to agree to the things that we’re proposing, it’s on us to make sure that they understand why we’re doing these things, how we’re reaching our conclusions, and what drives us on a daily basis – and all of these things should center around our actual customers and market.