Three commonly used roadmaps:

• Goal-oriented product roadmap,
• Now-next-later roadmap, and
• Story map.

The goal-oriented product roadmap focuses on outcomes with success criteria.

Product Owners use visuals to clarify what success looks like across stakeholders and the delivery team. This type of roadmap can be used to help guide the outcome of the product, and the thinking about the most beneficial features.

	First Quarter	Second Quarter	Third Quarter
Release	MVP	Release 2	Release 3
Goal - What is the goal:
Features - what product features and/or capabilities need to be included to achieve the goal:
Metrics: How to measure success? How to ensure the goal will be reached:

he now-next-later product roadmap visually communicates what is being worked on, what is planned, and what has not been scheduled. This type of roadmap is more focused on the features to be implemented but should look at the value and benefit each feature will provide.

The story map provides an overview of the features and activities the product could incorporate. While story maps are feature or story focused, they are beneficial at the beginning of new product planning

Two benefits from story mapping are:

• They start with customer or user activities, and
• The process fully engages stakeholders to share understanding and design solution feature ideas.

Both benefits invite opportunities for the team to focus on value. One of the major drawbacks of a Story Map is that it can give the impression that all listed features will be developed.

Components

Defined Vision and Strategy: The product roadmap elaborates the strategy through which the product Vision will be realized.

Defined Desired Outcomes: The P product roadmap articulates organization and stakeholder desired outcomes. Defining the desired outcomes helps the delivery team provide a working solution that adds value.

Product Management Team: The product management team is focused on maintaining the P product roadmap. The product management team ensures the roadmap:

• Reflects the most current priorities and goals,
• Is accessible to those who need it, and
• Tailors the view based on the audience.

It is imperative to have the team's input and buy-in on the product roadmap. They are responsible for product delivery, and they have the expertise required to gauge the feasibility of the roadmap deliverable timelines.

Themes: Product roadmap includes themes that represent a collection of requirements, features, or stories.

High-level Requirements: The product roadmap is comprised of high-level requirements or features that are expected to deliver value to achieve the vision and goals for the solution. These high-level items represent a group of requirements or stories.

1. Begin with the vision and its associated goals:
   • Explore and understand the reason why the product is being developed and what customer needs will be fulfilled by the product.
   • Evaluate market opportunities the product can:
     • Take advantage of,
     • Fulfill important demands, or
     • Alleviate key market pressures.
   • Identify the goals that will help achieve the product vision (if not already done), with customer and market considerations in mind.
2. Determine product capabilities or features required to achieve the goals:
   • Work with stakeholders to determine features the product could include to achieve the goals.
3. Prioritize the possible features:
   • Consider the
     • Product budget,
     • Available resources,
     • Dependencies, and
     • Other constraints.
   • Prioritize the product features based on prioritization criteria and constraints, e.g.:
     • High-impact and easy win features,
     • Time,
     • Budget,
     • Dependencies, and
     • Resource availability.
   • Give each feature a timeframe for implementation.
4. Develop the roadmap:
   • Identify which type of roadmap or maps you are going to create.
   • Determine the frequency of releases. Start-ups or new products may prefer more frequent deliverables, while mature products may go for longer releases.
   • Begin placing features into time blocks, paying attention to:
     • The availability of resources and their specialties,
     • Environmental constraints and availability,
     • Other dependent initiatives, and
     • Any other constraints that may impact timeframes.
5. Share the roadmap:
   • With stakeholders and resources to obtain their buy-in, and
   • To build the product backlog.

Considerations

Strengths

Limitations

It is visible and accessible to all stakeholders and ensures stakeholders feel their needs, input, and feedback will be addressed. It is an effective communication tool and orients stakeholders to a shared focus. It presents a unified view of the solution direction. It can be used to facilitate a discussion of options and priorities. There can be different views based on the audience for key information. For example, executives, solution teams, and external customers may have different views. It can be updated or changed as market influences change. It can help track the progress of the strategic plan for the product. It is a good starting point for planning the work and ensuring that work aligns with the product vision and strategy. Technical and architectural considerations are included in the plan.

Ineffective if the organizational environment leads to a frequently changing vision and desired outcomes. Can be misused as a milestone or date-driven roadmap. Time-consuming to maintain if overly detailed or multiple views are required. Can become just a list of features to be implemented. Can become too detailed, losing its purpose and effectiveness.

Tips for Success

• The timeframe for roadmaps varies. A long timeframe (2+ years) is not beneficial due to the high level of uncertainty.
• Items under each hierarchical level should have a unique colour to effectively show the thought process.
• Ensure that stakeholders understand that the roadmap includes features that could be implemented, but it does not guarantee implementation.
• Ensure that architectural and technical considerations are included.
• A roadmap is a living document and must be updated as needed.
• State the benefits the product is likely to create (or value delivered to the customer).
• Do not focus on details (this is not intended to be the backlog).
• Stay flexible—your roadmap will change.
• Roadmaps should only be developed after the product strategy is defined and agreed upon.