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 now start with an overview of the <Customhighlight>extended double diamond</CustomHighlight> model 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.

— Maarten Dalmijn

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.

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

Extended Double Diamond Inherits from Two Models

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

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, originally 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:

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.

Delivery

Build the solution.

Distribution

Ship to customers and onboard users.

Retrospective

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

The picture illustrates a straight left-to-right process. In reality, teams 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:

Different Teams are Accountable at Different Stages

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

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.
A product or feature's availability 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. However, we will not touch on engineering management or software engineering details.

Table of Contents