Why Do We Roadmap?
As a Product Manager, 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.
In that sense, a good 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 Creating Your Product Roadmap
Product roadmapping, like laundry, is an ongoing and iterative process. It’s not something that you cross off your to-do list.
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.
Collecting Inputs
We start by collecting inputs.
Inputs come from different sources.
We’re getting inputs constantly from our customers. 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’re collecting data and analyzing 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.
Establishing 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.
Determining 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.
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.
Vision
Before we can establish objectives, we 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 couple really great techniques you can try for determining your product vision:
- Press Release Format
- Elevator Pitch
- Vision Box
- 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, our 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.
These smaller bits are called 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 the annual and quarterly themes have been determined, 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. Just ask Johnny Cash.
If you’re using great tools like ProductPlan for your roadmapping 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 are some examples:
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.
Documenting and Sharing
So you have a roadmap, you’ve defined your OKRs, and you’ve established 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 direction.
Why We Roadmap
So what are some uses for a product roadmap?
We can use them to share the product vision and tell the world where we’re headed.
We can use roadmaps to identify possible resource gaps…in advance!
We can use roadmaps to 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.
We can use roadmaps for declaring End of Life plans. Google is notoriously bad at this. Microsoft is great at it. Be like Microsoft.
We can use roadmaps to indicate when a new market segment is going to be addressed, for creating shared understanding amongst teams, and for getting buy-in from stakeholders.
We can also use roadmaps to keep outside partners informed.
Bottom Line
This is the part where I tell you everything I just told you as quickly as I can, plus one thing I haven’t yet told you.
Roadmaps start with inputs, which we collect from various sources.
Inputs lead us to a series of annual and quarterly themes, which can inspire many epics or project initiatives.
Releases should be prioritized based on impact and made measurable using accountability frameworks like OKRs.
THIS IS THE NEW PART: If you’re new to product management or the process of roadmapping, you may discover that roadmapping is HARD.
Roadmapping is really a very 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 trying 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.
*This article first appeared as a guest post on the ProductPlan blog.
