When PM Titles Change but the System Doesn’t

Why renaming roles doesn’t change product behavior

Over the last few years, I’ve seen a familiar pattern repeat across large enterprises and through many reorgs.

We change product titles to signal progress. A Business Analyst (BA) becomes a Product Manager (PM). A Product Owner (PO) becomes PM.

On paper, it looks like a step toward transformation. In practice, that’s often where it stops. Very little actually changes.

When this happens, people are not just unclear about expectations. They are placed into the role without the structure, authority, or support needed to succeed.

It’s worth saying why this keeps happening.

Changing titles is fast, visible, and feels like progress. It signals transformation without requiring hard trade-offs. Bigger changes like how decisions are actually made, changing incentives, slowing delivery to learn, and coaching people through ambiguity take time and political capital. Under pressure to show momentum, leaders gravitate toward the thing that’s easiest to do.

The problem is that signaling change isn’t the same as enabling it.

But what actually happens when we change the title without changing the system around it?

---

I was talking to a PM this week who reflected that the hardest part isn’t the title change itself.

It’s being expected to do a job they were never taught how to do.

This comes up a lot in enterprises when BA or PO titles are changed to PM.

We change the title.
We don’t reset expectations.
We don’t coach people on what the role actually means in this context.
We expect behavior to change overnight.

Then we act surprised when it doesn’t.

People are suddenly asked to think in outcomes, look at data, run experiments, and talk to users. But they don’t have a well-defined product strategy. They don’t have access to data. They don’t have access to users or the right tools. And they’re not coached on how to frame problems or make decisions differently.

No one who finds themselves in this new role wants to raise their hand and say, “I don’t actually know how to do this.” So they fall back to what feels safe and what’s still rewarded: tracking deliverables, writing stories, waiting for requirements from business.

Not because they’re incapable. Because that’s what the system still asks them to do.

Later, this same behavior is used as evidence that:
“This isn’t the PM role we want.”
“This doesn’t align with the Marty Cagan model.”

What often goes unsaid is that we never built the conditions that the model assumes: clarity on ownership and influence in decisions, access to strategic context, real problems to solve, users to validate with, room to learn, and leadership support when trade-offs get uncomfortable.

The role doesn’t fail. The system sets it up to.

I’ve seen this pattern repeat over and over.

We bring in great thinkers. We run workshops (I’ve run more than a few myself). People leave energized.

And then nothing changes.

Titles change.
Processes stay the same.
Incentives stay the same.
Decision-making stays top-down.

Despite calling people PMs, the organization becomes more delivery-focused, not less.

In many organizations, “PM” quietly becomes the role where ambiguity is dumped without authority to resolve it.

There’s another dynamic at play here that’s harder to name.

In many enterprises, decisions don’t flow through roles. They flow through influence. The loudest or most politically powerful stakeholder still shapes what gets worked on, how urgently, and with what constraints. Leaders often inherit those priorities and pass them down, sometimes without realizing they’ve undercut the very PM role they’re trying to establish.

PMs see this quickly. They learn where real power sits. They learn which decisions are already made before a problem ever reaches the team. And they adjust their behavior accordingly—out of self-preservation.

The only time I’ve seen behavior truly shift is when the system around the role changes:

• How work enters the team

• How planning happens

• How success is defined and reviewed

• Where PMs are expected to lead decisions vs. collaborate or influence, and

• When PMs are coached over time, in context, while doing the work

In a follow-up post, I’ll plan to share what actually changed in the few cases where this worked and what it took to sustain those changes over time.

Workshops alone don’t change behavior. Training without system change creates frustration. Judgment is built through practice, feedback, and support—not through title changes.

That said, this isn’t just a leadership responsibility.

When PMs find themselves in this situation, there’s also a responsibility to actively upskill through coaching, courses, reading, and learning how strong product work actually looks in practice.

And when systems don’t change, PMs can’t wait passively. They have to identify the gaps.
Name where clarity around decisions is missing. Surface where success is still measured on output instead of outcomes. Create clarity bottom-up when it doesn’t exist top-down.

This is as much about managing up as it is managing down.

That’s hard work. And it requires courage, especially in environments that still reward compliance over judgment.

If you’re going to change the title, you have to be willing to: coach the role, change how work is taken on, redefine success, support validation and learning, and protect people while they build new skills.

Otherwise, the rename is cosmetic.

And if your PMs are acting like delivery leads, the real question isn’t whether they’re capable.

It’s what your system is actually rewarding them for.

If you’re a leader contemplating this change, ask yourself what else needs to change in the system for the transformation to actually be effective. If you’re a PM whose title has changed, ask how you’re actively upskilling so your actions can meet the expectations being placed on you.