TRENDING
Gain access to an ecosystem of thousands of product experts, colleagues and peers from around the world.
Complete the Pragmatic Data Maturity Assessment to see if you’re making the most of your company’s data. 
Determine your company’s strategy and be intentional in your design activities choices and recommendations. Think of the product roadmap as a guide to how you’ll execute your strategy. A product roadmap is a plan in which you’ll communicate the direction of your product and illustrate the vision and key phases of deliverables. It provides context for your stakeholders and communicates the why behind what you’re building. Ideally, it’s a high-level summary that helps product managers get everyone on the same page. Your product roadmap helps product marketing, sales, customer service and other key stakeholders align. But keep in mind: The product roadmap is a plan, not a commitment.
A product roadmap isn’t simply a list of features or the backlog. The roadmap needs to communicate the big picture—the initiatives that move the needle, expand markets, address competition and create customer value.
The product roadmap is much higher level than the backlog.
A product roadmap makes it much easier to get where you are going. As a product manager, product roadmaps are your No. 1 tool for communicating your vision and strategy for a product, allowing you to garner buy-in from key stakeholders. Think of it as the bridge from strategy to development.
Having a solid product roadmap will make your job infinitely easier down the line. Remember when your high school teachers used to make you turn in robust outlines before you started writing a research paper? A roadmap is kind of like that. It gives you direction and a huge head start on the next steps of product development.
The goals of a product roadmap are to:
Product roadmaps your No. 1 tool for communicating your vision and strategy for a product
A product roadmap shows the sales channel and our major customers where the product is headed and what features to expect in future product releases. Unfortunately, it also tells the competition. The competitor may ace your new features before your product hits the street.
And once a roadmap is published, it cannot easily be changed. More than one product manager has been shocked to see the roadmap stapled to a contract as an attachment. What began as a plan has now become a commitment. Many companies find that they need two roadmaps: one for internal use and another for external delivery. While this may be necessary, a better rule is “never print your roadmap.” Only the product manager should talk about a product’s future. A product manager may use the roadmap in a presentation but should never print or distribute the presentation.
Be prepared for this: Once you hint at the feature-set of the “blue release,” the sales channel will ask for a little more detail. Will it be Java? Will it also have reporting? Before you know it, they’ve dragged information out of you that you hadn’t intended to reveal. They will absolutely complain that they need more specifics, and then they’ll need demos, and then they’ll need an early copy to close a deal. Decide what will be communicated in your product roadmap and then don’t say any more.
Up until now, we’ve generally referred to product roadmaps in the singular. In reality, your organization and even your product likely will have multiple roadmaps that serve different purposes. Here are some of the more common types of product roadmaps:
Portfolio roadmap: This high-level plan is where you’ll map out the general milestones necessary to execute the strategy across an entire product portfolio. This type of roadmap is particularly helpful in illustrating how a different individual’s or a team’s contributions fit into the larger picture.
Strategy roadmap: Think of this as the initial roadmap you’ll build for a new product. It will communicate your strategy for the product as well as major milestones, core features and planned releases.
Releases roadmap: This roadmap, while still providing a high-level overview, gets more detailed with regard to product releases. It includes information such as what steps will need to get done leading up to a release and which individuals and/or teams will be responsible for them.
Features roadmap: This type of roadmap outlines the timeline for when and how certain product features will be released. Remember to keep dates general (think “Week 2” or “Q3”). The last thing you want is to be committed to specific dates on which you might not be able to deliver.
Theme-based roadmap: At Pragmatic, we recommend replacing the features roadmap with a theme-based roadmap. Instead of outlining specific features and when they will be released, the theme-based roadmap gives you more flexibility. Themes are similar product features, epics or initiatives grouped together according to a larger, strategic objective they share. For example, “Customers Complete First Purchase Faster” might be a theme that would be tied back to a measurable strategic goal. The theme-based roadmap lets you reprioritize without setting the wrong expectations for stakeholders.
Also, keep in mind that within these product roadmap types, you’ll also have various versions, depending on your audience. You’ll want to tailor your roadmaps to internal vs. external audiences, engineers vs. marketers, etc. The farther away an audience is from you in terms of working relationship, the less detailed the product roadmap should be. In many cases, in fact, you should keep your full, detailed product roadmap pretty close to the vest.
Remember to tailor your roadmaps to internal vs. external audiences, engineers vs. marketers, etc.
Now that you know why it’s important to have a product roadmap, it’s time to create yours. But not so fast. Actually, the most important part of the roadmap process happens before you begin building your roadmap. Setting the vision and strategic goals for the product—and, more important, getting alignment on these with your stakeholders—is the first step to creating a successful roadmap.
Know your product strategy when developing a strategy that ultimately leads to a product roadmap. It’s important to identify and articulate your product’s vision and principles—the why.
Spend time before you begin planning your roadmap determining the product’s mission, and then distill it into a simple statement your stakeholders can understand. This statement should include the product vision, the problems it solves, target customers and value to the marketplace. Documenting this forces you to nail down many of the key items that will inform your roadmap.
This strategy-first approach has several benefits. It makes it easier to articulate the product vision to any constituency across your company and ensures stakeholders are on the same page before you begin the detailed conversations that follow. It also allows you to more clearly identify priorities as well as items that should be set aside because they don’t serve the product vision.
From the product vision, you can derive product goals that will in turn influence the initiatives that are on your roadmap. Coming up with these outcome-based objectives helps you translate your product strategy into an executable plan.
Once you nail down your product vision, next, you’ll need to consult your specific product goals. These product goals have metrics assigned to them and are shorter-term, maybe one to two years out. You may utilize a north star metric model or have a handful of equally weighted metrics.
Metrics are ideal for guiding your product decisions and your product roadmap. Business goals such as revenue, margin, acquisition cost and retention are a great way to tie roadmap initiatives to your strategy. Customer-specific metrics such as product usage and retention are important as well if those relate to your broader strategy.
Now it’s time to start mapping. While everything you want to develop will be documented in your product backlog, you’ll need to prioritize initiatives for the product roadmap. We recommend using the value vs. effort model. Take each initiative required to satisfy the vision of your product release and plot it on the value vs. effort scale.
[Credit ProductPlan]
Now, select a mix of the initiatives in the blue and yellow quadrants. Start with those that are low effort and high value. Those are the first things you’ll want to develop—the low-hanging fruit, if you will. Then select some initiatives that have really high value but are also really hard, and add those to your product roadmap. You may only tackle a couple of those on your roadmap because they’re hard to do. But they also might be some of the most unique, differentiating features that really set you up for positioning against the competition. Finally, sprinkle in some low-value/low-effort initiatives customers are asking for.
If you have difficulty determining which initiatives belong in each quadrant, or you need to further narrow your focus—say you have too many initiatives in a single quadrant and need to choose among them—you can score each initiative according to value and cost. Jim Semick, co-founder and chief strategist at ProductPlan, walks you through how to do this in our webinar, Everything You Need to Know About Product Roadmaps.
Another prioritization method is the Kano Model, which is also explained in the webinar above. In this model, you’ll consider each initiative in terms of how much it will delight your customers. There will be initiatives that are required simply to make your product work, initiatives you’ll need to pursue to increase performance and initiatives that will delight your customers. This model ensures you really set yourself apart from your competition.
[Kano graphic here: ProductPlan]
The RICE Scoring Model is the latest prioritization method used in product roadmapping. In it, you’ll evaluate each initiative based on Reach, Impact, Confidence and Effort.
Reach: How many customers will be affected by the initiative?
Impact: What quantitative or qualitative effect will the initiative have?
Confidence: How confident are you in the initiative’s reach and impact?
Effort: How much time and effort will it take to complete the initiative?
At the end of the day, it doesn’t really matter which prioritization method you use, only that you pick one and stick with it. You’ll then use the method as the basis for deciding how to adapt your product roadmap when key stakeholders make requests or changes throughout the development process, which is sure to happen.
The fact is, you should be working with your stakeholders from the very beginning and getting their input throughout your planning and development process. But a critical check-in point is after you’ve plotted your product roadmap using your prioritization method of choice.
If you’re working closely with them along the way, nothing during this step should come as a surprise to them. But what you’ll want to do is get their signoff on your roadmap and work with them to fine-tune the prioritizations. Even after you begin executing your product roadmap, you’ll want to continue to engage your stakeholders frequently. This is where your product roadmap really comes in handy. When, say, the VP of sales comes to you and says the product needs to have XYZ feature because one noisy customer said so, you can refer back to your prioritization method and your roadmap and work together to determine whether the feature really is worth adding.
Product development times are shortening, thanks largely to agile software development. While development periods of 12 to 24 months were typical, now it’s common for products to be developed in three to six months or even less.
How often you need to update your product roadmap will depend on your time to development, market changes, competition, consumer demands, and more. Ideally, you should be looking at and updating your product roadmap weekly if not daily. That doesn’t mean you need to be communicating out updates that frequently—you can do it weekly or monthly, depending on your audience.
You might think working in an agile environment, you should skip the product roadmap. But that’s not the case. In fact, agile doesn’t discourage the creation of a product roadmap. To quote the agile guru Mary Poppendieck: “Agile hates plans, but loves planning.”
Given all the benefits of a product roadmap, all product teams should have one. Here are some tips for making product roadmaps work in an agile environment:
Focus on customer and user outcomes, not features and functions. Many roadmaps emphasize features and their delivery. But concentrating on customer outcomes makes it possible to describe the plan’s business focus.
Eat the elephant one bite at a time. The best roadmaps don’t provide a detailed list of features. Instead, they instill their audience with a sense of the product’s direction. And delivering frequent, incremental roadmap updates, or providing an intranet site that shows roadmap status, helps manage change and provide a clear sense of direction.
Be honest without scaring everyone. Roadmaps that support scrum teams should still forecast, but do it in an honest and open way, highlighting that the farther out an item is, the less likely it is to be delivered. Roadmaps are like weather reports: the longer the forecast, the less likely it is to be true.
Add a clear measure of success to your roadmap and report data on its success. Instead of simply describing the need, provide a way to measure its success. By adding a measurable success benchmark to a roadmap item, you provide clarity and encourage the development team to instrument the application.
Put everything in the context of true north. Everyone wants to work on something that matters. The purpose of a product is more than its features, functions or even its user outcomes. Purpose describes why the product exists and is closely linked to an organization’s mission. Describing everything in the roadmap in the context of its purpose allows scrum teams to better understand why at the macro level.
Read more on product roadmaps in the agile environment.
“Agile hates plans, but loves planning.”
A product roadmap is your bridge between strategy and development, and having a solid roadmap in place will make your job easier as the development process gets underway. Learn more about how to build a product roadmap and more in Pragmatic Institute’s Focus class today.
Fill out the form today and our sales team will help you schedule your private Pragmatic training today.
[