The product operating model has the right vision with empowered cross-functional teams organized around problems to solve, owning outcomes rather than outputs. Most product leaders understand what it looks like in theory and the potential benefit to organizations if properly implemented.
In many organizations, some form of product team exists, often consisting of a product manager, UX designer, and engineering lead at its core. Sometimes there are other roles, like data science or service designer, involved. These teams often focus on a specific workflow or part of the product. Each of these functions often has a process their function tries to use, like design thinking, CRISP-DM, or some version of an agile software delivery methodology.
Without a clear and understood unifying process for innovation, teams often feel friction, misalignment, and lack of role clarity. This leads to a lot of handoffs that focus on siloed, independent work within a team versus truly collaborative team or pod work. Since agile software delivery models are often the most entrenched from decades of digital transformations, focus can quickly shift to delivery, while everything else gets bundled together in a less structured discovery phase.
Each functional process has a lot of overlapping phases with other processes, differing slightly in name or scope. What teams would benefit from a single, uniting process that brings them together in alignment with intention for collective problem-solving, while allowing for functional flexibility with sub-process spinoffs within each phase, but always returning to collaborative work activities.
In his books, Marty Cagan tends to focus more on mindset and principles than providing a specific process. The absence of a uniting process, however, leads even well-intentioned teams down a path of siloed, functional processes from the start. Problem-solving becomes more of a buzz word or aspirational outcome than a structured way of working. In the absence of a shared process to get teams working together, even teams with the right structure and mandate spend a huge amount of time struggling to figure out how to work as one team. Pressure to deliver kicks in, leading to individual functions reverting to old ways of working, each declaring this is how “we”, the function, works. Rarely does it evolve into "we," the cross-functional organization.
The 5 Ds
The innovation process has five critical phases. Each produces an output that the next phase depends on. Each is a cross-functional learning cycle. These phases are not boxes to check, but stages of information exchange, deep understanding, application, and evaluation that must successfully complete before the next stage — the next learning cycle — can build on it.
Discover
Discover a problem that the customer is having in their experience. Start with what the customer is trying to achieve — the outcome they need, not the feature they're requesting. Then find the gap: what is preventing them from achieving it? Where does the current solution fall short, create friction, or fail entirely? The strongest input is a customer conversation, which should be treated as a learning process itself. This is a genuine exchange of information where the goal is to understand and learn, not to pitch or validate. Discovery is complete when patterns emerge across customers: shared outcomes, recurring gaps, and common points of friction that the current experience consistently fails to resolve.
Diagnose
Discovery tells you what problems customers are experiencing, while diagnosis tells you why those problems surface in the experience. The same symptom can have many causes across people, process, policy, and product. Treating the symptom without understanding underlying causes in depth produces band-aid solutions that rarely lead to sustained improvement. Diagnosis is complete when the team understands not just what is wrong within the experience, but why it persists. This identifies the specific conditions that, if addressed, would sustainably improve the customer's experience. These underlying causes are the things that need solving as part of a treatment plan, which is like a structured course plan in learning.
Define
Define takes the diagnosed causes and turns them into precise opportunity statements — what needs to change and why, what success looks like in terms the customer would recognize, and what constraints apply. These are detailed lesson plans within the course plan. This phase is consistently underinvested or bundles multiple causes, leading to lack of definition and clarity for each. It demonstrates high or surface level learning. It is a signal of an ineffective learning process in this phase and/or previous phases, which establishes a weak learning foundation for downstream phases. The result is often design work aimed at a vague target, producing solutions that are difficult to evaluate because success was never defined clearly enough to measure.
Design
Design generates solutions to the defined opportunity spaces as part of a learning process where customers can evaluate the application of what the organization understood about their problem. Think of it as a quiz or mid-term to see where the organization is at with its learning. This doesn’t just help an organization identify areas where it may have misinterpreted the defined opportunity space as part of this phase, but also where previous phases may have fallen short in establishing the learning foundation required for this phase. As the design phase completes learning cycles with feedback loops to deepen understanding, it can lead to changes to both the solution, as well as the defined opportunity space, only moving to deliver once evaluation results in a passing grade.
Deliver
Deliver is one of the larger phases, which is why it often gets so much attention within organizations and drains resourcing for earlier phases. It is a learning process, containing many sub-phases or cycles that themselves are learning processes. Since learning requires the foundation of learning in pervious phases, which are often phases of underinvestment, it is easy to see how delivery can end up with long delays and/or poor outcomes. Inadequate learning in earlier phases results in a large amount of learning being crammed into a time-constrained class. Everything becomes high level. Understanding becomes difficult and low grades are inevitable. Eventually a curve sets in and failing grades become passing grades in the eyes of the organization. This doesn’t mean that the real-world evaluator, the customer, is applying that same curve in their grading system.
Delivery functions as a college level course with a heavily weighted final exam. The customer grades it based on whether their problem was solved – whether their experience improved. This is different from how many organizations evaluate things today, which is focused on “did we ship it?” Even evaluation of adoption can be a misleading indicator, like grading on a curve. Did it improve the outcome the customer was trying to achieve? That answer, delivered honestly from the customers whose experience defined the problem, closes the cycle and opens the next one. A positive answer confirms the process worked. A partial or negative answer signals a breakdown in learning.
Each phase produces the input that the next phase needs. Skip or shortcut any phase and every subsequent phase starts from a weaker foundation. The sequence isn't arbitrary — it reflects the order in which understanding must deepen before action can be taken responsibly and effectively.
Three ways organizations struggle to learn and innovate
Most organizations fail at the innovation process in one or more of these three ways.
The first is skipping phases. Discovery is compressed into a review of existing feedback data. Diagnosis is skipped in favor of a hypothesis that feels obvious. Define gets absorbed into Design. The process runs in name, while the depth of understanding it was meant to produce never develops.
The second is treating phases as ceremonies rather than genuine learning activities. Discovery conversations happen but questions stay surface level. Diagnose sessions produce a high-level list of factors or the problem being experienced, rather than mapped, prioritized root causes. Define stages produce documents that lack clarity around the opportunity space and its constraints, or they are rarely used downstream. The artifacts get produced, but understanding doesn't deepen from them as they inform the next learning process in the chain.
The third is moving a phase forward without honest evaluation of whether it produced what the next phase actually needs. The work was done. Something was delivered. A ticket or story was closed and counted. But the individual or team that produced it is also the one declaring it ready. The proximity to the output creates blind spots that independent or cross-functional evaluation would catch. The deliverable enters the next phase looking like a sufficient input, while carrying gaps and assumptions that will surface later as delivery failures. It becomes difficult to trace back to the source for improvement, particularly when it occurs early in the innovation process. Each phase that closes without genuine evaluation produces a degraded foundation for everything built on top of it.
All three failure modes produce the same outcome: changes that don't reliably improve the customer's experience. In combination, that impact compounds. Problems persist despite increased amounts of work to solve them. And all three trace to the same root cause: the phases are treated as boxes to check rather than learning cycles that must close completely — with focused, independent evaluation — before the next one can begin.
A shared learning process
Innovation is a learning process, consisting of nested learning processes. When each function brings its own process instead of aligning around a shared process to drive organizational learning, the learning breaks down. It doesn’t build like classes and lessons within a single course, but rather a bunch of disconnected things that make understanding hard. It leads to a failing grade. Each function may feel like it is learning and getting a passing grade, but innovation requires the organization as a collective to learn and receive a passing grade from the customer.
A shared core process changes this. The 5 Ds aren't a product management framework or a UX framework. They're the end-to-end sequenced learning process for an organization that innovates and collectively solves problems — consistently. Roles and responsibilities get mapped to phases for learning to occur. Deliverables are generated as the application of what was understood, then properly evaluated. Sub-processes that follow the same learning process can spawn from the core process. Some might be specific to a single function, but they are children of the parent process that aim to deepen organizational understanding. They have a place and purpose in a larger familial learning process.
The 5 Ds improve what you create for the customer because they provide a structured way of learning for the organization to improve its ability to create. Innovation is not just about what you create — it is how you operate.