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.
But people rarely ask, “How do I build a product roadmap?”
Instead, I hear questions like:
- How do I move this project forward?
- How do I get everyone on the same page?
- How do we get the team moving quickly?
The answers to these questions start with building an effective product roadmap.
Why You Need a Product Roadmap
Before we go into details on how to build an effective roadmap, let’s start with why you need one.
Done well, a solid product roadmap helps you focus on what is most important. This starts with customer obsession.
“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
This is where product managers come in.
As you focus on the customer, what problem you solve for them, what pain you alleviate, you need to bring others along.
Product managers balance relationships with executives, their team, customers, and more. They are asked to lead, make decisions, and communicate across teams.
With this environment, a product roadmap achieves three key results for you and your organization:
- Simplicity
- Clarity
- Current information
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. Communicating simply and clearly in this environment is a must.
Kris Gale, VP of Engineering at Yammer, wrote about the high cost of complexity and its challenges.
“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.”
This is why the best product roadmaps have two key characteristics.
They are used as strategic communication documents. They help teams make decisions about what they will and won’t do sooner (before committing to costly solutions).
Second, they are living. This means they are updated often to reflect a current state of the product direction. It also means everyone who views the roadmap understands it is subject to change.
A living roadmap used as a strategic communication tool enables your team to stay aligned and make better decisions.
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.”
A product strategy that is only a release plan will fail.
To avoid this, here’s how to make a clear, concise roadmap that guides you and your team effectively.
What Every Product Roadmap Needs
So how do you actually build a roadmap that is clear, simple, and effective? I teach managers (yes, this goes beyond just product managers) they only need three sections: why, what, and how.
Download Our Free Product Roadmap Template
See how we’re using a product roadmap for our partner interviewing and onboarding process.
Section 1: Why
This section answers the question, “Why are we building this product?” This is the big vision, the mission, and/or the purpose (those are different things, to be discussed in a future article).
You want to find a balance between being very aspirational (e.g. solving world hunger) and overly tactical (e.g. “The CEO told us to do this”).
Unfortunately, many people skip this step or lose sight of it. They include so many details that everyone forgets why they’re making it. I encourage teams to simplify this into a single customer-focused sentence, and then add some context if needed.
A 3×3 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
Product roadmaps are outcome-driven. Backlogs and release plans are output-driven.
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?”
These are the business objectives that your product will help accomplish.
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. This allows your teams to understand the strategy more clearly and better involves partner teams like sales and marketing in your product’s long term success.
Section 3: How
The last section is how which breaks down into themes and timelines.
I have found the best number of themes is 4-6. These categories simplify the different pieces involved and help your team understand them. They also help guide your priorities and backlog.
Examples of themes can include:
- search
- browse
- email notifications
- mobile app
- landing page
- onboarding
- payment
- database
- settings
- tech infrastructure
Once you have your themes, you want to decide on a high-level timeline. Three categories I recommend starting with include current, near term, and long term.
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
This helps all teams know which features are coming at the highest level and when.
For example, when your salespeople talk with customers, or support teams check in with developers, this simplified timeline becomes invaluable.
Note: 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. This is also why current, near term, long term are good timeline categories, rather than exact dates or quarters. It helps communicate the ever-adjusting nature of the themes and timelines.
Download Our Free Product Roadmap Template
See how we’re using a product roadmap for our partner interviewing and onboarding process.
Why this Model is Effective
As mentioned above, some main challenges with products are:
- complexity
- uncertainty
- cost
It’s easy to jump to a solution too soon or overwhelm people with too much information. But building a product roadmap is more than categorizing information.
The model we’ve laid out for you also improves communication, sets clear expectations, and enhances productivity.
People from all teams can wrap their heads around the product. The summaries make it easy to digest. Regular updates keep it current. All teams and executives have clear expectations about the general timeline. Developers and designers know what is expected of them and can identify which pieces are missing.
With a visible strategy, it can be questioned by everyone in the process (executives, designers, developers, partner teams) and improved from the ensuing conversation.
And most importantly, using a product roadmap as a strategic tool empowers your team to become truly agile (in mindset and mechanics). People can ask critical questions, shift their focus, and make better decisions on where to spend their time.
3 Mistakes to Avoid
With all that said, knowing what not to do is just as important as knowing what to do. Here are the three most common mistakes I see people make when creating a product roadmap.
Mistake #1: Including too much detail
The main problem here is the product roadmap becomes too complex. There are so many details that teams can’t get through it quickly. Sometimes the roadmap is a 40-page slide deck, and no one can concisely relay the purpose of the product.
This is how I know teams have strayed away from a useful roadmap and created either a run-on sentence of a roadmap or a release plan. They have skipped one of the most important parts—simplicity—and their people can’t digest the information.
This usually happens because teams don’t have the discipline to say no (which causes run-on product docs), or they center their thinking around solutions too early in the process (and end up with a release plan).
Mistake #2: Not defining clear priorities
Another mistake I often see is not including clear priorities. The themes and timelines are not well-defined, and communication is poor. People have unrealistic expectations on what can get delivered and when.
I often see vision decks that include dozens of priorities. When asked, “Which of these is most important?” the answer is typically, “Well, they are all important.”
If everything is important, nothing is important.
This is why I recommend a 1-2 page document with clear, useful themes and timelines.
These let everyone know what’s currently being working on and sets expectations for the future.
Mistake #3: Focusing on solutions instead of problems
A final mistake I see often is focusing on solutions instead of problems. We can get married to solutions way too early and focus on shipping features fast.
But teams should always start with problems to solve.
If you become obsessed with a problem vs. a solution, you can say, “Look, I don’t care how we solve it. I just want to solve the problem our users have.” It’s a much better place to be in, and it opens teams up to greater learning and openness to new possibilities.
As a product manager, this also empowers you to defend your product roadmap—your why, what, and how. It enables you to get people excited and bought-in. You can iterate on solving the right problem and create value for customers and the business.
Setting Your Roadmap Up for Success
Even if you follow all the steps above, you still need a strong foundation. A critical component to your product roadmap is the data that informs it.
Without data, it will be hard to make good decisions and get buy-in from everyone involved.
Here are five steps you can take to make sure you have the strongest foundation possible for your product.
1. Talk to Your Users
Product managers are champions for solving valuable problems for real users. It’s not always the easiest or most exciting problem, but it should be the most impactful. People pay for products that solve real problems, so this step is critical.
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. Keep yourself updated and build a regular habit of learning from them.
It’s easy to get out of this habit when you are busy with meetings and conversations with stakeholders. But fostering these relationships with users on a regular basis is one of the most important responsibilities you have and will serve you well in the long term.
2. Gather Data
Next, consider what data you already have. What information from market research, historical sales data, or customer behavior is available?
As you continue chatting with users, track this information. Gather relevant data, conversations, and other metrics.
Talk with your executives and learn how they make decisions. Get their input and understand their goals, objectives, and insights. Many of them interact with customers every day and have a unique perspective.
Gathering this information will empower you to make critical strategic decisions. You will be equipped with more than your intuition, and you won’t be subject to the opinions and whims of everyone involved.
3. Align Key Stakeholders
Equipped with data, you can start capturing it and reflecting it back to key stakeholders. This allows you to start aligning your goals and get buy-in.
For example, after you write down your one-sentence vision for the product, go to the CEO or head of product. Ask them, “Is this accurate?” Share your conversations with customers and why you think you’re building the product. Give additional context, metrics, and what outcomes you hope to drive.
Because you have written it down and gathered data first, it will be easier for them to react. They can offer feedback, ask questions, and have a specific conversation with you. You can identify key areas where you are not yet aligned and address them.
Then, when it’s time to get alignment on the full product roadmap, you have already resolved most concerns. You can confidently say, “Here is the roadmap, and I think we’ve all agreed on it. What questions do you still have?”
But whether or not you use a sprint to get this initial alignment, roadmaps still require ongoing work. It should be adjusted and updated continually—and that requires continually making sure people are aligned.
4. Tie Your Backlog to the Strategic Roadmap
Now that you have articulated why your product exists and aligned your teams on the roadmap, it is important to make sure your backlog reflects this.
There is a lot I could talk about here with how to prioritize your backlog and incorporate user stories. It is a complex process, and everyone has different ways of doing it.
But one tip that really helps me is this — use the priorities in your roadmap as a guide for your backlog.
For example, breaking down the stories for the current prototype or sprint will be much more helpful than getting into details further down your backlog.
If you start breaking down the stories you plan on using later, you end up wasting a lot of time and energy. Realistically, when you are ready to address those features, everything will have changed. Your priorities may be different because you will have learned and adjusted through the process.
One solution is to group stories based on your themes. You can then add some sub-themes and plan to break them out later.
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.
Tying the backlog to the main priorities in the roadmap helps alleviate this waste and allows for more flexibility.
5. Communicate Well (and Often)
Lastly, your product roadmap will only be successful if you communicate well and often. Agile teams are autonomous, self-organizing, and engaged—meaning they can’t rely on one person to tell everyone else what to do.
So great product roadmaps and product managers enable all teams—including designers and developers—to contribute what they have to the product in the best way. They empower every person involved at detailed levels to understand the vision and make informed decisions.
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.
In the end, a product roadmap done well enables agile behavior. This is because it’s not a release plan—it’s a strategic communication document.
Knowing how to create a roadmap, you’re ready to get alignment across your organization and empower your team.
Join my monthly newsletter where I share practical links and advice from what I learn about product and parenting. Reach out to me on LinkedIn or twitter and let me know how building roadmaps works for you.
Other great resources you might enjoy:
- “What is a product roadmap?” by ProdPad
- “We don’t sell saddles here” by Stewart Butterfield
- Product Roadmaps Relaunched, the best book on product roadmapping, which has helped me better create and use roadmaps.
- “Example Roadmaps for Product Managers” by ProductPlan