Extended Double Diamond: Process Overview

In part 3 of this playbook, we will describe the Product Management process that we have successfully applied in multiple companies. We will start with an overview of the complete process now and drill down into each phase in subsequent chapters.

Many Frameworks Focus Either on Discovery or Delivery

While the Agile Manifesto explicitly refers to customer collaboration as a core value, the product backlog in Scrum just appears “magically”. There is hardly any mention of how the items came to be, how they have been validated, and how the Four Key Risks have been addressed.

Scrum is purposefully incomplete.

Likewise, most Product Management frameworks, such as Opportunity Solution Trees or Adaptable Product Discovery, for example, suddenly stop before the actual work of building it is addressed.

This is probably due to the different audiences: Product Delivery is typically addressed by Engineering leaders who are also accountable for efficient software engineering processes. By contrast, Product Discovery is most often discussed by Product Management leaders, designers, or UX researchers.

Disconnected Teams
Disconnected Teams
We believe this separation causes a severe disconnect between teams. Of course, the different perspectives are important. Also, the level of detail and involvement will vary at different stages depending on the roles of team members. Yet, both, the Discovery and the Delivery work streams must be aligned with each other.

A Roadmap Translates Vision to Reality

When there are so many misunderstandings and misconceptions, why do we need roadmaps at all?

Secondly, roadmaps ensure internal alignment across all teams. Specifically when internal stakeholders are involved in creating the roadmap, then this process facilitates discussions of all relevant options and ensures transparency, for example to the Marketing team who might need to adjust campaigns and prepare impactful launches. Finally, roadmaps help communicate with external stakeholders, be they customers, investors, or else — see our concept of public roadmaps below.

Extended Double Diamond Inherits from Two Models

To achieve this alignment, we borrow from two popular models:

Dual Track Agile
Dual Track Agile
Double Diamond by the Design Council
Firstly, Dual Track Agile, in its simplest form, essentially describes two parallel tracks: The Discovery track focuses on testing and validating ideas, and the Delivery track for the actual work to turn these ideas into working products. Both tracks are separated but closely aligned.

Secondly, Double Diamond is a design process that consists of four phases originally called: discover, define, develop, and deliver. However, the final phase, Deliver, is actually described as:

…testing out different solutions at small-scale, rejecting those that will not work and improving the ones that will.

Instead, when we refer to Product Delivery, we think of building highly scalable, robust, and mature solutions.

Extended Double Diamond at a Glance

The following illustration gives an overview of the complete process. The Double Diamond is immediately visible, and the color-coding indicates aspects of Dual Track Agile:

Extended Double Diamond
Extended Double Diamond

The following chapters of this playbook will provide details for every single phase, including relevant tools and frameworks. For now, let’s only quickly describe them here:

Idea Collection

Collect ideas wherever they might come from.

Problem Discovery

Dive into problem space and understand the problems of customers.

Problem Definition

Prioritize and select the most important problems to tackle next.

Solution Discovery

Explore feasible solutions to solve the selected problems.

Solution Validation

Select the most promising solutions and create a plan.


Build the solution.


Ship to customers and onboard users.


Learn how to improve as an organization.

Important Aspects of the Extended Double Diamond

It’s not a Straight Sequence but a Series of Non-Linear Iterations

For illustration, the picture shows a straight left-to-right process. In reality, teams will cycle through this process and continuously work on their ideas. Adaptable Product Discovery very nicely depicts this loop.

Even worse, Product Management isn’t like clockwork. Teams cannot blindly follow from one step to the next. In particular, during the early phases of the model, they will go back and forth a lot:

Extended Double Diamond is non-linear
Extended Double Diamond is non-linear

Different Teams are Accountable at Different Stages

As the color-coding suggests, the first half is all about Product Discovery as owned by Product Management while Engineering is accountable for Product Delivery. During Distribution, many other teams might get involved, too, and for the Retrospective dedicated coaches are often employed.

Tear Down the Walls

Despite different teams being accountable, it is highly recommended that the entire product team (Product Management, UX, Engineering) is involved and engaged throughout the complete process – for example by way of product trios as described in Continuous Discovery. The degree of that involvement may vary but now and then Product Managers should get in touch with building and coding – as software engineers should listen to customers at least occasionally.

Focus on Value, not Features

As we want to provide value to customers, the model explicitly includes the Distribution phase during which:
  • The product may get optimized and polished based on the learnings from early adopter customers.
  • The availability of a product or feature might be extended from early access to limited availability to general roll-out.
  • Onboarding of users is addressed, including pieces of training, product guides, or migration aspects.

Shallow on Engineering

This is a Product Management playbook. Consequently, we mention the Product Delivery part here, we will see how the Engineering team should be involved throughout the process. But we will not touch on the details of Engineering Management or Software Engineering.

Further Reading


Product discovery vs. delivery

How to uncover what your users need.

David Pereira | LogRocket

Discovery vs. Delivery

Most of us are working on solving some pretty hard problems, and it usually ends up taking some fairly complex systems in order to power these solutions. As such, for most teams there are two very significant challenges to tackle.

Marty Cagan | SVPG

Product Management: Product Discovery and Delivery

Here is a step by step process to create roadmaps so you can influence anyone in your company like a true Jedi.