Tag Archives: launch date


A product roadmap is a high-level, strategic plan, which provides a longer-term outlook on the product. This creates a continuity of purpose, and it helps product managers and owners acquire funding for their product; it sets expectations, aligns stakeholders, and facilitates prioritisation; it makes it easier to coordinate the development and launch of different products, and it provides reassurance to the customers (if the product roadmap is made public).

Unfortunately, I find that many product managers and product owners struggle with their roadmaps, as they are dominated by features: There are too many features, and the features are often too detailed. This turns a roadmap into a tactical planning tool that competes with the Product Canvas or product backlog. What’s more, the features are sometimes regarded as a commitment by senior management rather than part of a high-level plan that is likely to change.

The GO Product Roadmap Explained

Faced with this situation, I have developed a new goal-oriented agile roadmap — the GO product roadmap, or “GO” for short. GO is based on my experience of teaching and coaching product managers and product owners, as well as using product roadmaps in my own business.

The following pictures shows what the GO product roadmap looks like. You can download a PDF and Excel template by simply clicking on the picture.


The first row of the GO roadmap depicted above contains the date or timeframe for the upcoming releases. You can work with a specific date such as  1st of March, or a period such as the first or second quarter.

The second row states the name or version of the releases, for instance, iOS 7 or Windows 8.1.

The third row provides the goal of each release, the reason why it is worthwhile to develop and launch it. Sample goals are to acquire or to activate users, to retain users by enhancing the user experience, or to accelerate development by removing technical debt. Working with goals shifts the conversation from debating individual features to agreeing on desired benefits making strategic product decisions. The development team, the stakeholders, and the management sponsor should all buy into the goals.

The fourth row provides the features necessary to reach the goal. The features are means to an end, but not an end in themselves: They serve to create value and to reach the goal. Try to limit the number of features for each release to three, but do not state more than five. Refrain from detailing the features, and focus on the product capabilities that are necessary to meet the goal. Your product roadmap should be a high-level plan. The details should be covered in the Product Canvas or product backlog, and commitments should be limited to individual sprints.

The last row states the metrics, the measurements or key performance indicators (KPIs) that help determine if the goal has been met, and if the release was successful. Make sure that the metrics you select allow you to measure if and to which extent you have met the goal.

A Sample GO Product Roadmap

To illustrate how the GO template can be applied, imagine we are about to develop a new dance game for girls aged eight to 12 years. The app should be fun and educational allowing the players to modify the characters, change the music, dance with remote players, and choreograph new dances. Here is what the corresponding GO roadmap could look like:


While the roadmap above will have to be updated and refined at a later stage (particularly the metrics), I find it good enough to show how the product may evolve and make an investment decision.

When creating your GO roadmap make sure you determine the goal of each release before you identify the features. This ensures that the features do serve the goal. Filling in the roadmap template from top to bottom and from left to right works well for me.

My post “Working with the GO Product Roadmap” explains the GO product roadmap in more detail including its relationship to the Vision Board, Business Model Canvas, and Product Canvas.


The GO product roadmap provides a new, powerful way to do product roadmapping. Rather than focussing on features, GO emphasises the importance of shared goals. This makes it easier to communicate the roadmap, create alignment, and use it as a strategic planning tool that provides an umbrella for the Product Canvas and the product backlog. The metrics provided by the tool ensure that the goals are measurable rather than lofty and fuzzy ideas. Download the template now, and try it out!

You can learn more about creating effective product roadmap and working with the GO product roadmap by attending my Agile Product Planning training course. Please contact me for bespoke product roadmap workshops and webinars.

What is an Agile Product Roadmap?

A product roadmap is a high-level plan that describes how the product is likely to grow. It allows you to express where you want to take your product, and why it’s worthwhile investing in it. An agile product roadmap also facilitates learning and change. A great way to achieve these objectives is to employ a goal-oriented roadmap – a roadmap based on goals rather than dominated by many features.

Here is a sample agile product roadmap that shows the anticipated development of a dance game app for kids:


The roadmap above states the date, the name, the goal, the key feature, and the metrics for each major release or product version. It is a goal-oriented product roadmap, and it applies the GO roadmap template, which is explained in more detail in my post “The GO Product Roadmap”.

The benefit of a goal-oriented roadmap is that it shifts the conversation from arguing over features to agreeing on shared goals. This mitigates the conflict between viewing roadmap features as commitments and agile teams who only commit for next few weeks.

What Benefits does a Product Roadmap Provide?

A product roadmap can provide the following five benefits: First, it helps you communicate how you see the product develop.

Second, it helps align the product and the company strategy. By anticipating how the product is likely to grow you can show how the product helps the organisation reach its goals. This makes it easier to secure a budget for the next fiscal year.

Third, a product roadmap helps manage the stakeholders and coordinate the development, marketing, and sales activities.

Fourth, a product roadmap facilitates effective portfolio management, as it helps synchronise the development efforts of different products.

Last but not least, using a roadmap supports and complements the Product Canvas and the product backlog. This allows the canvas and backlog to focus on the tactical product development aspects, as I explain in more detail below.

When should I Use a Product Roadmap?

I usually create a product roadmap once I can confidently look beyond the next major release. If you cannot look further, then do not employ a roadmap! What’s more, I want to ensure that the assumptions about the target group, the needs to be addressed, and key aspects of the business model have been validated, as the picture below illustrates:


In the picture above, the market and business model assumptions are captured on a Vision Board. But you can also use the Business Model Canvas or Lean Canvas to state and validate your ideas. While the Vision Board and the two canvases are helpful tools, they not tell us how the strategy will be executed. This is where the product roadmap comes in.

How do the Product Roadmap and the Product Canvas/Backlog Relate?

Using a product roadmap can benefit your Product Canvas and product backlog . Here is why: As the roadmap takes care of the strategic product planning aspects, it frees the canvas/backlog to focus on the tactical work, as the picture below illustrates.


Say you release a new product version every three months. I would then suggest that your product roadmap should capture the next four major releases, while your Product Canvas or product backlog focuses on creating the next product version.

The following table summaries the differences between the product roadmap and the product backlog:

Who Owns the Product Roadmap?

As the product roadmap captures decisions about the product’s futures, the individual responsible for the product success should own the roadmap. In an agile context, the product owner should hence manage the product roadmap. The team members and stakeholders contribute, as the following picture suggests.


Having one person in charge of the product roadmap and the Product Canvas/backlog unites the strategic and the tactical product planning aspects, and establishes clear authority and responsibility.


A product roadmap allows you to communicate where you want to take your product. If applied correctly, the product roadmap and the product backlog complement each other nicely. But before you create your roadmap, make sure that you are able to forecast how your product is likely to develop in the future.

Learn more about working with product roadmaps by attending my Agile Product Planning training course. You can also download my GO product roadmap template that allows you to create goal-oriented, agile roadmaps.

This post was last updated on 15 January 2014.

Determining the launch date and the budget before development starts can be tricky in Scrum. Relying solely on Scrum’s empirical approach, a team working on a new product has to carry out at least one sprint to measure the velocity and to understand the rate of change in the product backlog. For many organisations this is difficult to accept, as an investment decision is often required before the development work can start.

Frozen Requirements or No Informed Investment Decision?

Employing a traditional planning approach and trying to capture all requirements in detail upfront in the product backlog is not only error-prone when dealing with innovative products. It is also undesirable in an agile context where the product’s detailed functionality is discovered during the development through early and frequent customer and user feedback.

Does this mean that we cannot make an informed investment decision at an early point in time on an agile project? Luckily, the answer is no. This blog post discusses how we can determine the launch date and the project budget before the first sprint – without turning the product backlog into a disguised requirements specification.

Running the Release Planning Workshop

A collaborative workshop involving the right people is a great way to carry out the initial release planning: The product owner, the ScrumMaster, the team, and stakeholder representatives including a management sponsor or the customer should attend the workshop. A shared product vision and an initial product backlog now have to be in place. The former paints a rough picture of the future product, scopes the project, and acts as the shared overarching goal. The latter sketches the outstanding work necessary to develop the product. Make sure all attendees understand and buy-into the vision.

Step 1: Identify the Window of Opportunity

Based on the product vision and the backlog, we determine the window of opportunity, the time frame in which the product must be launched to achieve the desired benefits. If the date is missed, the opportunity is gone, and launching the product no longer makes sense. The work carried out to create the vision helps us identify the window of opportunity and understand if the product can be developed and launched within the window selected; we leverage the insights gained from the initial market research and technical exploration work. The beauty of this approach is that it does not require having all requirements described in detail in the product backlog. But it assumes is that the vision stays stable for the duration of the development effort.

Step 2: Determine the Budget

Once the window of opportunity and a delivery date have been identified, we can determine the budget. To do so, we ask ourselves who is required to work on the project, which skills are needed and how many teams may be required. We then add additional items such as licensees for tools and third-party software. This provides us with an initial budget.

Step 3: Make a Go/No-go Decision

Understanding the timeframe and the budget and having the sponsor or customer present, should allow us to make a go/no-go decision in the release planning workshop, and in the latter case to discuss if and how the vision and the product backlog should be adapted. Making a decision in the workshop does not only create transparency and leverage the input of the attendees. It also avoids waiting and delays and helps reduce time-to-market.

Reality Check

Once development is underway, we capture the progress at the end of each sprint in form of a release burndown chart and create a forecast for the reminder of the project. This validates the original plan. It allows the product owner to steer the project and to trade off time, budget and functionality. Note that quality is frozen in an agile context and must not be compromised. Quality compromises result in defective product increments, making it impossible to clearly see the progress and to release software early and frequently.


Using a collaborative release planning workshop and determining the window of opportunity facilitates an early investment decision and the emergence of requirements. It frees agile teams from having to describe most product backlog items in detail at an early stage, and it avoids having to carry out one or more sprints before a date and a budget can be established.