Leading Product in Digital Engineering Organisations

In many organisations, Product and Engineering are structured as separate functions. Product Managers and Product Owners focus on customer value and direction, while engineering teams focus on technical capability and delivery.

Yet the most effective digital organisations recognise that these disciplines must work hand in hand.

In this episode of The Deep Dive, we explore how the expectations placed on Product Managers and Product Owners have evolved as digital products become central to modern organisations. Drawing on insights from Matthew Coxall’s books on product leadership, agile delivery, and organisational design, the conversation looks at how product leaders interpret strategy, collaborate with engineering teams, work with specialist expertise, and operate within complex organisational systems.

Rather than focusing on tools or frameworks, this episode takes a reflective look at the system around product work. What does strong product leadership look like today? How do Product and Engineering collaborate effectively? And why does organisational design often shape product capability more than individual skill?

If you enjoy thoughtful conversations about digital product and agile, follow the series so you don’t miss future Deep Dive episodes.

 #AgileProductHub
 #DigitalProductManagement
 #ProductOwnership
 #AgileLeadership
 #ProductAndEngineering
 #AgileHowToSeries 

Transcript

– Introduction

SPEAKER_01 0:00

Welcome to the Deep Dive, a series on digital product and agile.

SPEAKER_00 0:04

It is uh really great to be here for this one. I mean, it's such a massive topic.

SPEAKER_01 0:08

It really is. And you know, I want you, the listener, to imagine, if you will, a software team that operates with just absolute mechanical perfection.

SPEAKER_00 0:19

Right. The dream scenario. Trevor Burrus, Jr.

SPEAKER_01 0:20

Exactly. I mean, they ship every single feature on time, they hit every uh arbitrary milestone set by upper managers.

SPEAKER_00 0:27

Every project status update on the executive dashboard is just glowing perfectly green.

SPEAKER_01 0:31

Yes, perfectly green. And yet simultaneously, they drive the company straight into irrelevance or you know, worse, bankruptcy. Trevor Burrus, Jr.

SPEAKER_00 0:40

Because absolutely nobody wanted what they just spent a year building. Trevor Burrus, Jr.

SPEAKER_01 0:44

Exactly. So how does that happen? How can a team be entirely successful on paper but just a total failure in reality?

SPEAKER_00 0:50

Aaron Powell It's a great question. And it happens honestly far more often than anyone in the tech industry really wants to admit.

SPEAKER_01 0:55

Aaron Powell Yeah, I'd say it's the silent killer of modern enterprises right now.

SPEAKER_00 0:58

Oh, absolutely.

SPEAKER_01 0:59

And if you are listening to this right now, chances are you have felt the friction of that exact scenario.

– Why Product and Engineering get separated

SPEAKER_00 1:06

Yeah.

SPEAKER_01 1:06

I mean, maybe you are a senior leader trying to steer this massive organizational ship through a digital transformation.

SPEAKER_00 1:13

Aaron Powell Or maybe you're a product manager or uh an engineer in the trenches, just feeling like you are pushing a boulder up a hill every single sprint.

SPEAKER_01 1:24

Aaron Powell Right. Or maybe you're just insanely curious about why some tech companies seem to innovate effortlessly while others just get completely bogged down and endless bureaucracy, office politics, and well, missed opportunities.

SPEAKER_00 1:37

Aaron Powell We are definitely going to explore all of that today.

SPEAKER_01 1:39

Aaron Powell We are. Based on insights drawn from books by the author Matthew Coxall, we are going to look at the invisible architecture of how digital work actually gets done.

SPEAKER_00 1:47

And just to set the parameters for our discussion here, we really need to clarify what we mean by product leadership. Trevor Burrus, Jr.

SPEAKER_01 1:53

Yeah, because that term gets thrown around a lot, right? Trevor Burrus, Jr.

SPEAKER_00 1:55

It does a lot. But we are taking a very specific, calm, and analytical approach today. We're looking at this through a systemic lens.

SPEAKER_01 2:03

Aaron Powell Right. Examining the entire ecosystem of a digital organization. And I'm glad you brought that up because I want to set the tone here right out of the gate for you listening. This deep dive is not a how-to guide.

SPEAKER_00 2:16

Definitely not. We are not doing a Scrum workshop today.

SPEAKER_01 2:20

No, we are not going to give you a checklist of agile ceremonies to run through tomorrow morning. We aren't going to debate the best way to write a user story or, you know, argue about story points versus ours.

SPEAKER_00 2:32

Yeah, if you came for a tutorial on how to configure your Jiraboard, you are probably in the wrong place.

SPEAKER_01 2:37

Exactly. Our mission today is to explore product capability as a living breathing system role. We want to examine how the expectations placed on product managers and product owners have really evolved.

SPEAKER_00 2:49

Because it is no longer just about mere backlog coordination.

SPEAKER_01 2:53

Right. It's not just taking orders from stakeholders and handing them off to developers.

SPEAKER_00 2:56

No, we are talking about complex strategic leadership. Leadership that sits right at the intersection of engineering capability, customer understanding, and deep organizational alignment.

SPEAKER_01 3:08

It's a profound shift, really, in how work is conceived and executed.

SPEAKER_00 3:12

It is. And to really understand the magnitude of that shift, we have to look back at how we arrived at this current state. I mean, for decades, the default operating model for almost every major organization was what Matt calls project thinking.

SPEAKER_01 3:27

Project thinking. Man, that sounds so incredibly familiar. It sort of evokes images of those massive wall-sized got charts, doesn't it?

SPEAKER_00 3:37

Oh, the giant cascading timelines. Trevor Burrus, Jr.

SPEAKER_01 3:39

Right. The neat little dependencies, the uh comforting illusion that we know exactly what we will be doing on a random Tuesday in October of next year.

SPEAKER_00 3:47

That comfort is actually the key to understanding its appeal. Project thinking offered this incredibly seductive illusion of certainty.

SPEAKER_01 3:55

And it's crucial to remember we inherited project thinking from the industrial era, right?

SPEAKER_00 3:59

Exactly. It was designed for civil engineering, for construction, you know, manufacturing physical goods on an assembly line.

SPEAKER_01 4:05

Because when you're building a bridge, physics does not change halfway through the build.

SPEAKER_00 4:09

Right. The concrete doesn't suddenly alter its properties.

– Why digital products need a different model

SPEAKER_01 4:12

You don't get three months into building a suspension bridge and have a stakeholder walk in and say, actually, could we make this a tunnel instead? The users are really asking for a tunnel.

SPEAKER_00 4:21

A perfect analogy. In the physical world, the cost of change is just astronomical. So you do all your thinking, all your planning, and all your designing up front.

SPEAKER_01 4:30

Aaron Powell Because it was built for an era of predictability, fixed timelines, fixed scope, fixed outputs.

SPEAKER_00 4:36

Yes. The fundamental assumption was that the most important decisions about a piece of work could be made right at the very beginning, long before any actual development began.

SPEAKER_01 4:46

Aaron Powell Which, if you apply it to software, is completely backwards. I mean, in software, the moment you have the least amount of information about a product is literally the very first day you start thinking about it.

SPEAKER_00 4:57

Aaron Powell That is exactly the problem. Digital work simply does not behave like physical manufacturing. Software development is inherently exploratory. Trevor Burrus, Jr.

SPEAKER_01 5:05

Right. Customer needs aren't static, they are constantly emergent.

SPEAKER_00 5:08

A competitor launches a new feature, or you know, a global pandemic hits, user behaviors shift overnight. The underlying technology changes under our feet.

SPEAKER_01 5:17

Aaron Powell You just cannot chart that on a fixed timeline.

SPEAKER_00 5:20

You can't. And so the evolution we are seeing now, this necessary survival mechanism for modern businesses, is moving from project thinking to product thinking.

SPEAKER_01 5:30

Aaron Powell Product thinking. So it optimizes for continuous discovery, right? For adaptability. Trevor Burrus, Jr.

SPEAKER_00 5:35

Yes. And for long-term ownership of the value being created, it just asks entirely different questions.

SPEAKER_01 5:40

Okay, let's unpack this. Because what you are describing is a massive paradigm shift.

SPEAKER_00 5:45

Yeah.

SPEAKER_01 5:45

You are saying that instead of asking, when will this specific feature be done, the organization needs to ask entirely different things.

SPEAKER_00 5:53

Aaron Powell Exactly. They need to ask, what problem are we actually trying to solve and for whom?

SPEAKER_01 5:58

And what is the smallest, fastest step we can take to learn something meaningful about whether we are right?

SPEAKER_00 6:03

That is the absolute essence of it. In project thinking, success is defined by delivering the agreed-upon scope on the agreed-upon date within budget. It's internally focused.

SPEAKER_01 6:13

Right. It's about the business, not the user.

SPEAKER_00 6:14

Exactly. But in product thinking, success is defined by changing a customer behavior or solving a real-world problem that actually drives business value.

SPEAKER_01 6:23

Aaron Powell But here's the rub. There is a massive, often painful gap between an organization wanting to be agile and actually being agile.

SPEAKER_00 6:33

Oh, huge gap.

SPEAKER_01 6:34

If you look at the corporate landscape right now, it feels like almost everywhere you look, companies have aggressively adopted the terminology of agile, but completely missed the philosophy.

SPEAKER_00 6:44

They've rebranded their departments into squads and tribes.

SPEAKER_01 6:47

Right. They do the daily stand-ups at 9 a.m. They use the word sprint instead of phase, but underneath it all, the legacy structures are still completely intact.

SPEAKER_00 6:56

Aaron Powell That is what we call agile theater. And it is a devastating trap for digital organizations.

SPEAKER_01 7:02

Agile theater. I love that term.

SPEAKER_00 7:03

Aaron Powell You have these teams that have been told, congratulations, you are now an empowered, agile product team. But then you look at their operating environment, and they are still suffocating under waterfall governance.

SPEAKER_01 7:14

And for the listener who might not be, you know, deep in the weeds of project management jargon, let's define that real quick. Waterfall governance basically means you still have to go through massive sequential phase gate approvals.

SPEAKER_00 7:26

Right. You have to write a 200-page requirements document, pass it to a committee, wait a month for a signature, and then pass it to the builders.

SPEAKER_01 7:33

Aaron Powell Exactly. And you see this agile theater in the funding models, too. A supposedly agile team still relies on project-based funding that requires an 18-month business case.

SPEAKER_00 7:44

Predicting the exact return on investment before a single line of code is even written.

SPEAKER_01 7:50

Yeah. They still have these heavily matrixed reporting lines where the engineers answer to one department head, the designers answer to another, and the product person answers to a third.

SPEAKER_00 7:59

So the organization has bought the agile costumes, they have built the agile stage, but they are still performing the exact same project thinking

– The role of Product leadership

SPEAKER_00 8:08

play.

SPEAKER_01 8:08

And the result is that the product owners and product managers just get trapped. They are promised this strategic role, but they are reduced to administrative clerks.

SPEAKER_00 8:18

They essentially act as backlog groomers.

SPEAKER_01 8:21

Just formatting tickets in JIRA, chasing down approvals, and pushing other people's ideas through a broken system. And the challenge today, as Matt's work highlights, isn't just delivering software. Delivering software is actually the easy part.

SPEAKER_00 8:35

Right. The real challenge is ensuring that what gets built genuinely improves customer outcomes. That distinction between outputs and outcomes is really the watershed moment for a product leader.

SPEAKER_01 8:46

It goes back to that scenario I mentioned at the very beginning. It is so incredibly easy to sit in a monthly steering committee meeting wearing a nice suit, projecting a PowerPoint slide with your dashboards glowing and reassuring amber and green.

SPEAKER_00 9:00

Hitting every single delivery date.

SPEAKER_01 9:02

Exactly. You ship the login revamp, you ship the new checkout button, you ship the analytics integration, but you are delivering absolutely zero actual value to the customer.

SPEAKER_00 9:12

The users don't care about your green dashboard.

SPEAKER_01 9:14

No. They still abandon their shopping carts at the exact same rate.

SPEAKER_00 9:17

That image of the glowing green dashboard is so poignant because it perfectly captures the illusion of progress. It is movement without direction. You're delivering outbuts, things you made. You are not delivering outcomes changes in the world that create value. Right. And if your organizational system retains centralized control over funding and priorities, if some executive suite is dictating the features without talking to a single customer, the product manager role completely collapses.

SPEAKER_01 9:45

They cannot lead. They can only coordinate the delivery of someone else's unvalidated assumptions.

SPEAKER_00 9:50

Exactly.

SPEAKER_01 9:51

So if we pivot here, if the goal is actually delivering value rather than just hitting dates on a spreadsheet, the product leader's job fundamentally changes.

SPEAKER_00 10:00

It has to.

SPEAKER_01 10:01

They can't just follow a pre-written project plan anymore because the plan is likely flawed from day one. They have to actively interpret what the business actually wants to achieve. They become interpreters.

SPEAKER_00 10:11

Yes. Matt calls them interpreters of intent. And it is perhaps the most vital function they perform. Well, if you take a step back and think about high-level organizational strategy, it is almost always articulated at a 30,000-foot view. It's abstract by necessity.

SPEAKER_01 10:27

Right, like a CEO saying, we need to increase market share in the enterprise sector by 20%.

SPEAKER_00 10:32

Or we need to radically improve user retention over the first 30 days. That is the corporate ambition. But that ambition rarely, if ever, translates directly into specific product decisions on the ground.

SPEAKER_01 10:45

Aaron Powell Yeah, the CEO strategy doesn't tell the engineering team whether to build a new notification system or what database architecture to use or what the UI should look like.

SPEAKER_00 10:54

There is a massive void between increase retention and write this specific line of code.

SPEAKER_01 11:00

And nature abhors a vacuum.

SPEAKER_00 11:02

Exactly. If no one translates that high-level intent, teams will just guess. So the product manager or product owner steps into that void to provide that critical interpretive layer.

SPEAKER_01 11:11

They take that corporate ambition and translate it into meaningful direction.

SPEAKER_00 11:15

Yes. They explore how that high-level intent should influence problem exploration. They look at the data, they talk to the users, and they say, okay, to improve retention, our research suggests we need to fix the onboarding flow because users are getting confused on day two.

SPEAKER_01 11:31

Without that interpretive layer, strategy becomes completely disconnected from delivery. You can have an engineering team working incredibly efficiently, writing beautiful, bug-free code, deploying multiple times a day, moving incredibly fast, but moving in a direction that completely fails to support the broader organizational objectives.

SPEAKER_00 11:52

Exactly.

SPEAKER_01 11:53

I want to illustrate this because Matt uses an analogy in the source material that is just so vivid. It's the suitcase and the trip to Antarctica analogy.

SPEAKER_00 12:02

It's a brilliant way to visualize the danger of misaligned assumptions.

SPEAKER_01 12:05

Yeah, I want you, the listener, to picture this scenario in your own office. So imagine you are a leader. You gather your entire cross-functional team in a big conference room. You have your product folks, engineering leads, design team, business stakeholders.

SPEAKER_00 12:18

Everyone is there.

SPEAKER_01 12:18

Right. You stand at the front of the room and you announce with total enthusiasm and corporate vigor team, we are going on a trip.

SPEAKER_00 12:27

And you look around the room and everyone is smiling. Yeah. Everyone nods in agreement.

– When Product and Engineering drift apart

SPEAKER_01 12:32

Yes. The phrase sounds so simple, so universally understood. Everyone in that room feels completely aligned. There is zero apparent confusion. So you conclude the meeting and tell everyone to go home and pack their bags.

SPEAKER_00 12:45

But then let's look at what happens in isolation.

SPEAKER_01 12:47

Right. The product person hears the word trip and immediately frames it around user problems and relaxation. They pack shorts, sunglasses, flip-flops, maybe a light novel. They are imagining a warm beach destination.

SPEAKER_00 13:00

Makes sense for them.

SPEAKER_01 13:00

Totally. Then the engineering person hears trip and their brain goes to architecture, constraints, and survival. They pack sturdy hiking boots, a multi-tool, maybe some technical climbing gear, and a water filtration system.

SPEAKER_00 13:13

They're preparing for the worst case scenario.

SPEAKER_01 13:15

Exactly. And design hears trip and packs for usability, aesthetics, and interaction flow. They bring a high-end camera, lightweight clothes for urban sightseeing, a sketchbook.

SPEAKER_00 13:24

So they are all totally aligned on the phrase, we are going on a trip.

SPEAKER_01 13:28

But their internal, unspoken interpretations of what that phrase actually implies are vastly, wildly different.

SPEAKER_00 13:35

And the tragedy is that they don't know they are misaligned. They all show up the next morning at the airport, bags packed, energy high, ready to execute.

SPEAKER_01 13:44

And then you, the leader, reveal the destination. You say, All right, team, we are going to Antarctica.

SPEAKER_00 13:49

Aaron Powell And the silence in the room is just deafening.

SPEAKER_01 13:51

Aaron Powell You can hear a pin drop. Every single assumption, every single piece of preparation collapses at the exact same moment. I mean, the product person is shivering in their flip-flops.

SPEAKER_00 14:02

What is so crucial to take away from that story is that no one in that group failed. No one was careless or lazy or acting maliciously. Everyone acted in entirely good faith based on their professional lens, but they all filled in the blanks of that high-level strategy differently.

SPEAKER_01 14:16

Because a product manager hears a strategic goal and imagines user impact. An engineer hears the exact same goal and imagines system load and technical debt.

SPEAKER_00 14:25

A business stakeholder hears it and imagines commercial risk and quarterly revenue. The sentence is shared, but the interpretation is fundamentally fragmented.

SPEAKER_01 14:34

Which means alignment, real functional alignment, is not just nodding your head and agreeing on a sentence in a kickoff meeting.

SPEAKER_00 14:42

Far from it. Alignment is not merely agreement, it is shared understanding.

SPEAKER_01 14:47

A shared mental model of reality.

SPEAKER_00 14:50

Yes. And that is why the interpretive layer provided by strong product leadership is so vital. Great teams do not avoid assumption gaps. They actively hunt for them. They surface them early.

SPEAKER_01 15:02

They build shared meaning intentionally. They ask the annoying probing questions. When you say trip, do you mean a cold trip or a warm trip? Are we walking or flying?

SPEAKER_00 15:11

Exactly. They align mentally long before they try to align operationally.

SPEAKER_01 15:14

And this touches on a profound difference in terminology that Matt brings up. The difference between intent and plans. Let's say you did give that team a rigid, hyper-detailed project plan for Antarctica instead of just a vague intent. What happens when they get to the airport and the flight to Antarctica is permanently canceled due to a blizzard?

SPEAKER_00 15:32

The plan shatters. Plans are incredibly brittle constructs. They age rapidly because they are based on assumptions made at the very beginning of the journey.

SPEAKER_01 15:41

Which is precisely when you have the least amount of information.

SPEAKER_00 15:45

And the highest amount of ignorance. If you manage by rigid plans, the moment reality diverges from the spreadsheet, the team is paralyzed.

SPEAKER_01 15:53

They have to stop, go back up the chain of command, and ask for a new plan.

SPEAKER_00 15:57

But intent is different. Intent is the antidote to brittleness. It explains why the choices are being made. It's rooted in the military concept of commander's intent.

SPEAKER_01 16:06

Right, providing a clear direction and a desired end state without prescribing the exact step-by-step behavior to get there.

SPEAKER_00 16:14

Exactly. If the intent is made crystal clear, for example, we must reach the Antarctic ice shelves to extract core samples to understand climate change. Then when the flight have canceled, the team doesn't freeze.

SPEAKER_01 16:24

They can adjust their approach organically, they can pool their resources and charter a reinforced boat, or change their logistics.

SPEAKER_00 16:31

They do not lose their alignment because the why holds them together even when the how falls apart. Strategy in a digital organization should always be direction, not instruction.

SPEAKER_01 16:42

But let's take that from theory into the messy reality of a modern office. I mean, interpreting strategy and sharing intent sounds beautiful in an academic sense.

SPEAKER_00 16:50

It does.

SPEAKER_01 16:51

But in the real world, those different interpretations clash. They collide hard.

SPEAKER_00 16:57

Oh, absolutely.

SPEAKER_01 16:58

When you have highly intelligent, opinionated specialists in a room, how does a team navigate those clashes without grinding to an absolute

– What strong organisations do differently

SPEAKER_01 17:06

halt?

SPEAKER_00 17:06

That brings us right to the beating heart of decision-making in digital ecosystems. In modern organizations, you have an incredible, almost overwhelming number of voices contributing to a product's direction.

SPEAKER_01 17:17

It's a cacophony of valid perspectives.

SPEAKER_00 17:19

Yes. You have customers actively expressing their needs and frustrations. You have business stakeholders articulating commercial opportunities and market pressures. You have engineers identifying technical constraints, security vulnerabilities, and system risks.

SPEAKER_01 17:32

And you have designers advocating for cognitive behavioral flows and accessibility. It's so many voices. And they all think they're the most important voice in the room.

SPEAKER_00 17:42

Naturally.

SPEAKER_01 17:43

There is a story Matt shares in the sources about a refinement session. And uh, for those listening who might not use that term, a refinement session is basically a meeting where the team looks at upcoming work and tries to figure out the details before they start building it.

SPEAKER_00 17:57

Right. A very standard agile practice.

SPEAKER_01 17:59

Aaron Powell So the team walks into this meeting. They thought they were completely aligned, they had looked at the roadmap, the dependencies seemed fine, everyone was calm. And then a real tangible decision arrived on the table regarding a specific feature.

SPEAKER_00 18:12

And that calm superficial alignment instantly fractured.

SPEAKER_01 18:16

Right into four entirely different realities. It was like looking through a prism. Engineering looked at the proposed feature and immediately saw a massive performance risk that could crash the database.

SPEAKER_00 18:27

Design looked at the exact same feature and saw behavioral friction that would confuse the user and ruin the interface.

SPEAKER_01 18:33

Product saw that the core value proposition was being watered down to appease a deadline.

SPEAKER_00 18:39

And the business stakeholders saw that this technical change might delay another dependent organizational initiative they had promised to the board.

SPEAKER_01 18:47

They were all looking at the exact same problem but seeing entirely different, deeply held truths.

SPEAKER_00 18:52

Exactly.

SPEAKER_01 18:53

Which makes me want to push back a little bit here on behalf of the listener who is thinking about their own agonizing meetings. If everyone has a valid point, and let's be honest, in that scenario, engineering, design, product, and business are all objectively correct in their specific domains.

SPEAKER_00 19:09

They are.

SPEAKER_01 19:10

Doesn't collaborative decision making just turn into an endless, exhausting negotiation? If we say everyone's voice matters and everyone effectively has a veto, nothing ever ships. You just get stuck in analysis paralysis.

SPEAKER_00 19:22

What's fascinating here is that your pushback highlights exactly why the concept of decision ownership is so critical.

SPEAKER_01 19:29

Okay, tell me more about that.

SPEAKER_00 19:30

There is a massive industry-wide misconception that collaboration means consensus. It absolutely does not.

SPEAKER_01 19:37

Consensus is the enemy of innovation.

SPEAKER_00 19:39

Right. Consensus means we keep arguing until we find the lowest common denominator that no one vehemently objects to.

SPEAKER_01 19:45

So clear ownership doesn't mean you have an isolated dictatorial product manager sitting in an ivory tower handing down edicts and ignoring everyone else.

SPEAKER_00 19:54

Exactly. Collaboration is how you explore the problem space deeply, but ownership is how you resolve it.

SPEAKER_01 20:01

So someone ultimately has to break the tie. Someone has to make the call.

SPEAKER_00 20:06

It is even deeper than just breaking a tie. It means someone is structurally responsible for ensuring the final decision remains coherent, purposeful, and aligned with the overarching product vision.

SPEAKER_01 20:17

Think about the alternative. Without clear boundaries and constraints on who owns the final decision, strategy just devolves into a vague compromise.

SPEAKER_00 20:26

The alignment erodes because you end up building what Matt might refer to as a Frankenstein product.

SPEAKER_01 20:31

Oh, I've seen those. You bolt on a feature to appease the engineer's risk tolerance, you tweak the interface to satisfy the designer's aesthetic, and you cut corners to hit the stakeholder timeline.

SPEAKER_00 20:40

And the result is a monster that completely misses the customer's actual need. The product leader has to carry the heavy responsibility of maintaining that coherence. They listen to the friction, they value the input, and then they decide the path forward.

SPEAKER_01 20:55

So once a product leader owns that direction and makes that hard call, how do they bring the delivery team along? Because you just said it's not a dictatorship.

SPEAKER_00 21:03

No, it's not.

SPEAKER_01 21:04

You can't just synthesize all this complex strategy, walk out of a conference room, hand a JIRA ticket to a developer, and treat them like an assembly line worker putting a bolt on a chassis. If you do that, you lose all the value of their technical insight.

SPEAKER_00 21:19

Absolutely not. And if you treat engineers like typists who just translate requirements into code, you will fail. Right. The partnership between product and engineering is arguably the most critical relationship in the entire organizational system. Product direction isn't handed down from a mountaintop, it emerges through shared understanding.

SPEAKER_01 21:37

And this is where we need to dive into the fundamental difference between shared work and sequential work. This reminds me of another brilliant concept from the sources the drift. If you are listening to this, I guarantee you have experienced the drift. It is such a common trap.

SPEAKER_00 21:52

Oh, it happens everywhere.

– Product, Engineering, and shared delivery

SPEAKER_01 21:54

It goes like this you have a product team and an engineering team, and they kick off a Major new initiative. The kickoff meeting is great. Total confidence. High fives all around.

SPEAKER_00 22:05

Everyone leaves feeling great.

SPEAKER_01 22:07

Then product goes off to their corner of the office to refine the user flows, write the acceptance criteria, and talk to customers. Engineering goes off to their corner to build the technical foundation, provision the servers, and sort out the data architecture.

SPEAKER_00 22:21

And they both think they are being incredibly efficient. They think we are dividing and conquering, we are staying in our lanes, we are optimizing our time.

SPEAKER_01 22:29

Exactly what they think. But then, three weeks later, they reunite to integrate their work. And the pieces completely fail to fit together.

SPEAKER_00 22:37

It's like they were building two halves of a bridge from opposite sides of a river, and they meet in the middle and they are three feet apart.

SPEAKER_01 22:44

Yes. Product designed a user direction that relied on real-time system behaviors the engineers didn't prioritize. Engineering built a robust back-end architecture that assumed a completely different, much slower user flow.

SPEAKER_00 22:58

They didn't do anything wrong maliciously. They weren't incompetent. They just drifted.

SPEAKER_01 23:02

That drift is the direct, inevitable result of sequential work. It is the lingering ghost of project thinking, where we assume one phase neatly finishes before the next phase begins. First we design, then we build.

SPEAKER_00 23:14

But in product thinking, product and engineering must operate as a unified, interwoven force from the very earliest stages of discovery.

SPEAKER_01 23:22

Right. Product brings the deep insight into user psychology, market viability, and business value. Engineering brings the deep insight into technical feasibility, system sustainability, and security risks.

SPEAKER_00 23:33

They cannot work in silos. They have to develop a shared language.

SPEAKER_01 23:37

A shared language. That sounds nice on a motivational poster, but what does that actually look like in practice on a random Tuesday morning?

SPEAKER_00 23:44

It looks like continuous informal negotiation. It means that when a product manager says, we need this feature to be fast to deliver to market to test an assumption, the engineer doesn't secretly interpret that as I have permission to hack together a fragile, undocumented architecture that will collapse in six months. They use early whiteboard sketches, they run technical spikes, which are essentially time-boxed experiments to figure out if an idea is technically possible before committing to building it.

SPEAKER_01 24:18

Aaron Powell They do quick, informal checks of understanding. They reason about trade-offs together out loud. If we build it this way, we save two weeks, but we increase technical debt. Are we okay with that?

SPEAKER_00 24:28

Aaron Powell When they do that, they don't drift. They maintain their momentum because they are constantly micro-realigning.

SPEAKER_01 24:33

Aaron Powell And there's a profound psychological element to this collaboration too, specifically regarding the engineers who are actually writing the code and building the product. The sources cite this striking statistic from the renowned computer scientist Gerald Weinberg.

SPEAKER_00 24:46

Yes, the context switching stat.

SPEAKER_01 24:48

He noted that context switching can cost a developer up to 80% of their daily productivity. Let that sink in for a second for everyone listening. 80%.

SPEAKER_00 24:58

It is a staggering number to read, but anyone who has ever written complex code or done any form of deep analytical work knows in their bones that it is true.

SPEAKER_01 25:07

Aaron Powell Software development is not repetitive mechanical work.

SPEAKER_00 25:11

No, it is deeply cognitive. It requires sustained, uninterrupted concentration. Think about what a developer is doing. They are holding a massive, invisible, complex mental model of a system architecture in their head.

SPEAKER_01 25:25

Aaron Powell It's like building a cathedral out of pure thought.

SPEAKER_00 25:28

Aaron Powell Exactly. And if they get pulled into a mandatory 30-minute status meeting or a random stakeholder sends a Slack message asking them to context switch to investigate a bug on a different product, that mental cathedral shatters.

SPEAKER_01 25:40

It just collapses.

SPEAKER_00 25:41

It can take 20 to 30 minutes just to regain that flow state and rebuild that mental model after a single interruption.

SPEAKER_01 25:47

Aaron Powell So if you interrupt a developer five times in an eight-hour day, the day is basically gone. The productivity is completely destroyed, even if they were technically at their desk the whole time.

SPEAKER_00 25:57

Aaron Powell Which is why we need to talk about protection.

SPEAKER_01 25:59

Aaron Powell Right, because this proves something crucial. Good product leadership is also fundamentally good engineering leadership. A strong product leader actively protects that deep work.

SPEAKER_00 26:11

They are ruthless about limiting the work in progress.

SPEAKER_01 26:14

They act as a heat shield against stakeholder disruptions, deflecting the noise so the engineering team can actually maintain their flow state and build the thing.

SPEAKER_00 26:22

That is the very essence of servant leadership in a modern context. You aren't managing the engineer-specific tasks, you are curating and defending the environment around them so they can solve complex problems without unnecessary cognitive load.

SPEAKER_01 26:35

Aaron Powell You are removing the friction from the system.

– Organisational systems and structural friction

SPEAKER_00 26:38

Aaron Powell Yes. But let's expand the lens here because it's not just product and engineering in the room anymore. If you look at modern digital products, banking apps, global e-commerce platforms, AI-driven healthcare tools, they are wildly complex.

SPEAKER_01 26:53

Aaron Powell You have this whole network of brilliant specialized minds required to make something work at scale.

SPEAKER_00 27:01

Yes. And we need to address a very damaging myth. There was this early misinterpretation of Agile that suggested you just need a cross-functional team of purely interchangeable, full-stack developers who can do everything, and therefore you don't need deep specialists. Right. That is incredibly naive and dangerous. Modern digital ecosystems rely heavily on deep focused expertise, system architects, UX designers, business analysts, data scientists, security experts.

SPEAKER_01 27:30

Here's where it gets really interesting.

SPEAKER_00 27:32

Yeah.

SPEAKER_01 27:33

Because historically, in the project thinking days, those specialists acted as gatekeepers.

SPEAKER_00 27:38

Oh, absolutely. They sat outside the agile team in their own little department.

SPEAKER_01 27:41

Yeah, you do your two-week sprint, write your code, and then you'd have to submit your work to the architecture review board and wait a month for approval. Or you'd have to wait three weeks for the centralized UX team to hand you a polished design file before you could even start building.

SPEAKER_00 27:54

And that model completely breaks the iterative flow. It turns agile right back into waterfall. It creates bottlenecks and handoffs.

SPEAKER_01 28:02

So the evolution of the product leader's role now requires them to weave those specialists directly into the fabric of the team's daily discovery and delivery. Specialists are no longer external approvers, they are internal collaborators.

SPEAKER_00 28:17

Exactly.

SPEAKER_01 28:18

So how does a product leader actually orchestrate that? How do they drive sustainable delivery with all these specialists without becoming a bottleneck themselves?

SPEAKER_00 28:26

They do it by balancing the immediate tactical priorities of the current sprint with the long-term strategic health of the product and the business.

SPEAKER_01 28:34

Can you give an example?

SPEAKER_00 28:36

Think about the role of a system architect. If a product team is just churning out user-facing features sprint after sprint without any architectural guidance, they are going to build a fragmented, unscalable system that will eventually collapse under its own weight.

SPEAKER_01 28:50

Right. So the architect is there to ensure modularity and technical integrity.

SPEAKER_00 28:54

A UX specialist ensures that accessibility, usability, and human friction aren't just afterthoughts slapped on at the end of a release cycle. Analysts bridge the gap between high-level business goals and actionable team tasks.

SPEAKER_01 29:08

And data scientists ensure that the team is making evidence-based decisions, measuring actual user behavior rather than just relying on the loudest executive's gut feelings.

SPEAKER_00 29:18

So the product leader doesn't replace these experts. They don't have to be the best designer or the best coder in the room. They orchestrate them.

SPEAKER_01 29:25

They synthesize all these deeply specialized insights into one coherent, forward-moving product direction. And I imagine when that synthesis fails, or when a PM ignores those specialists, the product just violently drifts between competing priorities. Oh, adept of one sprint it's all about making the UX pretty, the next sprint the servers crash and it's a panic architecture refactor. And the next sprint the business demands a new revenue feature. It's whiplash.

SPEAKER_00 29:50

Whiplash is the perfect word for it. The product manager operates within a dynamic network of expert perspectives. If they can successfully synthesize that network, if they can hold the tension between those competing needs, the product decisions become incredibly robust and sustainable.

SPEAKER_01 30:06

Okay, so we have painted this beautiful, idealized picture of modern digital delivery. We have a product leader who gracefully interprets high-level strategy, who owns the hard decisions without being a dictator, who valiantly protects the engineering slow state, and who perfectly orchestrates a symphony of UX designers and architects.

SPEAKER_00 30:26

It sounds like a tech utopia.

SPEAKER_01 30:27

It does. But what happens if the company they work for is fundamentally structurally broken? What if the organizational soil is toxic?

SPEAKER_00 30:35

If we connect this to the bigger picture, this is where everything we've talked about meets harsh reality. Product capability is not just an individual skill.

SPEAKER_01 30:44

You cannot just hire a rock star product manager and expect them to fix your company.

SPEAKER_00 30:49

Exactly. Product capability is deeply, profoundly constrained or enabled by the organizational system itself. The reporting structures, the funding models, the governance patterns, the behaviors modeled by senior leadership. These elements form the invisible architecture that strictly dictates what a team can actually achieve.

SPEAKER_01 31:08

This brings to mind another powerful story for Matt's work. It's the story of the perfect product team. On paper, this team was flawless.

SPEAKER_00 31:18

They had deep alignment on their goals.

SPEAKER_01 31:20

Elite technical skill. They had deep psychological safety and trust among the team members. They genuinely wanted to do great work.

SPEAKER_00 31:27

And yet they struggled painfully.

SPEAKER_01 31:29

Painfully. And not because of anything they were doing wrong. They struggled because of the invisible architecture.

SPEAKER_00 31:34

Right. The engineers on this single, supposedly unified team reported to three different managers in three different departments, each with competing yearly KPIs.

SPEAKER_01 31:43

Their UX designers were matrixed across five different products, meaning they were split so thin they could never get focus time to deeply understand one user base.

SPEAKER_00 31:52

The critical back-end database systems they relied on to build their features were owned by a completely different legacy department with a completely different roadmap that updated every six months.

SPEAKER_01 32:03

Every single tiny dependency required a treaty negotiation between directors.

SPEAKER_00 32:08

And that is the tragedy of a poorly designed organizational system. It is a fundamental truth of organizational psychology. People do not behave according to their written job descriptions.

SPEAKER_01 32:18

They behave according to the system they sit within.

SPEAKER_00 32:21

Exactly. They respond to the incentives, the dependencies, and the constraints placed upon them. Good, capable, well-intentioned teams are routinely, systematically failed by structures that fragment responsibility and create endless bureaucratic handoffs.

SPEAKER_01 32:36

It's like the analogy of dragging a brick and suitcase behind you through an airport.

SPEAKER_00 32:40

Oh, that's a good one.

SPEAKER_01 32:41

You, the listener, might be the strongest, fastest traveler in the world. You might have trained for months. But if the wheels on your suitcase are busted and the handle is jammed, you are going to be exhausted just trying to move forward 10 feet. The friction of the system overwhelms individual capability.

SPEAKER_00 32:57

A very apt metaphor. And this systemic friction often comes down to the signals that senior leaders send. Leaders are, whether they realize it or not, the designers of the system.

SPEAKER_01 33:08

If a senior leader stands up in a massive company town hall and declares, we value outcome-driven product teams who take risks, but then later that week pulls a product manager aside and angrily asks, What is the exact delivery date for this specific button and why is it two days late? The team immediately hears the real signal.

SPEAKER_00 33:29

The town hall was noise, the reprimand is the signal.

SPEAKER_01 33:32

Right. They instantly shift their behavior toward activity over progress. They focus on output over outcomes. They optimize for green dashboards, not customer value.

SPEAKER_00 33:40

The system overrates the intent every single time. If a company tells a product manager in their interview that they are expected to lead strategic direction, but then the finance department retains total centralized control over funding and requires a rigid 50-page business case for every minor pivot.

SPEAKER_01 33:55

The PM role just collapses back into project coordination. You are a glorified accountant at that point.

SPEAKER_00 34:01

Which brings us to the ultimate synthesis of this entire discussion and the core thesis of Matt's insights. Strong, resilient product organizations are not built around heroic individuals fighting against a broken system.

SPEAKER_01 34:13

Heroics do not scale.

SPEAKER_00 34:15

No, they don't. Heroics depend on someone working weekends, burning political capital, and fighting endless battles. And inevitably, heroics lead to burnout. The heroes leave, and the broken system remains.

SPEAKER_01 34:29

So, what does this all mean for the listener? If you are sitting in one of these organizations right now, maybe feeling that whiplash, maybe feeling the weight of that broken suitcase, how do you make sense of this? What is the path forward?

SPEAKER_00 34:39

It means we must recognize fundamentally that product management is a system capability. It is not just a job title.

SPEAKER_01 34:46

The modern product manager represents the critical convergence point where corporate strategy, deep customer understanding, and actual delivery capability meet.

SPEAKER_00 34:54

But they cannot function in a vacuum. They cannot do it alone. True harmony in a digital organization is not the absence of conflict.

– Final reflections and close

SPEAKER_01 35:02

You actually want healthy conflict, right? You want the friction between engineering's risk awareness and product's drive for rapid value. You want the debate.

SPEAKER_00 35:10

Exactly. Harmony is the presence of structural alignment. It is an organizational environment that naturally allows creativity, speed, and sustainable value delivery to emerge precisely because the system is designed to support it.

SPEAKER_01 35:24

That's a massive cultural shift. It means a moving away from that traditional, top-down, control the industrial era, command and conquer style of management where leaders dictate and workers execute.

SPEAKER_00 35:36

It means moving toward a horizontal, influence-based servant leadership.

SPEAKER_01 35:41

It requires aligning the strategy, the teams, the deep expertise, and the decision-making pathways so that doing the right thing for the product is the easiest path, not the hardest path.

SPEAKER_00 35:50

Precisely. The system must be meticulously designed to allow good product decisions to emerge naturally, rather than forcing individuals to fight the system just to do their jobs.

SPEAKER_01 36:00

I want to leave you, the listener, with a final provocative thought to mull over today. Whether you are heading into a refinement session, a steering committee, or just sitting down to write some code. Think about the biggest bottleneck or friction point in your current digital team right now.

SPEAKER_00 36:17

The specific thing that drives you crazy every single sprint.

SPEAKER_01 36:20

Exactly. Is it truly a failure of the people involved? Are your colleagues really lacking skill or motivation? Or is your organization perfectly designed to produce that exact friction? Are you dragging a broken suitcase behind you?

SPEAKER_00 36:36

That is a deeply powerful question to take back to your teams and a great place to start designing a better system.

SPEAKER_01 36:41

Thanks for joining us for this deep dive on digital product and agile. If you found the conversation useful, follow the series so you don't miss future episodes exploring how product leadership and organizational systems evolve.