Product roadmap
A product roadmap is a plan of action for how a product will be introduced and evolved over time. It is developed by the product owner, an agile role responsible for managing the product backlog and feature set. The product roadmap is a high-level strategic view of the series of delivered systems mapped to capabilities and customer needs. The product roadmap takes into account the market trajectories, value propositions, and engineering constraints. It is ultimately expressed as a set of initiatives and capabilities delivered over time.
Purpose
The purpose of the product roadmap is to plan and provide visibility to the released capabilities of the customers over time. The roadmap is initially developed in Iteration 0, but as in all things agile, the roadmap is updated over time. A typical roadmap has a 12–24 month planning horizon, but for long-lived systems, the horizon may be much longer.
Inputs and preconditions
A product vision has been established which includes the business aspects (such as market and broad customer needs) and technical aspects (the broad technical approach and its feasibility).
Outputs and postconditions
The primary work product is the product roadmap, a time-based view of capability releases of the system.
How to do it
The product roadmap is organized around larger-scale activities (epics) for the most part, but can contain more detail if desired. An epic is a capability whose delivery spans multiple iterations. Business epics provide visible value to the stakeholders, while technical epics (also known as enabler epics) provide behind-the-scenes infrastructure improvements such as architecture implementation or the reduction of technical debt.
In an MBSE approach, epics can be modeled as stereotypes of use cases that are decomposed to the use cases, which are in turn, decomposed into user stories (stereotyped use cases) and scenarios (refining interactions). While epics are implemented across multiple iterations, a use case is implemented in a single iteration. A user story or scenario takes only a portion of an iteration to complete. User stories and scenarios are comparable in scope and intent.
This taxonomy is shown in Figure 1.18, along with where they typically appear in the planning:
Figure 1.18: Epics, use cases, and user stories
The product roadmap is a simple planning mechanism relating delivered capability to time, iterations, and releases. Like all agile planning, the roadmap is adjusted as additional information is discovered, improving its accuracy over time. The roadmap updates usually occur at the end of each iteration during the iteration retrospective, as the actual iteration outcomes are compared with planned outcomes.
The roadmap also highlights milestones of interest and technical evolution paths as well. Milestones might include customer reviews or important releases, such as alpha, beta, an Initial Operating Condition (IOC), or a Final Operating Condition (FOC):
CFigure 1.19: Create product roadmap
Enumerate your product themes
The product themes are the strategic objectives, values, and goals to be realized by the product. The epics must ultimately refer back to how they aid in the achievement of these themes. This step lists the product themes to drive the identification of the epics and work items going forward. In some agile methods, the themes correlate to value streams.
Create epics
Epics describe either the strategic capabilities of the system to realize the product themes. They can be either business epics that bring direct value to the stakeholders, or technical (aka enabler) epics that provide technological infrastructure to support the business epics. Epics may be thought of as large use cases that generally span several iterations. This step identifies the key epics to be put into the product roadmap.
Prioritize epics
Prioritization identifies the order in which epics are to be developed. Prioritization can be driven by urgency (the timeliness of the need), criticality (the importance of meeting the need), the usefulness of the capability, the availability of the required resource, reduction in project risk, natural sequencing, or meeting opportunities – or any combination of the above. The details of how to perform prioritization are the subject of their own recipe (see the Work item prioritization recipe in this chapter), but this is one place where prioritization can be effectively used.
Assign a broad product timeframe
The product roadmap ultimately defines a range of time in which capabilities are to be delivered. This differs from traditional planning, which attempts to nail down the second when a product will be delivered in spite of the lack of adequate information to do so. The product roadmap usually defines a large period of time – say a month, season, or even year – in which a capability is planned to be delivered, but with the expectation that this timeframe can be made more precise as the project proceeds.
Allocate epics in the product timeframe
Epics fit into the product timeframe to allow project planning at a strategic level.
Get agreement on the product roadmap
Various stakeholders must agree on the timeframe. Users, purchasers, and marketers must agree that the timeframe meets the business needs and that the epics provide the appropriate value proposition. Engineering staff must agree that the capabilities can be reasonably expected to be delivered with an appropriate level of quality within the timeframe. Manufacturing staff must agree that the system can be produced in the plan. Regulatory authorities must agree that the regulatory objectives will be achieved.
Update the roadmap
If stakeholders are not all satisfied, then the plan should be reworked until an acceptable roadmap is created. This requires modification and reevaluation of an updated roadmap.
Example
Let’s create a product roadmap for the Pegasus system by following the steps outlined.
Enumerate your product themes
- Providing a bike fit as close as possible to the fit of a serious cyclist on their road bike
- Providing a virtual ride experience that closely resembles outside riding, including:
- Providing resistance to pedals for a number of conditions, including flats, climbing, sprinting, and coasting for a wide range of power outputs from casual to professional riders
- Simulating gearing that closely resembles the most popular gearing for road bicycles
- Incline control to physically incline or decline the bike
- Permitting programmatic control of resistance to simulate changing road conditions in a realistic fashion
- Interfacing with cycling training apps, including Zwift, Trainer Road, and the Sufferfest
- Gathering ride, performance, and biometrics for analysis by a third-party app
- Providing seamless Over-The-Air (OTA) updates of product firmware to simplify maintenance
Create epics
Epics describe either the strategic capabilities of the system to realize the product themes. This step identifies the key epics to be put into the product roadmap. Epics include:
Business epics:
- Physical bike setup
- Ride configuration
- Firmware updates
- Controlling resistance
- Monitoring road metrics
- Communicating with apps
- Emulating gearing
- Incline control
Enabler epics:
Prioritize epics
These epics are not run fully sequentially, as some can be done in parallel. Nevertheless, the basic prioritized list is:
- Mechanical frame development
- Motor electronics development
- Digital physical bike setup
- Monitor road metrics
- Ride configuration
- Control resistance
- Emulating gearing
- Communicating with apps
- Firmware updates
- Incline control
- Electronics development
Assign a broad product timeframe
For this project, the total timeframe is about 18 months, beginning in early spring 2021 and ending at the end of 2022, with milestones for fall 2021 (a demo at the September Eurobike tradeshow), spring 2022 (the alpha release), summer 2022 (beta), and the official release (October 2022).
Allocate epics into a product timeframe
Figure 1.20 shows a simple product roadmap for the Pegasus system. At the top, we see the planned iterations and their planned completion dates. Below that, important milestones are shown. The middle part depicts the evolution plan for the three primary hardware aspects (the mechanical frame, motor electronics, and digital electronics). Finally, the bottom part shows the high-level system capabilities as epics over time, using color coding to indicate priority:
Figure 1.20: Pegasus Product Roadmap
Note the pseudo-epic “Stabilization” appears in the figure and indicates a period of removal of defects and refinement of capability.
Get agreement on the product roadmap
We discuss the roadmap with stakeholders from marketing, engineering, manufacturing, and our customer focus group to agree on the product themes, epics, and timeframes.
Update roadmap
The focus group identifies that there is another tradeshow in June 2022 that we should try to have an updated demo ready for. This is then added to the product roadmap.