Entangled Dimensions: Why Product Strategy, Discovery & Delivery Can’t—and Shouldn’t—Be Separated
Marty Cagan’s Product Operating Model offers valuable insights. In this response, I highlight its strengths, while also exploring where we, as a software development community, can go even further.
In a recent newsletter article I wrote describing Marty Cagan’s Product Operating Model, I explored Marty’s perspective on software development that emphasizes Product Strategy and Product Discovery. That piece sparked a lot of responses, including some tough questions from long-time listeners of the Scrum Master Toolbox Podcast. If you want to go deeper into those ideas, I share exclusive takes (and some spicy behind-the-scenes context) in my private Scrum Master Toolbox newsletter—you can join it for free right here.
But today, I want to respond to Marty’s article comparing Agile with his own Product Operating Model (1).
Marty Cagan published a thoughtful piece titled “The Product Model and Agile”(1). It’s a strong read, and it raises several essential points. In it, he argues that Agile has become overly focused on delivery at the expense of product strategy and discovery. Marty’s Product Operating Model names those three dimensions clearly and challenges us to treat them as vital, distinct pillars of modern product development, while warning that “Agile is simply one of the three major dimensions of the product model.”(1) Here, I think he completely misses the point. But more on that below.
First, I’d like to be clear that I agree with Marty on several of his warnings of how Agile is applied out in the real world today.
But I also believe that some of the assumptions behind his model—and especially the idea that Strategy, Discovery, and Delivery can or should be separated—need to be re-examined.
So let’s do that. And let’s do it with respect, data, experience, and most of all, pragmatism. Just like Alice(2) likes to do!
⭐️⭐️⭐️⭐️ This post is sponsored by The Global Agile Summit, where you can find the most advanced ideas on Software, Product Development and Agile! Join The Global Agile Summit, the most forward looking Agile event of 2025
Marty’s Core Contribution: Naming the Product Development Dimensions
Let’s start with this: Marty’s critique is both timely and important.
His warning about Agile’s overemphasis on delivery (especially when delivery becomes synonymous with output, aka more features) is something many of us have witnessed firsthand. Teams obsess over velocity, story points, shipping features, checking boxes, and hitting deadlines, while quietly losing sight of whether their work is solving real problems. I’ve been in rooms where “velocity” became the only measure of success, and it was clear: we were moving fast, but not necessarily in the right direction.
So when Marty lays out the three dimensions of a modern Product Operating Model—Product Strategy, Product Discovery, and Product Delivery—he’s giving us a language that can help re-center the conversation.
I agree with this statement that these dimensions are not interchangeable. They each represent a distinct perspective on the work. They ask different questions, require different skill sets, and serve different purposes. In short:
Strategy asks what problems we should solve.
Discovery asks how we might solve them.
Delivery is all about how we build, test and deploy our solutions.
Naming this three dimensions, as Marty calls them, gives us a strong framework. And it’s useful.
But it also carries an implicit message: that these three can (and maybe should) be separated—conceptually, operationally, or even chronologically.
🛑 That’s where I think we need to press pause and ask a deeper question.🛑
What if these dimensions aren’t just distinct? What if they’re entangled—and always have been?
Quantum Product Development: Strategy, Discovery & Delivery Are Entangled in Practice
Marty’s warning about the dangers of delivery-only-focused Agile is fair, and I share that concern. If an Agile Coach or Scrum Master only knows how to run a standup or track Jira tickets, they are missing the value and the impact of Agile as a philosophy of software development and business. And yes, we do need people who can coach teams through product thinking, and who understand not just how to build things, but how to figure out the right things to build (Marty’s Product Strategy, and Product Discovery dimensions).
But here’s where I believe Marty makes the very mistake he’s warning us about. 👇
By saying that Scrum Masters and Agile Coaches are delivery-focused, and claiming that the Agile principle of “working software is the primary measure of progress” isn’t sufficient for commercial product development, he implies that we need different people to cover Strategy and Discovery—enter the Product Coach.
On the surface, that sounds logical. But isn’t that just reinforcing the siloed thinking that got us into this mess? Mel Conway would certainly suggest we are on the fast track to silo thinking!(3)
Here’s the core issue: Strategy, Discovery, and Delivery cannot be disentangled—not in time, and certainly not in structure. They are not sequential steps on a Gantt chart. They are entangled dimensions, like the axes of a 3D space. And just like in the physical world, we’re always moving along multiple dimensions simultaneously.
Alice, it’s time for a pragmatic example!
Take a simple A/B test on a landing page.
Is it a strategy activity? ✅ Yes: it’s testing a hypothesis about value propositions or audience resonance.
Is it discovery? ✅ Of course: you’re gathering evidence to inform product decisions.
Is it delivery? ✅ Absolutely: it requires real code, real infrastructure, real deployment.
Or let’s talk about a current client project I’m involved in. The team is exploring whether to prioritize a specific user segment—what in my company we call a “Product Avatar.” They could run focus groups or hire a research firm, but instead they’re deploying lightweight in-product experiments to validate real behavior. It’s fast, lean, and grounded in user data.
Now, someone standing on the sidelines might say, “But that’s delivery work! That’s output!” And sure, it involves code. But what that team is actually doing is a blend of strategic positioning, discovery through iteration, and yes—delivery as a means of learning.
Let me say that again: delivery as a means of learning. Learning about Strategy (Avatar/user segment), and Discovery through delivery (value proposition and related user activation).
The truth is: what makes a piece of work strategic, exploratory, or deliverable is not what it is—it’s what questions it’s helping to answer.
That’s it Alice! It’s all about the questions we ask!
When we stop treating Strategy, Discovery, and Delivery as separate activities, and start seeing them as overlapping lenses/perspectives, we begin to unlock a more adaptive, effective way of working. Teams don’t need to “shift modes.” They need to work in all three dimensions, fluidly, every day. And that means everyone on the team.
Dear Marty, Agile Has Moved Beyond “Just Delivery” Many Years Ago!
It’s easy to look at the Agile space and point out the flaws—teams obsessed with story points, organizations stuck in rigid frameworks, output masquerading as progress. Marty does this well. But ironically, in pointing to Agile’s overly narrow focus on delivery, he falls into the same trap: reducing Agile to its worst-case implementations, while overlooking the deep, strategic work that’s already happening across the community.
Because here’s the thing: Agile has moved on. 🚀🚀🚀
Across industries and around the world, practitioners have spent the last two decades expanding Agile beyond just delivery, and into the realms of finance, procurement, and organizational strategy.
Take Lean-Agile Procurement, pioneered by Mirko Kleiner. In his book(4), procurement becomes a collaborative, outcome-oriented process. Instead of months of RFPs and contract cycles, teams co-create value with vendors from day one, with agility baked into how business gets done even before any delivery work is done!
Or look at the field of Agile Financing. In our Scrum Master Toolbox Podcast conversation with Maarit Laanti and Rami Sirkia(5), we explored how financial planning itself is being transformed by Agile principles. Budgets aren’t static, they’re living tools aligned to learning cycles and evolving strategies. Some would even argue that budgeting is the way decisions are made up and down the organizational chart!
There’s also the Beyond Budgeting movement, which has been part of Agile circles since at least 2011(6). These ideas challenge the very structure of how businesses plan, organize, and steer: arguing for adaptability over control, and for trust over bureaucracy. That’s not delivery talk. That’s business agility in its purest form.
Even the Wikipedia entry for Business Agility captures this evolution: it’s about strategy, leadership, structure, culture. Agile has long outgrown the team room.
So yes—Marty is right to critique the version of Agile that fixates on delivery metrics. But in doing so, he risks making the same mistake: focusing too narrowly on product, and ignoring the broader transformation already in motion.
Agile is not a subset of product.
If anything, product is a subset of Agile—just one area where these principles apply. Because Agile isn’t just about what we ship.
Agile is about how we think, how we decide, and how we build companies that learn in real-time.
The Problem Isn’t Delivery! It’s the Belief That Delivery Alone, or Any Set of Siloed Dimensions Are Enough
Let’s clear something up: the problem with Agile was never that it focused on delivery.
In fact, Agile’s approach to delivery has been one of its biggest advantages. Fast feedback loops. Iterative value creation. Working software as the backbone of learning. Anyone who thinks that’s a problem probably hasn’t tried to build software without it—and if they had, they’d remember the 1980s. Shipping working software is the “ticket to play”, non-negotioable!
But here’s where things go off track.
The mistake many organizations make is this: they tell Agile Coaches and Scrum Masters to stick to their lane. And, innevitably, Agile gets implemented in the delivery lane, while product strategy and discovery stay untouched—siloed in separate functions, disconnected from the heartbeat of learning that delivery makes possible. And then they wonder why “Agile isn’t working.”
Even SAFe, for all its flaws, at least gestures toward this problem. It tries—albeit clumsily—to move beyond delivery into budgeting, architecture, governance. That impulse is worth paying attention to.
Marty’s call for more deliberate thinking around strategy and discovery is important. But his proposed solution—splitting those responsibilities out to a separate role(s) (Product Coach)—risks repeating the mistake.
We don’t need more silos. We need more systems thinking.
We need to understand that product strategy, product discovery, and product delivery are not separate disciplines. They are perspectives on the same work. And more importantly, they are powered by the same feedback loops that Agile delivery enables.
Here’s a pragmatic alternative: instead of building separate teams or roles for Strategy, Discovery, and Delivery, tag the work.
In modern work management tools, we can tag each work item with the lens it serves. One task might be pure delivery. Another might combine discovery and strategy. A third might do all three. This gives us real, usable insights into how we're balancing our attention—not through structure, but through reflection. Exactly what an Agilist would do! Reflect on observations collected during the work!
This approach brings visiblity to the aspects that Marty (quite rightly) highlights, and if also keeps teams accountable to the whole picture, not just their slice of it.
So yes, Marty’s right—we need to go beyond delivery.
But we don’t need more separation.
🔥We need integration. We need to build capability across all three dimensions inside real teams, not organizational charts. Because the real work doesn’t respect the silos anyway—and neither does the customer!
We Don’t Need More Roles, We Need to Stop Siloing the Work
One of Marty’s solution to the Agile “delivery trap” is to call for more Product Coaches—people who can guide strategy and discovery work with the same intensity that Agile Coaches have (supposedly) applied to delivery.
And listen—I’m all for expertise.
But let’s be honest: this is Conway’s Law playing out in real time. We’ve realized delivery alone doesn’t get us where we need to go… so we create another role, build another silo, and hope it all magically integrates later.
Sound familiar?
“Organizations which design systems… are constrained to produce designs which are copies of the communication structures of these organizations.” —Mel Conway
Every time we split the work across specialized lanes, we create coordination tax, delayed feedback, and fragmented ownership. We think we’re fixing the problem, but we’re just moving it. This is the opposite of what Agile asks us to consider.
The problem isn’t that Agile focuses on delivery. That’s actually one of its superpowers.
The problem is that we’ve treated delivery as an isolated function, disconnected from strategy and discovery—as if great products were ever born from perfect sprints alone.
Let’s get real: changing only delivery is not a winning strategy. We’ve seen it fail, over and over. This is Marty’s very valid point.
Even SAFe, which I’ve critiqued plenty over the years, points to something important here—it attempts to address portfolio management, architecture, governance, and budgeting. And while I don’t believe SAFe gets the implementation right, it’s poking at the correct problem: Agile must move beyond the team level.
That’s why Marty’s call to action—to elevate strategy and discovery—is valuable. But his solution risks missing the point.
We don’t need more roles to represent the work.
We need teams who can hold multiple dimensions of that work in parallel. 💥
We need systems and practices that entangle strategy, discovery, and delivery by design—not by escalation or exception. That’s why I advocate for tagging work by dimension, not assigning ownership by silo. It keeps teams grounded in outcomes, not org charts. Plus: it provides data for reflection: are we spending enough time with product strategy, discovery, delivery?
Let’s build fluency. Integration. Reflection. And the kind of collaboration that doesn’t require role handoffs to see the full picture.
Agile Is How We Learn to Build Software-Powered Businesses
Agile has never just been about product development.
At its core, Agile is a way of seeing the world—one shaped by the reality that software isn’t just another department. It’s the medium of modern business. It’s how we learn, adapt, grow, and connect in a fast-moving world.
Agile is a philosophy of business!
As a society, we’re only just now learning how to develop software effectively. And our organizations, our policies, our governance structures? They haven’t caught up yet.
They weren’t designed for software. And they certainly weren’t designed for businesses that run on software.
That’s the real challenge.
So when we talk about Strategy, Discovery, and Delivery, we’re not just talking about product. We’re talking about everything: how we fund work, how we organize teams, how we communicate with customers, how we define success.
Marty’s call for a Product Operating Model is a meaningful step forward, and it’s one I support.
But we can’t stop there.
Because the bigger opportunity—and the bigger responsibility—is to recognize that we’re building something much larger: software-powered businesses, and the philosophies, systems, and practices that make them possible.
Agile continues to offer tools, ideas, and cultural shifts for this journey. It’s not perfect. It’s not finished. But it’s alive, it’s evolving, and it’s deeply grounded in reality.
So let’s not shrink Agile down to fit into a product-shaped box.
Let’s expand the conversation.
Join me at the Global Agile Summit, and let’s keep exploring what it really takes to build the future of work—not just better products, but better organizations.
Because this moment is too important to be owned by product, or process, or any single discipline.
This moment belongs to all of us.
At the Global Agile Summit we create the space for you to meet likeminded individuals, and form a community of pragmatic innovators! Get inspired, take action!
Join us in Tallinn, and help define a better way to develop and deliver software
References
(1) Marty Cagan’s “The Product Model and Agile”: https://www.svpg.com/the-product-model-and-agile/
(2) Alice is the Avatar (perfect customer description) for the Global Agile Summit. She is focused on results, loves a tough problem, and never shys away from applying concrete and specific Agile tools to solve her problems. She knows that, out there, there are real-life stories, of people applying Agile and succeeding! And she goes to the Global Agile Summit to connect with them!
(3) Conway’s Law: Conway’s Law says that the systems we build inevitably mirror the structures of the teams that build them. So if your org chart looks like a set of silos, don’t be surprised when your product does too. And every time we invent a new role (“Product Coach,” anyone?) we risk reinforcing the very boundaries we claim to be breaking. https://en.wikipedia.org/wiki/Conway%27s_law
(4) Lean-Agile Procurement: How to get Twice the Value in Half the Time
(5) BONUS: Lean and Agile Financial planning with Maarit Laanti and Rami Sirkiä
(6) I included Beyond Budgeting as a specific track in the series of conferences title Lean Enterprise Software Systems, which were held in Helsinki (2010), Stockholm (2011), and Tallinn (2012).
Also, I love this actionable point about tagging work items with the part of the process it serves
This is probably the longest article on Substack I’ve read so far. And yet, every single sentence is filled with value.
It’s unbelievable how timely this article feels, especially considering our last conversation where I pointed out how, as a regular developer but with a strong product orientation, I find Scrum insufficient for effective product engineering.
This article helps me understand that it's not me who is not properly educated about Scrum. It turns out this is something even Agile experts are also reflecting on.
But we, poor developers, can’t dedicate our lives to studying the true nature of Agile. What we need is a framework that goes beyond Scrum and delivery—a framework that synthesizes strategy, discovery, and delivery, and guides us in our daily work.