There has never been a perfect prescription for developing a successful product. Having an idea is just a beginning that helps you figure out market fit and product properties. But implementation is the tricky process that’s easy to mess up: Development is stretched over a long time period with thousands of factors transforming the initial idea.
In the center of it all stands a product manager. While the idea of a product evolves, the task of a product manager is to keep everybody in sync, so that teams understand the product in the same way. This can be accomplished with the help of a strategic document called a product roadmap.
In this article, we define the role of a product manager in product development, the product roadmap, and its main features. You’ll also find common roadmap types, examples of them, and some tips on roadmap creation.
Product roadmap explained in a nutshell
Who is a product manager?
To understand all the peculiarities of roadmapping, we’ll first give you a quick outline of the one who builds it. The main duties of a product manager cover:
- Market/competitor analysis
- Customer communication
- Product vision/tactics/strategy development
- Work estimation and prioritization
- Product roadmap creation
- Sharing roadmaps across organization
- Maintaining the product roadmap
The essential part of the product manager’s job is to figure out what the product will be, and tell everyone about it through the product roadmap. If you want a deeper insight, check our article on product management as an organizational function or watch our YouTube video:
Product manager or product owner – a misconception
You might question the difference between product manager (PM) and product owner (PO), as they both deal with communicating product details. In a plain language, PO is responsible for product value, backlog, and user stories. The main thing to remember — there is no PO role outside of a scrum project.
Product manager, in contrast, is a profession. So that a product manager may also be a product owner within a scrum team. To simplify it, PM delivers a product roadmap, with the vision and strategy, while PO works on a product backlog and specifies business/technical requirements.
We have also covered the difference between a product manager and project manager, so you might read it as well. But now, we will talk about the product roadmap itself.
What is a product roadmap?
A product roadmap is a high-level, strategic document that maps out general stages of a product’s development. The main purpose of a product roadmap is to tie a product’s vision in with a company's business objectives.
Product roadmap example
Source: Roadmunk
A product roadmap is created as a result of strategic planning. It documents both the executive strategy and overall goals of a product. A strategic product roadmap typically includes the following key points:
Product vision — what you want your product to become in the future.
Strategy — an execution plan detailing what your company is going to do to meet the vision.
Goal — a time-bound objective that can be measured by a specific metric.
Initiative — broad themes that unite features that must be implemented to achieve a goal.
Feature — an actual piece of a product that’s either part of functionality or a third-party application.
Time-frames — dates or time periods for a certain goal or feature to be finished. As a rule, a product roadmap suggests only an approximation.
Status markers — used to track the progress of work.
Metrics — assistance in the measurement data-driven goals, e.g. churn rate or organic traffic.
Product planning elements scheme
Depending on the product you are developing and methodologies you are practicing, the number of teams involved in roadmapping may vary. Most often, you would have your engineering team, UX, sales, marketing, support team, operational team, designers, and testing team. Those are the people that will work on the actual product.
Any product roadmap must be clear and simple to understand. This helps a product manager guide all the teams throughout the development process, keeping aligned with customer needs and business objectives. So, a product roadmap is useful and applicable when it meets the following requirements:
- Conveys the strategy of the product development
- Shows the vision of the product
- Evolves and changes with the product and market requirements
- Prioritizes high-level units of development
- Acts as a communication tool between all people involved
- Sets long-term timeframes
- Indicates exact goals and ties them to the business objectives
Sometimes, a product manager builds multiple roadmaps of different types to present the information to internal and external stakeholders.
How to create a product roadmap?
Sticking to general and well-tried practices makes sense when contemplating a multi-step process like configuring a roadmap. So, here are some practical tips:
Formulate your strategy and vision of the product
Talk to your internal and external stakeholders, talk to your customers, look at the market and your competitors. Define your customer personas, listen to what salespeople are telling you, speak to customers themselves. Provide intelligence on the customer voice to the production team and management. Once you’ve aligned the vision across all stakeholders and participants, you have the required input data to begin working on your roadmap.
Define your audience
A product roadmap is not a one-size-fits-all plan. The audience you have to present your roadmap to will be a predetermining factor for the format of your roadmap, its type, and the contents you should include in it. Determining the type of roadmap is a complex, and we will detail that in the next section.
Pick a suitable format
The format also makes an impact on your contents choice. The format you may choose can be more suitable for a specific audience. For example, a feature-based format is not suitable for the marketing department or management but is recommended for your engineering team. The format chosen will suggest the necessary items of information to be highlighted and which themes or goals should be prioritized on the timeline.
Choose the metrics and tailor them to the actual features
Metrics will help to see an even broader picture and measure your progress. Depending on the purpose of your roadmap, you may choose metrics oriented to customer needs or business needs. As a source of relevant metrics, you may analyze the market and your competition or have recourse to an industry analyst. To learn more about KPIs and metrics used in Agile product development, check our fact-filled article.
Use roadmap specific tools
Using a tool like Excel to build a roadmap can be a painful process. As a result, you will get a static presentation that would be fairly difficult to update. Cloud-based roadmapping tools allow you to speed up the process and keep the roadmap updated when priorities change. Here are just some tools you can use:
OpenProject is a free roadmap tool that allows you to create unlimited projects within a single user profile. OpenProject is an open-source product management software also tailored to the needs of Agile/Scrum teams.
Roadmap Planner is another open-source product management tool for Linux.
ProductPlan is the most popular among those mentioned, being used in such digital giants as Windows and Adobe. ProductPlan shares tons of roadmap templates for various purposes. You may also import items from Jira, Spreadsheets, or VSTS, which makes the planning process much easier.
Aha! is another industry giant, used by Shutterstock, LinkedIn, and Dell. The integration list with other applications is impressive.
Roadmunk is also on the list of top product management applications meeting all the necessary standards with good pricing.
Keep the information high-level and up to date
To preserve the functionality of your strategic roadmap, you have to focus on providing the general vision and strategy, not tactics. Your minor items of information are valuable, but your roadmap is a strategic document that has to be clear and easy to understand. For that reason, avoid being too detailed and including too much or unnecessary information.
The second point here is the dynamics of your product roadmap changes. Your product progress will bring new features and goals. To keep track of them and convey the information to the rest of the stakeholders, a product roadmap should be constantly updated, which means a gradual evolution with the product.
Types of audience for a product roadmap
Like a product, a roadmap has its target audience. Different groups of people are connected with the product, so you want to communicate with precision different information to those groups. The audience factor will tell you the type of content to include, the content form, and how detailed it should be. So, as a product manager you may either create multiple roadmaps for each group of people or build a single, strategic document for everyone (which is a rare case). Let’s look at the audience types your roadmap can be made for.
Types of audiences in roadmapping
The product roadmap audience can be internal, e.g. your team and executives, or external, customers and investors.
Internal roadmaps communicate information required by each department, so you want to suggest the proper data to the right people. Commonly, internal roadmaps are meant for executives, production team, and sales:
Because the executive group requires a more strategic look at the data, the roadmap should focus on vision, strategic goals, timelines, market numbers, and so on.
The production team, on the other hand, concentrates on tactical aspects, deadlines, and technical details of the implementation. To bring real value for a production team, a roadmap should communicate low-level information based on actual parts of a product, themes, or features.
The sales team is especially interested in the combination of product features and product benefits for customers. That’s why this type of roadmap should be concentrated on product value. A theme-based format is the best fit here as themes can graphically show which goal each feature serves.
External roadmaps usually have a presentation-like format as they don’t share any specific information about internal processes. External roadmaps should be easy to understand, visually clear, and share maximum information about the benefits for the customers. Most often, roadmaps shared with the public don’t contain any deadlines. They introduce approximate time frames and the succession of feature releases.
Product roadmap types and examples
Product roadmaps will differ from project to project, because they may be tailored to convey different types of data or follow different logic. Based on this, the look and the structure will vary. The most common classification is given by Brian Lawley in his Expert Product Development book, which covers general purpose roadmaps:
- Strategy & Market Roadmap — deals mainly with high-level details and market state.
- Visionary Roadmap — outlines the vision of a product instead.
- Technology Roadmap — a complete opposite of the previous two, a low-level technical roadmap for the production team.
- Technology Across Product Roadmap — the mix between actual technologies/features planned for product/products.
- Platform Roadmap — aimed at multiplatform digital products.
- Internal & External Product Roadmap — tied to different types of audience.
But the real-world variety of roadmaps is much wider among Agile practitioners and digital technology companies. With the audience as the primary factor in mind, let’s look at some common types of roadmaps.
The now-next-later roadmap describes the tasks/sprints/features in a prioritized way. Basically, it's a simplified version of a product backlog that categorizes items of information in horizontally and vertically. It shows what will be released now, what’s prepared next, and what will be released later. The purpose of this roadmap is to show priorities in the simplest way possible.
Now-next-later roadmap
Source: www.scrum.org
A Goal-Oriented roadmap helps to keep all information grouped and clearly explained. Goals determine a reason for every feature to exist. A goal can be stated in simple words as “Increase user engagement” or “Make registration process faster.” By organizing the information around the goals, you will keep your roadmap high-level and make your strategy and vision easy to understand.
Goal-oriented roadmap example
Source: https://roadmunk.com/
A Theme-based roadmap is similar to the goal-oriented one. The goal and theme concepts are close as they both answer “why” questions. The only difference is that themes consist of several goals at once.
Theme-based roadmap example
Built with Roadmunk
A Feature-based roadmap entails using a feature as a central point of your roadmap making it very detailed. The drawbacks are:
A feature is not a stable unit considering the changing market. Technological innovations and customer needs cause your feature set to change quite often.
A feature-based format doesn’t provide high-level details, which blurs a general vision of the product, making your roadmap practically more difficult to maintain and harder to understand.
Feature-based roadmap example
Source: Roadmunk
Strategy roadmap is a general purpose roadmap. It can include any type of information and be tailored to both internal and external audiences. It is a high-level outline of general product information tied to a specific aspect depending on the purpose.
Strategy roadmap example
Source: blog.aha.io
Technology roadmaps or IT roadmaps are more low-level documents usually created to support the main strategic roadmap. They are used for the internal teams to formulate tech requirements. Technology roadmaps determine the use of a certain technology and help to allocate resources they depend on.
Technology roadmap example
Built with Roadmunk
Manufacturing roadmaps are created for the actual manufacturing of a physical product. The name is self-explanatory, as manufacturing roadmaps help to control manufacturing and set actual dates for a particular release.
A portfolio roadmap is used to communicate the strategy of a product line between executives and product managers. In companies with multiple products, it’s essential to see how each product evolves and how different products relate to each other to accomplish high-level business objectives.
Portfolio roadmap example
Source: Aha!
A release roadmap is an example of an external roadmap presented to customers. This type of roadmap represents major releases of app functionality for public consumption, so it doesn’t need many tech or practical details.
Release timeline roadmap for the external stakeholders
Built with Roadmunk
A market roadmap is a document that may be used if the product launch is planned across multiple markets. It’s mostly developed to enable the marketing department and internal stakeholders to plan marketing strategy for single or multiple products. Market roadmaps are, perhaps, the most dynamic ones, as they have to capture the rapid changes in the market. Competitor or technological progress may cause significant shifts requiring strategy adjustment. At the same time, they basically include three or four items, as companies rarely distribute their products to a large number of markets.
Product roadmap templates
The basic understanding of a product roadmap type may not be enough if you are going to build your own. All the examples mentioned above can be used as a reference. In this section, we’ll provide some templates that can be used or shared with your audiences. The most basic one is our Spreadsheet template above.
Roadmapping software providers offer their own free templates that can be used during the trial periods or downloaded:
Aha! Templates (available only after sign-in).
Miro templates (available only after sign-in).
Or, if you need a downloadable template, you can use one of these. Roadmaps built in files are kind of difficult to update, require registration, but are free to share.
Office Timeline downloadable templates.
TemplateLAB downloadable templates.
UseFyi downloadable templates.
Roadmap-supporting documents
A product roadmap in any of its forms still has to preserve the general key points of information. To avoid adding low-level information to the document, we can use two more artifacts supporting a strategic roadmap.
A product backlog is a Scrum artifact with a list of high-level requirements and features. Backlogs are created by product owners and consist of user stories. A product backlog is basically a to-do list that defines product development at the tactical level.
A release plan is a document that sets strict release dates. Product managers mostly set floating timeframes for releases. While the goal of the product roadmap is to show the succession of product releases, a release plan presents more precise dates for a specific feature to be released. It’s also a normal practice to match development sprints with certain features or bug fixes.
Is a product roadmap necessary?
After reading all this, you might reasonably ask whether it is necessary to build a product roadmap. First of all, any document on its own requires a lot of effort to create. A product manager will spend time gathering all the input data from stakeholders and the product team.
Maintained and formatted properly, roadmaps give your teams easy access to strategic information. Think of this as a handy instrument.
If a roadmap helps you achieve your production goals, go with it. But if it takes more time to build and distribute or its maintenance entails updating multiple documents each time, you can probably do without it.
However, if you are struggling with prioritizing tasks and setting strict deadlines, there are more suitable techniques in product management like user story mapping. Also consider general backlog prioritization techniques used in Agile, since products are driven by backlog one way or another.