One of the long-standing cliches about product leadership — and all leadership, really — is that PMs must exercise “influence without authority”. That is: we are expected to guide teams toward successful outcomes, but are almost never empowered to make those outcomes happen using the tools and kinds of authority invested in managers, e.g. “do this or you’re fired” or “do this and you’ll get promoted.”
And that’s true to an extent. A product manager almost never has the operational authority to enforce decisions via those kind of carrot-and-stick methods, especially if the people they need to influence report to different managers. On some teams the person wearing the PM hat may be a product design lead, or a business analyst, and it would be silly for the design lead to be able to fire an engineer who doesn’t report to them.
But what I find flawed about this statement is that effective PMs should have authority, it’s just not authority to hire and fire. Rather, strong product-led organizations invest decision-making authority into PMs (or PM-like roles like Design), which is backed up and reinforced by the bosses who do have that other kind of authority.
For me, product authority on a team boils down to this: when someone is looking to start work on something, do they wait for someone else’s opinion, and if so, whose?
The strongest kind of PM role — not to say the best, but the one where PMs have the most authority — is one where folks on the team wait to start work on a proposed project or task until it’s been reviewed and approved by the PM.
Of course, the other extreme is that no one waits for PMs before they dive into something. On very engineer-led teams, individual engineers or tech leads reserve the authority to spin up projects, maybe in consultation with their engineering leadership or maybe on their own initiative, and other functions like UX or UXR have to ride that current.
It is totally possible for a company or team to have gone to the trouble of hiring product managers — maybe even a lot of product managers — but end up with them having no real authority.
I’ve never encountered a team that hired PMs intending for them to have no authority; on the contrary, these teams will often hire PMs because they feel like they lack “strategy” (whatever that is for them) and want to bring in a strategy specialist to get the team onto more solid footing. But in those cases success or failure totally depends on:
- Whether or not the individual(s) who currently wear the PM-like hat acknowledge that they are wearing it. This is often the most senior manager, or a lead from the closest PM-like function like UX or program management
- Whether or not those individuals are willing to share or cede that authority to incoming PMs
- Whether or not they’re willing to declare publicly — from day one and as often as needed — that PMs are wearing the PM hat and have that authority
- Whether or not that message is heard and absorbed by the team
Years ago an engineering colleague said what he looked for when a new product leader joined a team and rolled out a strategy is whether his team’s UX director (who, in his mind, had the decision-making authority I’m talking about) “put his arm around the PM at the all-hands and said, ‘this is the guy’.”
Absent that kind of clear, visible endorsement and torch-passing, his team would still ultimately look to the UX director as their source of decision-making truth.
In fairness, this dynamic can be OK if the UX director and PM are in regular contact, aligned on things, and speaking with one voice. But it can be a recipe for heartbreak if a PM has been told they’re the decider, only to find people regularly routing around them and asking the UX director’s opinion on everything. And if the UX director doesn’t mind being asked to weigh in, this is unlikely to create enough friction to prompt a clarification.
All of which begs the question: why even hire a PM? Honestly, I think some teams hire us because they think we have some kind of secret sauce or magic bullet. A pattern I’ve seen a couple of times is an engineering- or design-led team that’s been following the same playbook for a few years, feels like it’s not having the same impact that it used to, and attributing that to lacking “strategy.”
In those cases, though, sometimes the truth is that the old playbook is still the right one — it’s just that they’ve achieved what I call ‘cruising altitude’, where they can basically keep doing what they’re doing and produce an expected degree of impact or business value indefinitely, and there’s not an alternative strategy that’s likely to improve on that without introducing a lot of risk or a major culture or process shock.
In my first job at Google, almost 2 years ago, I was hired to bring some “product thinking” and “strategy” to the process of delivering computer/phone hardware, software, and services to Googlers. None of the teams I worked with were waiting on me to make any major decisions — in fact, they were SRE or operations teams who had been doing things a certain way for over a decade, and had no experience working with PMs (and only a little bit of experience working with UX or research). I wasn’t paired with an eng or UX lead. It was just me, parachuted into a problem space to find this elusive “strategy.”
What I found was that, actually, everything was working just fine. These SRE teams were well managed by strong tech leads and program managers who had clear roadmaps and lots of opportunity for community engagement. Most of the areas where folks on these teams felt they lacked “strategy” were not gaps so much as potential optimizations, where the cost of change was likely way higher than the ROI.
And because I didn’t have any functional authority — because no one was including me in planning, or waiting on me as a decision-maker — I felt (and, honestly, was) less like a conventional PM and more like a management consultant, except unlike a McKinseyan my eventual report suggested changing almost nothing.
This is also to say: PMs lacking this sort of authority — being a person who the team looks to for direction and decision-making — is not necessarily a sign that people are doing it wrong, though it may be a sign that PMs weren’t needed, or were hired too early or too late. Teams can operate in all kinds of ways, and PMs can fill many kinds of roles.
My experience from Google’s IT org wasn’t consistent with the “PM as product CEO” model, but in hindsight it did align with a model where PMs might gather the same kinds of research data as one would on a consumer-facing team — it just was less about supporting the teams directly, and more about supplying senior leaders and executives with insights, so they could exercise the product authority. This wasn’t exactly intentional or made explicit, but it worked out.
But if the intent when hiring a PM is for them to, sooner or later, own the decision-making authority for a team or org, that authority won’t be invested in the new PM unless/until whoever possesses that authority clearly passes it on. Not doing that can create a lot of pain, and also prolong whatever situation led the powers that be to hire a PM to begin with.