In one of my last articles, we've already made the case that if you want to develop a successful product, you better use a product development process.
It should come as no surprise that the cornerstone of a good product development process is a good product roadmap. It is a tool that helps you align your product development process with your product vision and your overall business goals. After all, it’s the products themselves that shape that path!
That’s why a product roadmap document is a useful tool for product development—it helps you reconcile various viewpoints on your to-be, new product, recognize dependencies and trade-offs, and give you the big picture on how you should structure the features with respect to the functionalities of your product(s).
The 3 most important dimensions of a product roadmap: the “Quality, budget, schedule” triad
The most important metrics to control your product development process are quality, budget and schedule.
You want your product to fulfill a certain set of functionalities in terms of product features (“quality”), you want your product to cost a certain, maximum amount of money (“budget”) and you want your new product to be ready for market introduction at a certain date (“schedule”). That’s why product development is at the same time always an exercise in project management: it fulfills the textbook definition of a project—“a one-time undertaking that is carefully planned to achieve a specific result.”
Depending which of these dimensions you want to (or have to) focus on at a certain moment, you can orient your product roadmap accordingly.
How Your viewpoints shape your product roadmap templates
There are a various viewpoints you can (and should) use during the new product development process:
- PRODUCT DEVELOPMENT PROCESS: How should my products be developed?
- PRODUCT VISION and PRODUCT GOALS: What should my product look like? How should it help the customer? Why?
- BUSINESS GOALS: Where should my company go next?
Of course you can find many more such viewpoints, but let’s stick with these at the moment so that we can better illustrate how to set up a product roadmap.
Different types of product roadmaps for different stakeholders
While the actual product development is always driven by the product team, which is headed by a representative from the company’s product management department, there are other groups of stakeholders who also profit from a product roadmap—but it has to be adjusted to their needs.
First, we have all the corporate layers above the product team. The “usual suspects” are (caveat: heavily industry- and company-size dependent!):
- The top leadership of the company
- Its product strategy department (which is either adjacent or below the board)
- The leadership of a specific product-lineup or product family
Then we have:
- Corporate layers below or adjacent to the product team
- External stakeholders
The former are the departments that are involved in developing the product and that cater to the product team—R&D, design, financial controlling, quality, manufacturing, purchasing, etc. The latter are suppliers, external developers, service providers, all other kinds of contractors etc.
And each of them needs the right type of product roadmap to work with.
I can imagine that you are curious to finally have a look at a product roadmap template or example, but we still need to do a bit of pre-work. In the end it will all fall into place. We also need to clarify one important thing: different stakeholders may use different types of roadmaps for one and the same product. But:
There must be a single source of truth from which you source all ingredients of a specific product roadmap.
Types of Product Development
Another factor that influences how our product roadmap has to look is the kind of product that we want to develop:
On the one side of the scale we have products that are 100% pre-defined the moment their development is initiated. Think DIN-normed screws, or uniforms for the military, or car seats that the supplier has to supply to the car manufacturer exactly as stipulated in the requirements sheet.
Then we have the somewhat pre-defined products. One typical example is a car. When product development starts, the main parameters of the car are already defined (body measurements, number of doors, type and power of engine etc.). Other parameters follow successively, as more and more customer feedback comes in (e.g. focus groups will be held to decide upon the seat coating, the dashboard design and the overall look of the car). And as the production of car is about to be launched on the assembly line, the last technical gimmicks that promise to increase overall profitability are being included into the product plan (umbrellas in the door panels, fancy ice scrapers with the brand logo, etc.)
On the other side of the scale we have fully agile products. To use the car analogy: whereas a typical carmaker already has a pretty good idea what kind of car will come out once the product development process will be completed, the agile approach would be “Let’s design a vehicle!”—and it’s first iteration might be a skateboard (an MVP that would bring in the first cash flow from customers, as well as customer feedback and wishes), the second iteration might be an e-scooter (because the customers wished for something motorised), and after several iterations, we would finally see a car with four wheels, a body, an engine, etc.
Product Roadmap Examples for Building a Great Product
I am going to present you a selection of product roadmap templates that:
a) Serve different stakeholders at different “flight heights” (company leadership; supplier who is delivering a pre-defined module to a manufacturer; an agile team developing an application) and
b) Deal with different types of products (a complete portfolio of existing products together with some ideas for new products; a pre-defined product; an agile product idea that is being built and upgraded through iterations)
You can use then use them as inspiration to build your own product roadmaps.
Product Roadmap Template #1 - The Product Portfolio Cycle Plan
Cycle plans show a “helicopter-view” of the current situation of a company’s product portfolio.
When to Use This Roadmap
Let’s say you work in a company that has a diverse range of products. This means that the company leadership’s first question regarding new products is: Which new product do we have to launch when and in which markets - so that it fits into our existing product portfolio and thus into our product strategy? Also, the company leadership would like to have an overview of how long existing products have already been in the market, how successful they were (sales volume, income per sale etc.) and whether/when they should be phased out or re-released as a new product version.
How to Build It
In a “cycle plan”-type of product roadmap, your leading dimension (“x-axis”) is “Schedule”, i.e. a timeline, as you are examining your past and thinking about when to phase new products in and old products out.
And, consequently, your y-axis-dimension would be “Quality”—your existing and planned products (that ultimately are nothing else than “collections of features”).
To get a better overview, you would cluster them in a suitable order, e.g. car classes (small, compact, mid-size...), types/variations (notchback, hatchback, sedan...), (major) markets etc. as well as provide space for new product initiatives.
And to cover all bases, you would then include their financial KPIs (“Budget”) on the specific ribbons of each product.
Product Roadmap Template #2 - The Classic (“Stage-gate”) Product Development Roadmap for pre-defined products
The “classic”/”stage-gate” product roadmap is the workhorse of today’s manufacturing industries and is typically used at the operative level of product development. This means that both the product team as well as suppliers frequently work with it.
When to Use This Roadmap
Love it or not, the bulk of (physical) products, especially in the B2B-world (typical supplier-customer relationship) is still being developed through a stage-gate approach.
Why? A stage-gate approach puts emphasis on quality—and quality is what your typical B2B-customer is looking for. They need reliable partners who are able to develop exactly specified parts for their final product on a regular basis and in high volumes with all the functionalities that are needed. If a car manufacturer orders tens of thousand of seats that have to be developed and then delivered to his plant (often just-in-time or even just-in-sequence), he has to have peace of mind that each and every seat will fit in perfectly into the car body and that each seat will delivered within a set timeframe.
That’s why you need to have these classical product roadmaps as a tool under your belt as well as have some ideas how to adapt and enhance them for your specific needs.
How to Build It
In this case, your leading dimension is also time, as your customer needs your product at a specific date.
Along the timeline, you build in quality gates.
At these points in time, the progress of your product development is checked and challenged (with a pre-defined set of requirements that have to be fulfilled by that time)—and only then do you proceed with the next stage of product development. At those quality gates, you also checkmark to what degree the pre-defined features of the new product are ready.
On the y-axis, you outline the logical sequence and dependencies in which you are developing and producing your pre-defined product (think “Gantt-chart with milestones”—and generally I recommend to any product developer and product manager to brush up his or her project management knowledge).
Taking seats as an example, you would start with an analysis of how many existing toolings you can use for the new product, how many of them you have to modify to get the product done and what new toolings and materials you have to purchase. You will most probably already have a well-established production plan (“How do we actually build seats on our assembly line?”) that you would modify to your customer’s specific requirements. Then you would have to start building prototypes before ramping up production.
To enhance your product roadmap you could use a second x-axis where you track your budget along time and product development stage. This is simple, but highly useful.
With such a product roadmap layout, you are tracking all major metrics of your new product, available budget, and schedule. In case your new product is only partly pre-defined, you could also build in “checkpoints” in time, where you and your development team decide about phasing in additional features. To do this, you would collect possible features beforehand, rank them, and then include them in your new product.
Product Roadmap Template #3 - The typical Product Roadmap for Agile Product Development
When we build products the agile way, we shift our focus from timelines to product iterations and the features they should contain. The reason lies in the agile approach to product development:
When to Use This Roadmap
Agile product development is fundamentally different from the aforementioned stage-gate product development:
Instead of developing one specific, pretty much pre-defined, fully developed product that we introduce to the market and ship it for months or years to come without altering it too much, in the agile world, we start with a general product idea, develop a concept out of it and think about how the most basic realization of that concept could look: the “minimum viable product” aka “MVP”. The MVP will contain only to most basic features. By bringing the MVP to the market we will collect real-life customer feedback and use this feedback work on new features in the next iteration of the product release.
How to Build It
I am well aware that I am cutting corners here, but as the article’s focus is on the product roadmap—and not agile product development—let’s keep it simple:
To take the agile-example from the beginning of the article (“Let’s design a vehicle”), the product team members would try to come up with a basic set of features for the MVP of a vehicle, e.g. 4 wheels and a board. They would also come up with other possible features that could be built-in in a second iteration (these are stored in the so-called “product backlog”).
Then the first sprint starts and results in the MVP. As the MVP is released, the product team collects market feedback and translates it into new features. Before the next sprint starts, the product team decides upon the prioritization of the features that should be built-in. As the next sprint brings an enhanced, customer-feedbacked version of the MVP to the market, the product team expects a higher customer buy-in. And the cycle starts again.
The picture shows you what an agile product roadmap can look like. You might notice that I also like to put in an effort estimate for each feature as well as an ROI estimate.
Where to next?
Wanna dig deeper? Check out the following material:
6 Free Product Roadmap Templates To Impress Your Stakeholders
10 Best Product Roadmap Software In 2023
Liked this article? Subscribe to our newsletter to get curated product management articles and resources delivered fresh to your inbox.