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.
Scrum is purposefully incomplete.
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.
When there are so many misunderstandings and misconceptions, why do we need roadmaps at all?
To achieve this alignment, we borrow from two popular models:
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.
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:
Collect ideas wherever they might come from.
Dive into problem space and understand the problems of customers.
Prioritize and select the most important problems to tackle next.
Explore feasible solutions to solve the selected problems.
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.
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:
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.
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.
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.
Here is a step by step process to create roadmaps so you can influence anyone in your company like a true Jedi.
