Tag Archives: product lifecycle

Innovation can be a tricky thing: Not only does it means different things to different people, but creating a brand-new product requires different practices compared to updating an existing one. This post helps you choose the right lean and agile practices to innovate successfully. It introduces three innovation stages and explains how product ownership, process, and project setup are influenced by the amount of uncertainty present.

The Three Stages of Innovation

Innovation forms a continuum ranging from maintaining an existing product to creating a brand-new one. To select the right practices, I find it helpful to divide the continuum into three stages: a maintenance stage, a new feature stage, and a new product stage, as the image below shows. The diagram is inspired by Nagji and Tuff’s HBR article “Managing Your Innovation Portfolio”.

In the image above, the degree of uncertainty and innovation rises from left to right. Whereas stage three focuses on protecting existing assets, stage one and two are about investing in the future.

The three innovation stages correspond to the product’s lifecycle: Every product starts in stage one. After its launch, the product moves into stage two, and eventually arrives in stage three.

Understanding the Innovation Stages

Stage 3: Maintaining a product means making small incremental updates to ensure that the product stays competitive and profit goals are met. The product management focus is typically on maximising the return of investment: to minimise cost and increase revenue. The innovation is low, and there is little uncertainty about what the product should look like and do, and how it is built. Experimentation and failure are hence not desirable. Planning the work and executing the plan works well. Most products in an established company fall into this category, and companies often optimise their processes and structures for this stage.

Stage 2: One or more new features are created. This enhances an existing product, for instance, to increase the market share, or to enter a new market. Creating new features may require dealing with a new target group or addressing new needs, changing the user experience, or employing new technologies. Consequently, there is a significant amount of uncertainty present. Experimentation and failure are helpful to acquire the necessary knowledge and to develop the right features in the right way.

Stage 1: A brand-new product aimed at a new or an existing market is created. Developing the product may involve addressing a new target group or new user needs, creating a new user experience, employing new technologies or a new business model. There are many more unknowns than knowns. The innovation present is high to very high. Rapid experimentation is a must, as it helps the team fail fast to succeed sooner: to create the right product for the right people. The stage-one products usually form the smallest group in a mature enterprise.

Employing the Right Practices

Distinguishing between the three innovation stages enables us to choose the right practices. These include the process and the project organisation employed, and the way product ownership is implemented. The table below summarises my observations.

As stage three aims to maximise ROI, a linear process tends to work well – it facilitates efficiency. Employing a Kanban-based approach that leverages pull, collaboration, and visualisation is usually beneficial. The product ownership may be shared amongst several individuals, for instance, a product marketer, a product manager, and a project manager or business analyst. Collocated team members is a plus but often not mandatory.

In stage two the focus shifts form efficiency to effectiveness: quickly resolving uncertainty by acquiring the relevant knowledge. This requires an iterative process that supports experimentation such as Scrum. A single product owner is beneficial to enable effective decision-making. The team members should be collocated, and product owner and team should collaborate on an on-going basis.

In stage one, effective experimentation becomes even more important. Scrum with short sprints, or Lean Startup combined with Kanban work well. The latter allows running experiments in varying lengths in parallel, but it tends to be more difficult to master. Product owner and team should form an incubator, a new, temporary organisation that is loosely coupled to the rest of the company. This provides the team with the freedom to try out new things and to literally think outside the box.

The following image visualises the three innovation stages and the different practices:


Choose your innovation practices to suit your needs: Your mature products are likely to benefit from practices that facilitate efficiency such as a linear process. To develop new features or a new product, you should select different practices, practices that help resolve uncertainty and acquire new knowledge. Applying an iterative, experimental process, and enabling collaboration will be key.

You can learn more about employing the right agile and lean innovation practices by attending my Agile Product Management training course.

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.

It’s not uncommon for me to visit a new client and to discover that the scrum teams change frequently, sometimes after every single sprint. Changing the team composition too frequently is undesirable for the individuals and the organization. To flourish, teams need stability. With markets, requirements and technologies frequently changing in an agile world, a stable scrum team provides security and continuity.

To create stable scrum teams, follow these recommendations:

First, carefully consider who should be on the Scrum team. Find the right individuals to play the product owner, ScrumMaster and team role in order to develop a great product. Having the right individuals on board is most likely the biggest success factor for any development effort.

Second, minimize any changes to the Scrum team within and across releases. It takes some time for a group of individuals to become a true team – a tightly knit unit with members that trust and support each other and that work together well. Changing the team composition makes this teambuilding process start all over again and, as a result, productivity and self-organization suffer. Avoid loosing team members while a release is being developed. A good time for people to leave and new members to join is after the release of a new product version. But ensure that the majority of the team members continue to work on the product to avoid loss of information, defects and delays.

Last but not least, establish a long-term partnership between a Scrum team and its product; every product should be developed by one or more dedicated teams. This not only facilitates ownership and learning, but it simplifies the allocation of people and resources.

The product owner should always be a permanent member of the Scrum team. This allows the individual to manage the entire product lifecycle, from gestation to its discontinuation. It also encourages balancing short-term wins with long-term success.

Find out more about employing stable teams by reading my book Agile Product Management with Scrum or by attending my product owner course.