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 to go 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, but 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 that 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 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!

---

Other stuff

It’s been a while since my last newsletter, primarily because it’s been a very busy month. Nevertheless, here are some of my podcast episodes that are definitely worth a listen, as well as some other interesting stuff that I’ve seen around the web:

• First up, I spoke with Jennifer Yang-Wong. Jen is the VP of Product and Talent at Contrary, a Silicon Valley VC fund. I had some questions for Jen, including “What the heck is a VP of Product and Talent?” and “Why does a VC firm need a VP of Product?”. We also went deep on the perils of being the first “first product manager” and the difficulties founders can have moving away from founder-led product management. Check the episode out here.

• I also spoke with Duena Blomstrom. Duena is a renowned fintech influencer turned organisational change agent, who has written multiple books on the people side of tech and has founded People Not Tech to provide a platform to enable culture change from within. We spoke about all of that and more! Check the episode out here.

• I most recently spoke with Namrata Sarmah. Nam’s a good friend, powerhouse CPO at INTO University Partnerships, as well as the founder of Women in Product UK. We talked all about her journey, the principles behind Women in Product UK, and why good product operators can find it hard to get into the C-Suite. Check the episode out here.

• Aside from that, I was also interviewed by the Collato team about “Shaping a Product-Centric Organisation” for their blog. We went deep into some of the challenges in moving to a product mindset, as well as some of the concrete steps that product leaders can take to get started. Check it out, and let me know if you disagree with any of it!

• There’s been some back and forth online about the recent McKinsey report “Yes, you can measure software developer productivity”, where they take the SAFe route and repackage some existing concepts and try to sell them to large organisations.

  Gergely Orosz
  and
  Kent Beck
  have collaborated on a detailed rebuttal to some of the core problems with the McKinsey approach. They’ve done a far better job than I ever will, but I think it’s an important discussion. My take: Measuring developer (and product manager!) productivity is tricky, but I don’t think it’s automatically a bad smell. On the other hand, bad metrics and bad KPIs make for bad behaviour. Proceed with caution!

• Continuing the theme of what product management, is or isn’t, here’s an article from my friend Saeed Khan, entitled “Product Management: It’s a System for Business Success, not Product Features”.

• Something else that I’ve been noodling on recently is the classic Brooks’ Law, which states “Adding Manpower to a Late Project Makes It Later”. This sounds counterintuitive, but it’s actually pretty obvious if you think about the training, onboarding and additional communication overhead. Here’s an article about Brooks’ Law, and you can also pick the classic book “The Mythical Man Month” up on Amazon (not an affiliate link).

  

• Another thing that I’ve been thinking about recently is a bit more niche, but interesting.

  I asked a question on Twitter the other day about whether using national flags as the selection options for languages in an app is good or bad. There are some spirited arguments in both directions in the replies. My personal opinion is that it is culturally insensitive, but I can understand that people outside of those cultures might not see it as a problem at all. Here are a couple of articles that back up my position. I’m sure you can find your own to refute it!

• This just in: I came across an interesting report from ChartMogul about SaaS growth metrics, and some of the key drivers of the journey to $1M ARR, $10M ARR and beyond. Check out the report here.

• Also just in: I was interested in the ProductPlan’s “The 2023 State of Product Management Report” (free registration required). Includes the sobering stat that “52% of participants say their strategy is more reactive than proactive'“.

Thanks for reading! Please drop me a line if you have any comments or would like me to cover anything in future newsletters. If you find this remotely useful, I’d love you to share it with your friends.

For full disclosure, none of the links in this newsletter are affiliate links (unless explicitly specified). If you want to support my work, you can throw me some spare change.