Product Managers Aren’t Responsible for the Delivery of their Products

There has been a lot of talk recently about the role of product managers in companies, and the value that they bring to the table. Part of this is a continuation of an age-old debate, and part of it has been brought into focus by moves such as Airbnb and Stripe getting rid of product managers (which, of course, neither of them did). Now, I’m no fan of stories of Airbnb’s designers whooping with delight when they thought all the PMs were getting fired, but, on the other hand, we should always be willing to ask ourselves… what are we for?

In this post, I’m going to talk about what we’re not for, because it’s something that I’ve seen often on my travels, and I think it’s at the root of much of the bad feeling between product managers and their teammates. To cut a long story short, product managers are not responsible for the delivery of the products they manage.

What? Let me explain…

About that “manager” word

Product managers have a labelling problem. That pesky manager word has connotations for many people, especially in organisations that don’t have a history of strong product management practices. This can manifest itself in one of two ways (or both):

• A product manager who believes that they are the “leader” of their pod, or squad, or whatever they call their team. They’ll do things like refer to “my developers” and start allocating work items to individuals.
• Developers and designers treat the product manager as their boss, feeling that they have to run everything past the product manager. Things like standups become status updates as people start trying to justify how busy they are to the boss.

But, no one ever said that product managers are the boss. That pesky “manager” word! On the other hand, “product owner” has been devalued by so many organisations that it doesn’t feel right either. Maybe we need a different word, but until then, we need to accept the fact that product managers manage the products, not the teams that make the products, and certainly not every detail of the delivery of those products.

So, who is responsible for delivery?

If product managers aren’t responsible for the delivery of their products, then who is? I should start by clarifying what I mean by “delivery”. By delivery, I mean the tasks that are handled by developers, designers and any other cross-functional partners. The code that’s being written. The designs that are being designed. The internal organisation needed to sequence the work and minimise dependency problems. Quality Assurance. Testing. Technical documentation.

These are all tasks that people in other teams know how to do much better than the product manager does. So, let’s let them do them without getting in the way! Our job is to give enough context about why they’re important and when we need them for (either vaguely, or a “high-integrity commitment” from time to time). Once we’ve given that, we’re there to answer questions and give feedback, nothing more.

In situations where the product manager is seen as the leader of the team, they have to drive everything. If the product manager doesn’t drive these things, they start to slide. You might see some of the following behaviours:

• No work is getting done without being authorised by the PM, who becomes a massive bottleneck.
• The PM spends 75% of their time wrangling the team, which means they sacrifice talking to users or aligning with commercial stakeholders and leadership.
• The PM spends more time arguing about whether tickets are detailed enough than talking about the outcomes they’re driving for.
• The PM starts micro-allocating work items to individual developers.
• The PM is also doing some support work and a bit of QA, because everything keeps getting escalated to them.
• Developers are constantly complaining about standups being status updates, and retros just develop into “us and them” complaining sessions.
• No one on the team seems to know why they’re working on anything, apart from the PM, who is constantly frustrated that no one else seems to know why they’re working on anything.

And, as a bonus:

• The PM feels unable or worried about going on holiday because who’s going to look after the team?
• The PM simultaneously starts thinking they’re not contributing if they’re not constantly moving people and tasks around like chess pieces.

The product manager becomes the de facto delivery manager for the team, spending more time micromanaging their teammates than working on actual product management tasks. They’re probably playing the role of quasi-Scrum Master (it seems to me that lots of companies aren’t even bothering with this as a role anymore).

It doesn’t have to be this way!

Now, let’s point out that, in some companies, this is exactly how they want it. I have spoken to many people who either run companies or work for companies where they want product managers to do all of these things and nothing more. They see the role of the product manager as the “techie who can talk to people” rather than a strategic business partner.

But, product development is a team sport. We often see talk of the “product trio”; that’s to say a product manager, a product designer and a developer (presumably the development lead for that squad). The most important thing to call out here is that it’s not that product managers aren’t responsible for product delivery, but that it’s a shared responsibility with everybody else in the team.

This could be an uncomfortable shift in mentality for some teams, but it’s worth making that shift. In the worst-performing teams I’ve seen, the product manager is the gatekeeper for everything (whilst, ironically, often being gatekept from the rest of “the business’). In the best-performing teams I’ve seen, everyone in the team works towards a common goal, and they all take responsibility for achieving it together.

Some things you can try to start the shift

Again, this could be an uncomfortable shift, but it’s worth trying. Here are some concrete actions you can try in order to build that shared mindset.

1. Get teammates talking to each other, not you

I’m sure people are talking to each other, but make sure they’re talking to each other regularly about the work that’s getting done. If you’ve set a goal and everyone’s clear on what the goal is and how to get there, leave them to it. They can always come to you if they need help, but don’t sit there having debates about whether it’s a front-end ticket or a back-end ticket, or when QA should check this bit or that bit. Let them talk to each other and work it out themselves. Otherwise, you’re probably just getting in the way.

2. Rotate Scrum Master duties

Yes, yes, not everyone uses Scrum, but a lot of people do (or some version of it). In organisations without Scrum masters, the responsibility for keeping the Sprints going, running the standups and retros and all of that good stuff falls by default onto the product manager. Of course, most people forget that the Scrum Guide says that the “product owner” is an optional attendee. In any case, whether you use Scrum or some other approach that has regular meetings, rotate responsibility for these meetings throughout the team.

3. Get the team demo-ing together

I’m a big fan of Show and Tell-type meetings, where product teams go and show everyone in the organisation what they’ve been up to recently. No, this isn’t a Sprint Review. This is a chance to get people in front of the organisation and show what progress has been made, what has been learned, and what’s happening with the roadmap these days. You can even get non-product development colleagues to come and give presentations. In any case, you want the entire team involved in this, not just the product manager as the only spokesperson. Get the people who did the work to show it (and take the praise!).

4. Get the whole team to write tickets

I’ve seen organisations where every single work item, including deeply technical requests that originated from within the development team, had to go to the product manager to get written up (generally in a canned template with lots of sections). Now, prioritisation of work is definitely up to the product manager (although, the rest of the team should feel empowered to question prioritisation decisions), but they don’t have to write all the tickets (or stickies, or stories, or whatever you want to call them).

5. Get the whole team aligned upfront, and keep them there

I remember once speaking to a developer who said to me, in a somewhat defeated-sounding voice, “I don’t even know why we’re building this anymore”. That hurt like a punch in the gut but, at the same time, I knew that it was 100% my fault. I had let the team lose sight of the goal, and everyone just felt like they were churning code out for the sake of it. This was not good, and it was holding the team back.

These days, I like to get teams super-aligned upfront, through participatory design and regular alignment. That sounds like word soup, but what I mean is that we need to get away from product managers locking themselves in a tower and eventually coming back with a perfectly crafted flower of a specification that teams have to just execute. Get your thoughts up early! Share them! Invite comments! I’d rather be having these discussions at the beginning of an initiative than at the end. It’s hard to unset concrete.

Also, make sure any retros you might run, or even the Show and Tells, aren’t just lists of features or context-less gripes. It’s a cliché, but you need to continuously remind people why they’re there. Make sure people don’t have a chance to forget.

6. Expose the teams to internal and external stakeholders

We’ve all heard of the stereotypical developer who sits in the corner wearing noise-cancelling headphones, not-so-silently judging everyone who tries to talk to them, and seeing everything as just a technical challenge to be solved. These people do exist. To be honest, I was a lot like that when I started out. And, it’s fair to say that there are some developers out there who have zero interest in talking to other developers on their team, let alone non-developers outside the team.

However, it is important to get some of the developers talking to customers, coming along to user interviews, and also involved in internal meetings with marketing, sales teams or company leadership. They don’t have to come to everything, but the best way to develop empathy for users, as well as maintain contextual understanding of the organisation, is to make sure they’re involved, rather than a service department to throw tickets at.

I mention developers because they’re the clearest example, in organisation after organisation, of teammates who just feel left out of the loop. But, bring everyone else along for the ride too.

But… why? And what will the Product Managers do instead?

Excellent question, we should always ask “Why?”

If we accept that product management isn’t all about writing tickets and moving them around a board, and celebrating the technical delivery of code, we can start to get somewhere. By putting more focus on the team to drive the delivery, rather than just the product manager, everyone maintains a greater sense of ownership and agency. It becomes a true collaboration. There’s less communication overhead because there are fewer bottlenecks and people can just talk to the people they need to talk to. The team organises around the work that needs to be done.

But, where is the product manager in this? They are involved and interested, but not on the critical path. Every single decision doesn’t have to go through them. This means they can spend more time speaking to customers, speaking to stakeholders, wrangling with leadership, looking into product usage data, looking at market trends and making sure that everything the company does makes sense. Above all else, being true partners to the rest of the business.

This might sound fluffy (hey, they’re not just sitting there typing!), but this is some of the highest-leverage work a product manager can do. They need space to do it. If a product manager can’t go on holiday for a week without everything falling apart, there’s something very wrong with the organisation. Let’s fix that!

Originally published at https://oneknightinproduct.substack.com.