Software Acquisition

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 Glossary


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: 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: USD(A&S) Guidance

Programs use the product roadmap to communicate when capability is projected to be delivered. A product roadmap provides a rolling calendar-based view of key capabilities/feature sets to be delivered in the near term (10–12 weeks) through the coming 12–18 months for a product/service, and a high-level description of capabilities to be delivered annually. The roadmap is considered a product schedule. It informs the planned evolution of the solution capabilities and should align to the product vision, enable the MVP, and visibly communicate the capabilities/feature sets targeted for delivery and/or deployment at discrete points in time. The capabilities/feature sets identified in the product roadmap provide focus and align the development team(s) with the product management and user teams on those feature sets to be delivered first (representing the features of highest value to the end user community, as assessed by the user and product management teams). The product roadmap is a living document and therefore will change over time, and it should always be an accurate representation of the business product priorities.

The product owner is responsible for defining the product roadmap. The roadmap must be at a high enough level of abstraction to allow teams to elaborate and decompose the high-level capabilities and features into the emerging system design. The product roadmap should not include the lower level tasks.

A product roadmap neither assigns work to specific teams nor dictates explicit design. Instead, it provides a prioritized, value-driven view of work to be performed that aligns to the program vision. It depicts the capabilities or features to be developed over time while avoiding overly prescriptive plans. Because product roadmaps are defined at a high level of abstraction, they allow the teams to collaborate on lower level requirements and design details.

The product roadmap is an input to iteration and increment planning; therefore, the Product Owner must review and edit (if appropriate) the roadmap prior to and in support of these events. The roadmap should include key upcoming external-facing milestones such as legislative events, participation in exercises, or field events that will be a performance priority.

Additionally, the product roadmap provides input to the program user training plan. Users who evaluate early versions of software should be adequately trained to perform the evaluation effectively. For every software release deployed to the field, the receiving military units should receive adequate training that ensures enough proficiency with the new capability to maintain operational effectiveness.