ISSUE #22 - FEBRUARY 20, 2024
Will product managers ever stop spending their time managing delivery?
The time and energy spent on managing delivery is one of the most common sources of frustration for product managers. In this issue, I'm sharing a few thoughts on the root causes of that matter and potential ways to help resolve it.
A couple of weeks ago, we had a chat with a few PM colleagues at the office regarding PM’s involvement in delivery. The subject of the discussion was the common struggle where a PM gets constantly involved in delivery way more than they’d like to. The (frustrating) consequence of that is that this often eats up so much of their time, that there’s no time left for other important tasks, like discovery.
In my experience, this problem is very common across companies, so I started to ask myself: Is there a way to solve this? So, I started trying to first figure out the reasons behind this and a few things that could help.
Are we on the same page regarding business objectives and ownership?
My first thought was that as product managers, we have a natural predisposition to - at least be concerned about delivery - which is sourced from our ownership. PMs are naturally considered to be the main owners of business objectives and, inevitably, business objectives rely on deliverables. This, by itself, creates a tendency to be involved in delivery, which frequently ends up with the PM managing it, as falling behind in delivery, usually means that you’re falling behind on your goals.
However - ruling out the case where a PM is a micromanager - delivery is one of the duties of the tech lead. Consequently, shouldn’t they also have the same ownership in business objectives as the product manager?
So, this was one of the first issues that I looked into. Does everyone on the team - and especially the product trio - share the same sense of ownership of business objectives? Hopefully yes, but being honest, I have seen (and I’m sure you have as well) cases where TLs only care about engineering excellence and how the tech stack looks like, design leads only caring about UX best practices and PMs about writing good stories and creating fancy roadmaps, instead of delivering actual business value.
Are we putting too much on people’s plates?
During the aforementioned discussion - a colleague brought up an argument that stuck with me - and truth is many PMs frequently ignore:
"Often, we ask from the tech lead to manage people, write code and contribute to deliverables, manage delivery, participate in shaping and other ceremonies, and occasionally address business queries as well. We often ignore that “they only have two hands” and can’t do it all. Inevitably, when delivery falls behind, PMs are going to step in to manage delivery. And then the domino effect starts, as they’ll also have too much on their plate and areas like discovery will fall behind."
The point I am trying to make here is that as PMs, we often focus on the multitude of tasks that we have on our plate due to the versatility of the role and forget that this might be happening with other people as well. The above example focuses on how you can overload a tech lead, but this can be the case for anyone on the product trio. For instance, a designer might be forced to spend way too much time on being involved in research or framing and so on.
Taking a step back, the main consideration here is: Are our roles well defined within a team? And if so, do we protect the boundaries of our roles, making sure that people actually have the capacity to do what they’re asked for? Does the company protect those teams by giving them the necessary resources, so that PMs won’t have to fill in gaps in delivery management, TLs won’t have to fill in gaps in product development and designers won’t have to fill in gaps in product discovery?
Is the team empowered? (not in the “fluffy” way)
With the term “empowered” here, I don’t want to go to the “fluffy” definition about “empowered product teams” which work on a pink cloud and do everything perfectly. I mean can the team make decisions while delivering without the PM signing off everything? Or are you the bottleneck?
Unfortunately, there are many cases where the PM themselves are the bottlenecks when it comes to delivery. And while you are not “actively” managing delivery, you affect it in a significant way. There are cases where nothing finds its way to delivery, unless the PM signs it off. That means that the delivery team cannot make decisions by themselves and as a PM you will have to always give the green light. There could be several reasons for that, to name a few:
- The team might not feel that they have the necessary context to make a decision. And this is a PM problem, because if that’s true, that means that the team does not understand well what they are doing and what we are trying to achieve. And this is a product manager’s problem to fix, by improving how they bring and communicate projects with the team.
- The team might simply not have the permission: Again, a PM’s problem to solve. If a PM is not allowing the team to make decisions on their own, that ultimately means that they don’t trust them.
The bottom line here is that the PM is not “the boss” of the developers or the designers and they need to give them the necessary trust and context so that they can make decisions by themselves.
Let’s jump off the pink cloud now
Having considered the above, I must be realistic. We don’t live in a world created by Marty Cagan. Business is business and there will always be lows. There will always be times when there will be pressure as you are falling behind from your goals, or a new time-sensitive opportunity presents itself and you will have to be more tactical. That would mean that short-term and delivery is a much higher priority and areas like discovery will matter less. In that case, you will naturally gravitate more towards delivery and it’s ok.
The thing here is how often will that happen? It’s not uncommon for companies to be in that state of emergency constantly and the focus on execution to be the only thing that matters for a long time. And this can become the reality of the company, in which they might forget that the strategic matters as well. Being able to think more long-term, discover new opportunities and find ways to nurture them can only be on the back-seat for a limited amount of time.
Do you agree with the above perspectives on why product managers are spending more time than they should on delivery? Have you witnessed any other reasons why this happens? If so, I’d be glad to listen to them. Hit reply and let’s talk.
Past Newsletters
ISSUE #21 - OCTOBER 25, 2023
From Individual Contributor to Senior Product Leader: The Evolution of the PM Role
The evolving role and responsibilities of product managers as they progress in their careers highlight differences in the areas of progress measurement..
ISSUE #20 - AUGUST 22, 2023
Takeaways after training 150+ AI models in 8 days
The story and the key learnings (not limited to product only) after training 155 AI models during my summer holidays.
ISSUE #19 - JULY 29, 2023
Backward Working Documents: What are they, and why should you use them
In this post, you can learn what are Backward Working Documents, how and when to create them, and what are the benefits of using them.
The Product Notebook by Manos Kyr.
Once every month, I’m sharing my thoughts on product, growth & entrepreneurship.
Copyright © Manos Kyriakakis