Who Decides? Sorting Out Product Managers, Project Managers, and Product Owners

Product manager. Product owner. Project manager. Three roles that often exist in the same organization, sometimes in the same meeting, and frequently stepping on each other's toes. In this episode, Dave and Peter break down what actually separates these roles, why the confusion happens, and what it costs when the lines blur in the wrong ways.

They dig into the difference between a project-centric operating model and a product operating model, and why that distinction matters more than most organizations realize. They also get into a concept Peter uses with clients: product owners reduce decision latency, project managers reduce reporting latency. It sounds simple, but the implications reach into how teams are funded, how authority is distributed, and why some transformations stall halfway.

The conversation covers real patterns from the field, including what happens when a technical project manager spends most of his time coordinating 14 dependency groups just so a product owner can get a decision made, and what it looks like when a project-centric funding model quietly undermines a product operating model that was never quite finished.

They also touch on where AI fits into all of this, and where it currently falls short as a bridge between these two worlds.

Three key takeaways from this episode:

1. It's not either-or. Both project management and product management are necessary. The goal is to use each skill set in the right place, not to eliminate one in favor of the other.
2. The relationship between product managers and project managers works best as a true peer-to-peer dynamic. Hierarchy between the two tends to break things down quickly.
3. Be clear about decision-making authority. If your product owners don't actually have the autonomy to make decisions, the role isn't working. And if your project managers exist primarily to satisfy a funding model that doesn't match your operating model, that's a signal to look at finishing what you started.

If this is a conversation your team needs to have, share this episode with them. And if you're finding value in Definitely Maybe Agile, follow the show on your favorite podcast platform so you never miss an episode. New conversations drop every week.

Transcript

Welcome And Role Confusion

Peter [0:04]: Welcome to Definitely Maybe Agile, the podcast where Peter Maddison and Dave Sharrock discuss the complexities of adopting new ways of working at scale.

Dave [0:12]: Hello Peter, how are you today?

Peter [0:14]: Excellent, excellent. I'm glad we get a chance to have this conversation. I think this has been brewing for a while. Our discussion today is product managers and project managers. How they operate, what the expectations are on them in an organization versus project managers, and why there might be overlap, conflict, whatever may come out of that.

Dave [0:38]: And I think we're going to talk about product owners as well.

Peter [0:41]: Yes, absolutely.

Dave [0:44]: When I think product management, I think of that product management function as a whole, which is product managers and product owners working together. There's a lot of swapped role titles there that can get confusing.

Project Model Versus Product Model

Peter [0:57]: So we probably should start by defining what we mean by these various different roles.

Dave [1:03]: Let me start on the product side, because that might be causing half the headache. And there's something underlying this, which is the operating model they work in. If we think of two fundamentally different operating models, one is a project-centric model. The packages of work are well-defined, substantial projects, and a project manager is likely responsible for delivering one or more of those well-defined packages of work that traditionally have a beginning, an end, a budget, a timeline, a bucket of scope that has to be delivered.

Peter [1:40]: On time, on budget.

Dave [1:41]: On time, on budget, yeah. And the product role is really tied to product operating models where there's a continuous flow of work to improve a product. I always think of this one as a conveyor belt. There's no beginning and end. There's a delivery of a range of different things that improve some experience for an end user, whether that's employees using an HR system or customers, whoever it may be. Things that make them happier, more likely to stay, more likely to spend.

Decision Latency And Real Outcomes

Peter [2:16]: With project managers, we've typically got a very well-defined target. We know what we're trying to achieve. Whereas with a product manager, it's generally more exploratory. We're looking to evolve the product toward a solution and adapt it as the user base changes, as the industry changes, as everything around it shifts. Products work better in a more volatile environment. And one of the lines I've been using, which sparked your interest in having this conversation, was this idea that product owners reduce decision latency and project managers reduce reporting latency.

Dave [3:03]: Right.

Peter [3:03]: Which might make it sound like I don't value project managers. That's not quite true. Project managers have a very distinct role and a lot of valuable skills. Not all project managers are made the same either. They both play a role in creating value within an organization, but they tend to deal with different types of problems.

Dave [3:26]: My thinking around this has really sharpened recently around the abstraction of what we're measuring. When I think of project managers and how projects are structured, I feel like they're built for a world where being slightly distant from the actual outcomes is acceptable. Say you're introducing new functionality to increase customer retention. In a project world, the assumption is we know that if we make these changes, we'll get the positive effect we need. So I don't need to measure that positive effect directly. I can use a proxy. How many features have we delivered? Are we on time, on budget, within scope? All of that is an abstraction away from whether we're actually achieving the result we want.

Product managers can't work with that abstraction. They have to work with the actual data. They need to see retention numbers changing. They need to see people returning, engaging, using their product. And typically that's not just a philosophical preference, it's because things change fast enough that if they're not close to it, they'll lose track of what's happening.

Peter [5:09]: That gives me a nice segue to explain the difference I see between a product manager and a product owner, because I see those two roles as slightly different. A few years back I was working in the CPG space, consumer packaged goods, where you have roles called brand managers. Brand managers have oversight of decision making across an entire brand. It feels to me like we took that concept into the technology space and said, well, the one person being able to understand everything, including enough about the technology to make decisions on that side, is a lot to ask. So we kind of split the role in two. Product managers hold the direction, the strategy, where we're taking this product and what it needs to do. Product owners are essentially there to reduce the decision latency of the technical teams who are building and trying to figure out where to go. They need someone who can help them make decisions quickly so the team can adapt as the market and industry change.

What A Technical Project Manager Does

Dave [6:30]: It's a problem of scale. When you've got one single team, the product owner and product manager are pretty much the same individual. But as you scale, that changes. Totally agree. I think we're on the same page there.

Peter [6:45]: And then we've got project managers. My anecdotal story here is from working in a large bank, as I quite often have. I sat down with a TPM, a technical project manager, and asked him about his role, basically mapping out what the system was doing. He explained that his role was largely twofold. First, he prepared all the status and financial reporting, because the product team didn't do that. It went up to the EPMO and fed the funding buckets. The funding model of the organization required that TPM role to exist, essentially to fulfill that function. The second piece was that he coordinated across 14 different groups. Effectively managing all the dependencies, because in order for anything to get done by this product, they had to get 14 other things lined up, things like server access, networks, storage, all of it. So the TPM's role was largely to broker those dependencies just so the product owner could make a decision.

Dave [8:06]: Yeah. And often the decisions are already implicit in how those dependencies get resolved. So what you're highlighting is one of the key issues that really gets under our skin. Either you disempower the product owners because they're handed a decision that's already effectively been made, or you disempower the project managers who are basically just running around saying "I need this by Thursday," without any real coordination, trade-offs, or discussion happening.

Peter [8:32]: Yeah.

Dave [8:33]: And just as a corollary, I have definitely been in organizations where someone somewhere said "we don't need project managers" and that translated into no more project managers anywhere in the organization. That has never ended well. Project management has a function. It's a trade-off with product management, and they need to be playing as peers. The biggest headache I see is when that's out of balance. Project managers are the ones handling the big physical stuff, the things outside your digital delivery. Recently, for example, we worked with a grocery store chain. There was a lot of software work happening around point-of-sale devices and inventory management, but there was also a whole project management effort around training, rollout, hardware upgrades, all the things a product manager is never going to do.

Peter [10:07]: Right. It's all the other things that have to be coordinated around it. The only place where that might not apply is in a purely SaaS world where you're pushing changes into a service that's digitally consumed.

Dave [10:31]: Even there, though. If I'm at one of those huge purely SaaS services, I'm still going to exhibitions and conferences. There are proof of concepts to build and partners to find. There's a bunch of activity around it that suits project management.

Peter [10:53]: And anyone who has ever organized any kind of event will know exactly what you mean.

When Peer Relationships Break Down

Dave [10:57]: And it's a skill. A very valuable skill. Let's touch on that product manager and project manager peer relationship. What are you seeing? Where does that work, and where does it break down?

Peter [11:11]: Where it typically doesn't work is in the anti-patterns you were describing, where decision authority ends up in the wrong place. The purpose of the product owner role is to reduce decision latency. I can think of organizations right now where there simply aren't enough product owners who have been given the autonomy and authority to make decisions. That leaves the technical teams stranded. They need a decision now, no one will give it to them, and everything escalates up the stack. It becomes a mess. The other side of it is the funding piece. If an organization has gone halfway down the product model path but hasn't changed how it funds initiatives, hasn't moved to funding teams rather than projects, things don't quite fit.

Dave [12:28]: As you describe that, I'm thinking of a couple of scenarios I've worked in where the project manager is tracking everything line item by line item in the budget because they have to present it back up, while the product team is just trying to get their work done and the reporting keeps interrupting the flow of planning and everything else. I also want to highlight what you said about transparency in decision making. In strongly project-centric organizations, I've rarely seen them follow an SDLC to the letter in a really well-executed way. What we typically see is some level at which the SDLC functions pretty well, and then it cascades down into just get the stuff done. Project managers are amazing at getting the right people to the table at the right time to get their projects across the line. But their focus is on their projects. What that does to your project is less of a concern, because they've become very good at working around it. And that's subtly different from where the product owner sits in terms of decision-making discipline.

Peter [14:16]: That's a good point. And it connects to a corollary, which is making the project everything because you've got to hit on time and on budget. That can result in the people actually doing the delivery being pushed to exhaustion to make it happen, ending in very bad outcomes for them. And then the project manager gets celebrated and maybe even gets an award for delivering on time and on budget, even if a few metaphorical dead bodies were left along the way. I can think of a few examples.

Decision Frameworks And AI Limits

Dave [14:57]: Yeah. I've done my apprenticeship in project management, I like to say, and I have definitely been in scenarios where those metaphorical dead bodies were somewhere in the background. But it's part of the structure of the system. Touching on that, what I find is that in stronger project-centric organizations, the product side often struggles to hold onto decision-making authority because they keep getting tripped up by decisions made around them. One interesting response to that is having some mechanism where decisions are visible and respected across many different streams of work, not just within one particular domain.

Peter [15:51]: Some of that comes down to starting with an agreement about how decisions should be made. Actually having that conversation explicitly, rather than leaving it hidden in the background where nobody is really aligned. Having a decision-making framework, some way of resolving disputes and moving forward. When we think about these two different roles, there's also a question of what AI plays in both, because it does help both sides with their different tasks. I wonder if it helps resolve some of that friction, or helps create bridges where they might not have existed before.

Dave [16:41]: Currently I'm not seeing that, and it's a great question. I think there are two problems. One is if I'm a project manager and you're a product manager, and we're both individually using AI tools to do our own jobs better, then the AI tends to take my side or your side depending on who's doing the prompting. It's not naturally bridge-building. It's more like two of us getting advice from two different perspectives that each reinforce our own position. It's not thinking about us working toward something together.

Peter [17:39]: This might partly be me, but I have a habit of asking these tools to be critical, to tell me what's wrong with my thinking. Or in this case, something like "take the role of a product owner if I'm being the project manager, and how would you respond to this?" You can use these tools to think through decision prompts from a different angle. They can also help with data extraction and presenting the options in a way that makes it easier to think about different paths forward.

Dave [18:17]: I think you're quite an advanced user, and there's an element of remembering to ask for that critique. I'm also a bit cautious that the models I'm using are beginning to think the way I think, so I have to actively say, here's a totally different version of Dave, an impartial one, for you to consider. But I do think there are mechanisms there worth exploring. The more interesting one might be looking at the flow of work and where AI can help at that level, because when we take an individual view, this starts to feel like local optimization of different steps. If we look at the entire flow, we can actually see where the real holdups are, and that becomes a much more interesting systems-oriented conversation. But that's for next time.

Peter [19:23]: For sure.

Three Takeaways And Closing

Peter [19:23]: So, what three points should we leave our audience with today?

Dave [19:30]: The first one is that project managers, product managers, and product owners overlap. They have plenty of opportunity to bump into each other while getting their work done. The key learning is that it's not either-or, which has somewhat been the assumption in the past. We need both skill sets, and we'll use them in different places in the organization.

The second one is that a true peer-to-peer relationship between the two is the ideal. As soon as there's any kind of hierarchical gap, things start breaking down. When there's a genuine peer-to-peer dynamic, that can be a really difficult pairing to beat.

Peter [20:28]: And the third point is to think clearly about decision-making authority. Who is actually able to make this decision? Have you documented it? If you have a product owner whose role is to reduce decision latency and help guide the teams, you need to make sure they are actually empowered to make those decisions and supported in doing so.

And if your project managers exist primarily to support a funding model that doesn't match your operating model, you need to think about finishing off that implementation. Even then, you will still need project managers. But if a project manager's sole reason for existing is to fill in a spreadsheet once a month, that's a signal to look at completing your operating model.

So those would be my big takeaways. Thank you as always, Dave. I really appreciate the conversation, and I hope it was valuable for our listeners.

Dave [21:46]: Always a pleasure. Until next time.

Peter [21:48]: Until next time. You've been listening to Definitely Maybe Agile, the podcast where your hosts Peter Maddison and Dave Sharrock focus on the art and science of digital, agile, and DevOps at scale.