A Guide to Assembling a Product Roadmap

Why Do Product Managers Assemble a Roadmap?

As a product manager (PM), you need to know where you are, where you’re going, and what needs to be done along the way.

A good PM moves fluidly between the resolutions of now, next, and later to avoid getting stuck in tactical execution.

But, product managers are tired of spreadsheets, presentations, and wikis to communicate their product vision. They want to convey the big picture but are stuck in the weeds. You might relate to the struggles below:

• Spreadsheets are great for organizing and prioritizing but bad for communicating a vision
• Presentations take time to produce and are static documents that are hard to share
• Wikis and other documents are disjointed and hard to keep updated
• Getting company alignment is an uphill battle
• There is rarely a single source of roadmap truth

In that sense, a good product roadmap is a polestar for product teams. It keeps us connected to the longer-term vision so that we don’t get lost in the day-to-day. It’s the strategic counterpart to task lists and opportunity backlogs.

A Step-By-Step Guide to Assembling Your Product Roadmap

1. Collect Inputs

We start by collecting inputs. Inputs come from different sources. Customers are constantly giving their input. We’re gaining insights and gathering information from our key internal stakeholders (like the sales and marketing teams), as well as key external stakeholders (like our investors). We have to collect data and analyze that data. We’re looking to our competitors, both existing and new, and we’re looking to the cultural landscape and the technology trends that are emerging.

All of that information is coming at us constantly, and as we gather it, it forms the foundation for our plan of action, which is what the roadmap really is.

2. Establish Objectives

Once we have collected our inputs, we need to parse the information into clear objectives. Objectives may be set for the company itself, for the department that we’re working in, for the specific product that we’re involved with, or even the specific feature that we own as part of that product team.

Objectives are broad, ambitious goals that can inform meaningful discussions about what kinds of projects or releases might actually realize those goals.

3. Determine Outcomes

A core tenet of Agile is “outcomes over outputs.” The objectives we establish are only as good as the impact we expect them to make (to our customers, to our business, to our future). Determining outcomes helps us set and prioritize the right objectives.

4. Measuring Outcomes / Iterating

As (and after) we execute our planned roadmap activities, we should be measuring the actual outcomes of our work. Those results become new inputs to inform the process. This is the cyclical nature of roadmapping.

Roadmap Iteration Frequency

Different organizations iterate on their product roadmap at different intervals. Some teams might update their roadmap quarterly or every couple of weeks. Early-stage startups experimenting their way to product-market fit typically don’t even roadmap beyond six months into the future.

By contrast, enterprise organizations and hard product manufacturers may be working with five or seven-year-long roadmaps.

Whatever the frequency, however adaptive the team, the contents of a roadmap are highly subject to change, but the process remains relatively constant.

Vision

Before you can establish objectives, you have to have a vision. It’s altogether possible, depending on where you are in your own product lifecycle or at what point you joined the current team that you’re working on, that you may be inheriting a product vision that’s already been established by the company, or it may be incumbent upon you and your team to help reinvigorate that vision.

If you’re a founder or product manager in a new startup, you may very well be part of the team that’s trying to establish the product vision.

The product vision is like an umbrella that spans over the top of the entire roadmap. It’s the ultimate state of being we are perpetually working toward.

There are a few really great techniques you can try for determining your product vision:

1. Press Release Format
2. Elevator Pitch
3. Vision-Box
4. Magazine Review

These exercises may seem corny to some, but envisioning is a necessary process for going beyond granularities toward big-picture thinking.

At 100 Product Managers, the vision is to become the most beloved place to gather product managers in community and conversation. Today, we’re articles, and we’re podcasts, and we’re free tools, and we’re resources, but the vision that stretches out over our entire roadmap is to create a robust community of highly engaged individuals sharing ideas and supporting each other.

Annual or Quarterly Themes

Months and years are the temporal increments that help you realize your vision by tackling it in smaller bits. We call these smaller bits, themes.

Establishing themes is a powerful way to get entire teams or departments sharing the vision. And for that exact reason, themes should generally be succinct and actionable so that people can get excited, not confused. I like to think of themes as locker room cheers. Short sentences that end with exclamation points and result in teams charging the field.

In his book, Mastering the Rockefeller Habits, Verne Harnish sets up a really simple framework for both establishing and limiting roadmap themes. He suggests that for any given period you should have one internal and one external focus, and not more.

Obviously these rules can change depending on the scale of the organization, but in general, the practice of limiting themes is important for promoting focus.

External themes drive outbound efforts. Some examples are “get funding!” or “keep employees!” or “drive referrals!”

Internal themes drive operational behaviors. Some examples are “better production!” or, perhaps, “cheaper production!” or “improved process!”

Whereas the product vision is highly unlikely to change from year to year, or even at all (if it’s big enough), themes should change annually and quarterly. Themes create the bedrock of your roadmap.

Mapping Projects to Themes

Once you have determined the annual and quarterly themes, you can begin to map your planned releases, projects, or initiatives to those themes, or brainstorm new ideas out of those themes.

Mapping your initiatives will help you better identify those projects which are just simply out of focus. However, most organizations don’t suffer from too few planned initiatives. If your initiatives are starting to pile up, this is a good opportunity to leverage a prioritization framework such as 2×2 grids or weighted scoring to further eliminate low impact ideas.

In my opinion, it doesn’t really matter what framework you use for prioritization, so long as you use a framework. What I’ve discovered in working with teams, is that nothing deflates morale more than a seemingly arbitrary process of prioritization, which doesn’t typically foster good team relations.

So pick an approach, establish and agree to it with your team, and release the low priority ideas from purview. Now is the time to execute!

Backlogs are not Roadmaps

Some organizations refer to their product or opportunity backlogs as their product roadmap.

A backlog or a list of feature ideas inform roadmap planning, but should not be confused with a true product roadmap. Bottom-up tactics don’t typically lead to a coherent upfront strategy.

If you’re using great tools like ProductPlan for your road mapping and Pivotal Tracker for your software delivery process, you can integrate them together and easily “telescope” (a term that I like to borrow from Amazon’s Jason Meresman, which describes the act of switching focus between present and future) between your backlog and roadmap while keeping progress in sync on both sides.

Measuring Outcomes Using OKRs

Themes and initiatives give direction and priority to our roadmap but generally fall short in providing quantitative or qualitative measurements for assessing outcomes.

This is where the OKR framework can help. OKR stands for Objectives + Key Results. OKR is a syntax for goal setting that anchors broad, ambitious goals (objectives) to specific measurable outcomes (key results).

Here is some example OKRs:

• Objective: Widen the appeal of the product!
• Key Result: Increase new registrations by 10%

• Objective: Create a best-in-class experience for our vendor partners!
• Key Result: 50% adoption rate for online vendor orders

• Objective: Become a better product manager!
• Key Result: Attend 3 product management workshops in Q4

The idea behind OKRs is to define a way for the team to understand (and share in the understanding of) where the finish line is. OKRs tell us how we will know when we have accomplished our objective and when it’s time to set new targets.

If you’re keen to learn more about the concept, I can’t recommend a better book for understanding OKRs than Christina Wodtke’s Radical Focus.

Best Practices for Documenting and Sharing Your Product Roadmap Guide

So you have a roadmap, you’ve defined your OKRs, and you’ve established a shared understanding. There’s one more piece that you need, and that’s actually sharing the information with others.

In fact, one of the biggest reasons roadmaps fail is because most people in the organization never get to see them.

Good roadmaps:

• Are easily shareable
• Are easily refactored
• Provide transparency

Remove obstacles to change (which is inevitable when roadmapping) and embrace tools that make your roadmap easy to share, update, and access.

Timelines

Keep your timelines high-level. The roadmap is usually the worst possible place to make specific commitments like, “Yes, go ahead and put in that media buy,” or “Yes, go ahead and take out that loan,” or “Yes, go ahead and hire that whole new developer team.”

Because when we’re roadmapping, we’re in the widest part of the cone of uncertainty—usually out in front of project details by several weeks or even by several months. For that reason, we want to keep projects and timelines high-level and conservative across larger slots of time.

In fact, some organizations remove specific timelines altogether in favor of the Kanban approach, which really means, “We’re working on what we’re working on until it’s finished, and then (and only then) will we work on whatever is next.”

Regardless of format, resist the temptation to use roadmaps for providing absolute deliverables, and instead use them to communicate the direction.

Why Do We Assemble a Roadmap?

So what are some uses for a product roadmap?

1. Share the product vision and tell the world where we’re headed.
2. Identify possible resource gaps…in advance!
3. Communicate when certain features are going to be released. This is super helpful for sales and marketing teams that are busy trying to grow and maintain customer interest.
4. Declare End of Life plans. Google is notoriously bad at this. Microsoft is great at it. Be like Microsoft.
5. Indicate when a new market segment is going to be addressed, for creating shared understanding amongst teams, and for getting buy-in from stakeholders.
6. Keep outside partners informed.

Takeaways

Roadmaps start with inputs, which we collect from various sources. Then, inputs lead us to a series of annual and quarterly themes, which can inspire many epics or project initiatives. You should prioritize releases based on impact and made measurable using accountability frameworks like OKRs. If you’re new to product management or the process of roadmapping, you may discover that roadmapping is hard.

Roadmapping is a highly strategic kind of exercise. It’s business-driven and necessarily holistic. If most of your experience to date has been in coordination roles, or you’re an associate product manager, or you’re new to the process, or you haven’t really been invited into the “war room,” a lot of you may struggle to try to put all these pieces together.

That’s ok. Know that it’s to be expected. Let yourself off the hook and consider this advice: Sign up for a free trial of ProductPlan. Use it to build a roadmap for your own personal or career goals. Bookmark this article and revisit it as often as you like. Practice. Trust the process.