Software Acquisition

Click Here for SW Lethality Directive FAQs!

AAF > Software Acquisition > Define Capability Needs > Product Roadmap

Product Roadmap

How To Use This Site

Each page in this pathway presents a wealth of curated knowledge from acquisition policies, guides, templates, training, reports, websites, case studies, and other resources. It also provides a framework for functional experts and practitioners across DoD to contribute to the collective knowledge base. This site aggregates official DoD policies, guides, references, and more.

DoD and Service policy is indicated by a BLUE vertical line.

Directly quoted material is preceeded with a link to the Reference Source.

Reference Source: DODI 5000.87 Section 3.3

The sponsor and program office will develop and maintain a product roadmap to plan regular and iterative deliveries of software capabilities. The product owner and program office will also develop and maintain program backlogs that identify detailed user needs in prioritized lists. The backlogs allow for dynamic reallocation of current and planned software releases. Issues, errors, threats, and defects identified during development and operations, including software updates from third parties or suppliers, should be captured in the program’s backlogs to address in future iterations and releases. Regular stakeholder feedback and inputs will shape the product roadmap and program backlogs.

Reference Source: DODI 5000.87 Glossary

Product Roadmap: A high-level visual summary that maps out the vision and direction of product offerings over time. It describes the goals and features of each software iteration and increment.

Reference Source: USD(A&S) Guidance

What is a Product Roadmap?

A product roadmap is a tool owned by the Product Owner that illustrates high-level, adaptable value delivery targets over a designated period of time. Work items (e.g., capabilities) depicted on the Product Roadmap should be structured to deliver stand-alone value to stakeholders along the release cadence leveraged by the team. It tells “what” will be delivered and “when”, but it empowers and trusts the team to figure out “how.” To understand a Product Roadmap it is important to consider what it is and what it is not:

A Product Roadmap IS and IS NOT...

A Product Roadmap IS…	A Product Roadmap IS NOT…
A high-level, coherent visualization of What and When. A high-level, value-driven snapshot of what strategic objectives and related capabilities are estimated to be delivered and when they are targeted to achieve the vision. Elements have a statement of value that expresses why they are important.	The How. It is not a highly detailed project schedule or IMS. It is not detailed at a granular level and will not provide: All features and stories to be delivered Steps/tasks/activities to complete identified features and stories Detailed architecture and design plans Note: In Agile, team members are trusted to determine “how” to best design, build, and deliver the work they produce and long-term detailed planning efforts are considered waste. Developing a project schedule or IMS is inconsistent with Agile and the expectations of the software pathway.
Flexible and adaptable targets. It is expected to change based on new learning, evolving customer/end-user needs, competitor actions/directional indicators, and advances in technology.	A rigidly adhered-to commitment/plan that attempts to detail every task/activity over the long term and identify/anticipate every future unknown and contingency. Note: These are not APBs, and developing APBs is inconsistent with the expectations of the software pathway.
A tool that is owned and adapted regularly by the Product Owner who actively engages a variety of stakeholders, scans the market, and captures insights from the team to maximize value.	A set of fixed requirements that is captured and locked in once on Day 0 and then rigidly adhered to throughout delivery.
A tool that illustrates product direction and incremental value delivery (i.e., value delivery over short timeboxes, along release cycles).	A tool to reinforce waterfall developmental phase gates and “big bang” deliveries. Agile programs will plan>execute>deliver within each increment (every 3-6 months) and each iteration (every 2-4 weeks). Therefore, Agile teams simply identify the value they intend to deliver. This means that leadership will not see work broken out along waterfall phases (plan> build> test> deliver). If value delivery is > 1 year and/or work requires the phase gates noted above, the program is not operating in an Agile fashion.
A tool to align all stakeholders on the product vision, strategy, and development targets. It allows leadership, the product owner, teams, and customers/end-users to understand product direction and collaborate with the Product Owner and team. It provides a foundation for breaking down and prioritizing work in the product backlog.	A tool that provides granular detail of tasks and activities to be performed by specific teams and/or resources that allows leadership to “manage” to schedule. Note: A Product Roadmap with tasks and activities required to generate value (e.g., Capabilities, Stories) is incorrectly built and too detailed.
A tool that drives ongoing collaboration between the Product Owner, teams, and customers/end-users on architecture and design details. It allows those closest to the work and those using the end-product to elaborate architecture and design details just-in-time.	A tool to dictate explicit architecture or design details on Day 0, when the least information is known/available.

Why Use a Product Roadmap?

Agility recognizes that change is inevitable, and that product, service, and technology lifecycles are constantly shrinking. Therefore, teams must routinely scan the environment, identify valuable changes, and adapt to maximize value delivered. To accomplish this, teams must have the flexibility to incorporate new learning, respond to actions/indicators from our adversaries/competition, and to meet the ever-evolving needs of customers/end-users. The Product Roadmap helps visualize value delivery targets that can adapt as needed to maximize value.

Agile emphasizes near-term planning focused on delivering working product that customers/end-users can react to. This incremental and routine value delivery validates the team’s effort and guides future product direction, minimizing the need for detailed, long-term planning. Because this future direction is expected to adapt, detailed long-term planning is inefficient, ineffective, and perceived as waste in Agile programs. The Product Roadmap balances the need to understand long-term product direction with the desire to minimize the effort spent on long-term planning (since Agile teams know the long-term plan will change).

Instead, Agile employs higher-level long-term planning using a Product Roadmap that sets flexible/adaptable value delivery targets along routine release cycles. The Product Roadmap is a tool that aligns resources and allows leadership to determine appropriate investment for the delivery of products and services, while maintaining the ability to adapt to new learning and changing conditions during execution. To help maintain that alignment, the Product Roadmap should be regularly update by the Product Owner and posted somewhere that all stakeholders have access.

The following is an example of a three-year product roadmap leveraging an annual release cycle. The team provides as much detail as they are aware of at the time the roadmap is developed but is only required to elaborate work below the capability level for the work targeted for the upcoming release (in this case, release 10).

Three Year Release Cycle Product Roadmap

Benefits of a Product Roadmap

Visualizes long-term product/services evolution to gain alignment with stakeholders (e.g., leadership, customers/end-users, teams).

An adaptable planning tool that allows long-term planning to change as needed to maximize value based on new learning, emerging customer needs, evolving competitor capabilities/indicators, and advances in technology.

Provides the basis for more detailed, near-term release planning (work that is better understood).

Makes long-term planning is easier by answering “What” and “Why” about the product, but trusts the development team to figure out “How”.

Flexible enough to capture a variety of work elements – architecture, MVP/MVCR, enhancements, enablers, spikes, external facing milestones (e.g., legislative events), related programs/platforms, and user engagement/change management activities (e.g., training).

Building a Product Roadmap

Building the Product Roadmap requires those involved to:

Understand of the product vision/direction, mission needs, and targeted capabilities (as captured in the Capabilities Needs Statement (CNS), Software ICD, or other requirements document).
Determine the appropriate timeframe for the Product Roadmap(s) and routine increments/ releases. This becomes the structure of the Product Roadmap.
Break down capabilities into work (e.g., Epics/Features) that delivers stand-alone value within the release timeboxes.
Populate the Product Roadmap structure with the work targeted for delivery (e.g., Capabilities, Epics/Features).

Begin by reviewing product vision, mission needs, and targeted capabilities as noted in the Capability Needs Statement (CNS or similar artifact). Next, determine the appropriate timeframe for the Product Roadmap (e.g., 1-5 years) and the program increment / release cadence (e.g., 3-6 months). Both should be determined with a preference to the shortest duration possible. This establishes the structure for the roadmap and provides meaningful timeboxes for value delivery.

Structure for Building Product Roadmap Graphic

Once the structure and timeboxes are established, build in the content:

Add in capabilities and their delivery timeframes (these estimates of time are flexible/adaptable targets and are typically determined at a rough order of magnitude). The delivery of capabilities may span a single release or multiple releases.
Break down capabilities into lower-level work items (e.g., Epics, Features) that will deliver stand-alone value within a single program increment / release cycle.
Populate the Product Roadmap with the content from steps 1 and 2.

Note: Structuring work to deliver stand-alone value is critical and will be challenging for new Agile teams.

The following is an example of a Product Roadmap:

An Alternative Approach to Building a Product Roadmap

From time to time, there may be a need for longer term planning (e.g., 2-5 years) but also a need to satisfy nearer-term planning for annual budgeting or reporting (e.g., 1 year). If both are required, consider splitting the Product Roadmap into Strategic and Tactical Roadmaps:

Strategic Roadmap (2-5 Years)	Tactical Roadmap (Optional, Typically Annually)
Conveys the long-term strategic vision and path toward capability delivery for the program/product.	Conveys a mid-term view of the path towards capability delivery.
Timeframe may align with longer-term funding/reporting cycles (e.g., the FYDP).	Timeframe may align with annual budgeting/reporting cycles.
A communications tool to align stakeholders (e.g., leadership, customers and end-users, teams).	A communications tool to align stakeholders (e.g., leadership, customers and end-users, teams).
Contains less detailed, highly adaptable targets that can evolve due to new learning, emerging customer needs, evolving competitor capabilities, advances in technology.	Contains less detailed, highly adaptable targets that can evolve due to new learning, emerging customer needs, evolving competitor capabilities, advances in technology.
Requires definition and prioritization of capabilities.	Provides more detail than the strategic roadmap, but less than the program backlog.
Value delivery targeted annually or along release cycles (e.g., 3-6 months).	Requires definition and prioritization of both capabilities and value targeted for delivery within the timebox.

The following is an example of a Strategic and Tactical Roadmap:

Example Tactical and Strategic Product Roadmap Graphic

Using a Product Roadmap

The Product Roadmap is a tool used to align all stakeholders on the targeted path to delivering/evolving the product. Once all stakeholders are aligned on the Product Roadmap, it is leveraged to drive more detailed program increment/release planning sessions that generate the Product Backlog. The Product Owner ensures that the product roadmap is updated regularly to ensure accurate understanding of priorities and product direction. The Product Owner should have the authority and freedom to say “no” to requested additions, modifications, and changes to timing on the Product Roadmap to ensure it is realistic. The Product Owner should gauge how realistic the Product Roadmap is based on input and commitment from the team(s) performing the work, Agile dashboarding/metrics, and value assessment data.

The Product Roadmap can also be leveraged as a budgeting and investment decision-making tool. The key is to align budgets and expenditures to capabilities along any line items deemed valuable, including program management, contractor, and internal labor costs. Product teams should be able to track all spending back to capabilities delivered in order for leadership to make smart investment decisions and answer critical questions, including:

Does the anticipated value generated in a given period outweighed by the anticipated costs?
Do investment amounts align to anticipated capability delivery?
Do capability investment amounts and delivery timelines seem reasonable given known complexity capabilities?
Is the investment allocation across capabilities aligned to the Product Roadmap?
Are the allocations of funding across expense categories reasonable (e.g., most funding is targeted to development efforts)?

Typically, progress against the Product Roadmap is considered along with the Value Assessment and team performance data in a retrospective after every release. These retrospectives should aim to answer the following questions:

Are product teams delivering on their commitments as illustrated in the Product Roadmap?
What are the root causes for variations, and how can we solution/continuously improve?
Are we investing in capabilities that are deemed valuable by customers/end-users?
Do we need additional investment to deliver the right capacity to ensure speed of relevancy?
Are vendors/contractors performing well?

Using the previous example of a three-year product roadmap, tracking costs back to capabilities and spend categories helps answer important questions to guide future investment decisions.

Product Roadmap Relationship to the Product Backlog

The Product Backlog is a separate tool/artifact that contains all known work items (e.g., Epics, Features, Stories) targeted for completion in the next release (e.g., the next 3–6-months). In essence, the Product Backlog is a means to manage workflow within the team but it is also a communications tool that provides detail on what is targeted for delivery in the next release. Metrics and dashboarding can be provided to show progress over the program increment/release cycle. Stories in the Product Backlog are structured to complete within each iteration/sprint (e.g., the next 2-4 weeks).

In the example below, there are four Epics targeted for delivery in Release 1. Once the Product Roadmap is accepted the product team will decompose those agreed upon Epics into Stories required to deliver each Epic. This populates the Product Backlog. The Product Owner then prioritizes those Stories for the Team to deliver.

Product Roadmap to Product Backlog Relationship Graphic

Over the course of the program increment/release cycle the work depicted may be added to, modified, and/or reprioritized by the Product Owner based on new learning generated by all stakeholders (customers/end-users, the Product Owner, the team, and leadership). All Epics and Stories are still targets for delivery so their priority and anticipated delivery timelines can shift as needed.

Further, it is important to recognize that the Product Backlog is not a project schedule/IMS and does not contain detail on “how” the work will be completed (i.e., the steps, tasks, activities). Team members should not capture the steps, tasks, and activities that drive towards value delivery in the Product Roadmap or Product Backlog nor should they be asked to provide that information in the Product Backlog.

Decomposing work to the steps/tasks/activities level in the Product Backlog is an Agile anti-pattern that:

Distracts leadership and the team from the overall goal of value delivery
Dilutes value delivery data/reporting necessary to drive continuous improvement
Shifts the discussion to the progress towards value delivery instead of its achievement.

Additionally, program and project leadership should NOT reinforce the capture of steps, tasks, activities, by requesting an integrated master schedule (IMS) or other form of project schedule (including from contractors). Instead, program/ project leadership should adapt to Agile management practices and learn how to use the Roadmap, Product Backlog, Agile metrics, and value assessment information to assess team performance and forecast their ability to deliver value.