“Why are we doing this now?”

“What are we doing next?”

“What’s the actual plan?”

These are all questions that, as a product manager, you might hear from anyone in your organization, from sales to engineering. And yes, it can be frustrating. As Braden Kowitz points out, these questions can cause a great deal of anxiety.

One way to get ahead of them is to create a product roadmap that not only communicates the product plan but also aligns your whole organization around it. Useful product roadmaps can take time to create, but they also give stakeholders on different teams insight and ultimately boost their confidence in your product leadership.

The challenge is building a roadmap that will align your company around your product vision.

Often, companies will go about building a product roadmap the wrong way. They’ll focus on hitting deadlines above all else, which can cause a lot of anxiety for the team. One of our customers told me it was like being held hostage by your roadmap.

Sometimes you’ll see companies build a roadmap once and then never look at it again or rarely update it. That’s a sign that the organization is just building features based on whoever is yelling the loudest.

Other companies build roadmaps that are so in-depth that no one can understand the vision for the product.

Essential pieces of a product roadmap

The goal of your product roadmap should be to articulate your product strategy in a way that’s understood by everyone. Before diving into specifics, I always like to take a step back and remind everyone that what works for you may be unique to you and your organization. That’s why it’s critical to talk to everyone across the teams and make sure you’re all aligned on the best way to present this information.

There’s a lot of advice out there about what to include in your roadmap, but in the spirit of keeping it informative enough to be useful and simple enough to be accessible, we think you should primarily focus on the following three.

Timeline

You don’t need to list specific dates on your roadmap. But you do need a way to clearly outline and prioritize short-term features, medium-term features, and features you’re planning for in the long term.

Example timelines:

  • Q1, Q2, Q3
  • March, April, May
  • Now, Next, Later

Features

What features are you releasing along the timeline above? You can categorize these based on what you’re looking to communicate and what tools you use for project management. These can be simply stated as the feature you’re building, or you can create a hierarchy of broad feature themes down to more specific subfeatures.

Examples (from high-level to detailed):

  • New user onboarding, Team collaboration, Video messaging
  • Create user signup flow, Share files between teammates, Record video calls
  • Implement SSO, Integrate Dropbox, Share saved video files

Goals

What are you looking to accomplish with your products and features? You’re not doing work for the sake of doing work. You’re moving the needle on your business. Goals (or objectives) lets your organization know where the product is headed. These may be product-specific goals or business goals.

Examples:

  • Improve team communication platform
  • Launch dashboard analytics
  • Increase monthly active users by 5%

Types of product roadmaps

Let’s look at some common types of product roadmaps to help you figure out which one will work best for you. These are essentially the elements described above shown in different views. You should choose which of these views best supports the way you want to communicate and rally your organization around your product vision.

The first two are examples focus on how to communicate the features you’re delivering, and the second two focus on communicating the timeline.

Feature-driven product roadmap

The most straightforward thing you can do is list out the features you plan on releasing. However, to provide more context for these features, you can show these features based on a hierarchy that shows your features in context with one another.

The power of this level of information is that more people across your organization can easily understand it instead of looking at a laundry list of features. This view begins to tell a clear story about what you plan on delivering. Features are attributed to higher level themes, making it clear what those features will provide in the context of a broader plan.

This level of structure lends itself easily to often used categorizations, including epics, stories, and tasks, which can be helpful if the biggest consumers of your roadmap are engineers and project managers.

Objective-driven product roadmap

The key piece of information missing in the feature-based roadmap is the why. The objective-driven product roadmap ties your features to objectives, which makes it easy for anyone to understand why each feature is being developed.

When using business-level objectives, this offers a clear connection between your product and business strategies. Someone might ask, “Why are we doing Feature X instead of Feature Y?” With other roadmaps, your answer may be tougher to answer. But with an objective-driven product roadmap, you can clearly show that Feature X directly ties to your company’s business objectives.

objective based roadmap

A customer of ours told me how using an objective-based roadmap was eye-opening for his team. He wanted to motivate his developers by showing how the work they were doing would move the actual business metrics. He said, “So things like ‘new onboarding workflow’ wasn’t just some feature. But it was actually going to help get us to our target monthly revenue faster.”

Time-based product roadmap

These next two roadmap views focus on the timeline. Time-based roadmaps focus on all of the features that will be coming in each product release in a general time frame. This can be helpful for teams, such as marketing, to organize activities around releases.

Be wary about using tight time frames as this can set burdensome expectations. At a company I previously worked at, we just kept shifting releases to the next set of dates. This is when roadmaps become more performative than useful, and you want to avoid this as it can lead to lower confidence in the product team.

Consider using a time frame that works best to communicate your plans broadly. This may be monthly, quarterly, or any bucket of time you think works best for your needs. You also don’t need to maintain a consistent timeline to help organize features you plan on delivering in the long-term.

release based roadmap

Now-Next-Later product roadmap

For agile teams, the now-next-later roadmap can be a great way to understand what’s being worked on right now and what’s coming up.

now next later roadmap

This view provides detailed near-term insight into what’s coming next. Typically, features in the ‘Now’ slot have more detail as they’re being worked on and features in the “Later’ bucket will likely be a bit more high level and can reflect your long-term strategy if you set it up correctly. This can be especially helpful in more engineering-focused organizations when the release cycles are generally understood.

While this view is great for organizations that move quickly, you’ll want to make sure your prioritization process rigorously keeps things on track. What can happen is that things in Later stay in Later indefinitely while new ideas that are disconnected from the long term strategy make their way into the Now or Next buckets.

Getting to where you’re going

Product roadmaps are critical for your success. Creating a great product without a roadmap is like going on a road trip without a map: if you’re lucky, you might eventually get to your destination, but it’s pretty likely you’ll end up in some run-down motel. You’ll also probably have to stop a bunch of times to ask for directions from people who had no idea what kind of trip you initially planned. Unlike road trips, product roadmaps are all about the destination, not the journey.

Monty Mitra May 31, 2019