When working with clients, one topic that comes up frequently is product roadmaps. As a product manager at LinkedIn and director of product at Degreed, I kept the best practices and tips based on what worked for me and the hard lessons I learned.

A product roadmap is a strategic communication tool that helps teams make better decisions faster.

When done right, it answers three questions everyone asks:

  • How do I move this project forward?
  • How do I get everyone on the same page?
  • How do we get the team moving quickly?

Why Most Roadmaps Fail

"Product roadmaps should come from this idea that you're actually obsessed with the customer, that you're looking to solve the problems that your product is supposed to solve for them in a way that's better than any other business or product or solution or alternative in the market."

Hiten Shah

ProdPad describes a good product roadmap as "visual, clear and accessible enough for everyone involved to understand."

This is critical because of the complex nature of products. Products have many teams involved, a high degree of uncertainty, and the potential for high costs.

Kris Gale, VP of Engineering at Yammer, wrote about the high cost of complexity:

"Among the most dangerously unconsidered costs is what I've been calling complexity cost. Complexity cost is the debt you accrue by complicating features or technology in order to solve problems."

Unfortunately, many roadmaps are too detailed, confusing, or outdated. They function as tactical release plans, and teams get lost.

I like what Melissa Perri has to say on product strategy:

"Most companies fall into the trap of thinking about Product Strategy as a plan to build certain features and capabilities. The problem is that when we treat a product strategy like a plan, it will almost always fail."

What Every Product Roadmap Needs

So how do you actually build a roadmap that is clear, simple, and effective? You only need three sections: why, what, and how.

Section 1: Why (One Sentence)

"Why are we building this product?"

I encourage teams to simplify this into a single customer-focused sentence, and then add some context if needed. A 3x3 walkthrough is one approach we advocate.

This one sentence is powerful. Everyone can understand it, buy into it, and talk about it in a way that is clear and compelling.

Section 2: What (Outcomes, Not Features)

The "what" section of your roadmap answers questions such as, "What outcomes do we hope to drive because of this product?" and "What do we hope changes because of this?"

I recommend including both quantitative and qualitative data to inform this section. For example:

  • What do you want users to do?
  • What do you want users to feel?
  • What do you want them to think?
  • What do you want them to say?

When defining "what," most people focus on outputs (or features) way too fast. Instead, define the real business value you want your product to drive.

Section 3: How (Themes & Horizons)

Organize work into 4-6 themes—big buckets of related work.

Examples of themes can include search, browse, email notifications, mobile app, landing page, onboarding, payment, database, settings, tech infrastructure.

Then add time horizons:

  • Now: What we're actively working on
  • Next: What we're exploring and validating
  • Later: What we're considering but not committed to

While months or quarters seem ideal, they can trap you in commitments to release that you aren't ready to make. It is better to use more generic terms and talk through the current desired timeline with the caveat that timing is subject to change. This is a balancing act that depends on your needs, company culture, and other factors.

As an example, if "search" is a theme and our product doesn't have this functionality, we could break the timeline down like this:

  • Current goal: Add basic search -or- Enable users to search articles
  • Near term goal: Enable users with basic filtering
  • Long term goal: Enable advanced filtering

A disclaimer at the bottom of this section is critical so that those consuming and using the roadmap realize this isn't set in stone - it reflects the current direction of the team.

Product Roadmap Template

See how we're using a product roadmap for our partner interviewing and onboarding process.

Why This Works

With a visible strategy, it can be questioned by everyone in the process (executives, designers, developers, partner teams) and improved from the ensuing conversation.

How to Make Your Roadmap Actually Work

Design sprints (originally developed at Google Ventures) are one way you can test this up front and avoid wasting time and energy on the wrong problem or solution.

But in order to do this, you must talk to your customers. Learn how they use your product and understand what they want. Join sales and support calls.

Use the priorities in your roadmap as a guide for your backlog. This method helps keep me sane, especially when product groups have a backlog that increases from 10 to 20 to 50 to 100 items. I have personally managed a backlog with 600 items in it.

But no one can realistically manage that, and it becomes useless.

As you learn, adjust. It should be adjusted and updated continually, and that requires continually making sure people are aligned.

The simplest way to know if you've communicated it well is to ask someone what they think the strategy is. Their response will tell you everything you need to know about how well your team is centered strategy-wise.

Strategy isn't just what you have written down somewhere. It's what everyone remembers and uses to make daily decisions.

Other great resources you might enjoy: