Who owns what between an engineering manager and a product manager?

The common answer fits in one sentence:

The PM owns what and why. The EM owns how, who and how well. Together they own outcomes.

It's a good sentence. Nobody argues with it, mostly because it doesn't decide anything. Who runs the project? Who tells the customer when it ships? Who decides that this iteration goes to tech debt instead of the feature sales has been asking for? The sentence has nothing to say about any of these, and that's where most of the friction between an EM and a PM lives.

I'm an engineering manager, and my closest partner on this is a product manager. Together we tried to fill in the gaps.

The table that didn't work

My first attempt was a table. Rows for contexts (the team, the product, the organization, customers, strategy) and columns for EM and PM. Fill in the cells and the ambiguity is gone.

Almost every cell fell apart as soon as I questioned it. Should an EM have opinions about the roadmap? Obviously. Should the PM I work with have opinions about how we measure quality? Also obviously. SLOs, MVP scope, what "done" means and which bugs come first all ended up as "both".

For a while that felt like the exercise failing. Then I looked at which cells refused to settle, and they were the same places where she and I cover for each other, and where most of our disagreements happen. Planning, customer calls, deciding what to cut. The overlap wasn't a gap in the table. It was the part that makes the partnership work.

Two kinds of borders

The fix wasn't walls. It was two kinds of borders.

A soft border means one side leads and is accountable, but the other is expected to contribute, challenge and shape it. When an EM pushes back on the roadmap, that's the system working, not overstepping. Soft-border decisions are made together.

A hard border means one side makes the final call. That's not "I decided, now I'm informing you". The other side can still raise concerns, and those concerns have to actually be heard. What makes it hard is that we agree one of us is better placed to own the decision, because accountability, expertise or confidentiality require a single owner.

With that split, the hard borders turned out to be a short list:

• EM: hiring, performance, compensation input and career growth. Who works on what. The engineering quality bar. Architecture and technical design, security, privacy and compliance, performance and reliability. Estimates and technical readiness to release. Cross-team technical dependencies. Incident response.
• PM: product readiness and launch timing. External product messaging.

Everything else is soft: vision, problem definition, scope, success metrics, the delivery process, team health, customer escalations, quarterly planning, and deciding what we won't do.

Two things surprised me once it was written down. Most of the hard borders sit on the EM side, and none of them are about strategy.

It looked lopsided until I thought about what the PM's core areas actually are. Vision, roadmap, scope and metrics are soft by nature, because they only work when engineering shapes them. A roadmap engineering didn't help shape is a wish list.

That's mostly a lesson for EMs, and I'm including myself. A list of things you own outright makes it tempting to stay inside it: "Architecture is mine, the roadmap is theirs." But the soft areas are where most of the outcome gets decided, and your hard borders don't excuse you from them.

When nobody talks about the borders

Soft borders only work if you talk about them. When nobody does, it shows, and the best engineers notice first:

• Engineers get one answer from the PM and another from the EM, and stop trusting either.
• Work gets started, paused and restarted.
• Reliability keeps slipping until it becomes an incident.
• Features ship and sit there, with no announcement and nobody tracking adoption.
• Disagreements turn into escalations, and leadership ends up refereeing.

The causes are usually structural, not personal:

• Different managers. EMs report through engineering, PMs through product, and incentives drift apart. Escalating starts to look easier than working it out.
• No project owner. Sometimes both sides drive the same project, sometimes neither does.
• Different time horizons. PMs think in quarters and markets. EMs juggle this week's incident and next year's architecture.
• Features vs. everything else. Tech debt and reliability compete with features every iteration, and without talking it through, the loudest request wins.
• Moving lines. With AI, PMs build their own prototypes and engineers are expected to be more product-minded, so the old split no longer matches who does what.

The fastest way to break trust is a commitment made on the other's behalf. Picture a PM telling a big customer a feature will ship next month, and the EM finding out a week later, after the iteration is already planned. Now it's break the plan or break the promise, and either way that one sentence does more damage than a month of disagreements in private.

The quieter version is avoiding the disagreement altogether. It feels like being a good partner in the moment, and it turns into resentment later.

A test I like to run on myself: can I explain my PM's top concerns right now, and could they explain mine? If either of us would answer with "they just don't get it", it's broken in both directions.

Habits that keep them soft

Most of what keeps soft borders working comes down to talking more than feels necessary.

A few rituals give the talking a home:

• A weekly 1:1 that doesn't get skipped. Priorities, risks, people, customers, and one question every time: "Anything I'm worried about that you don't know yet?"
• Iteration planning prepared together, so the team sees a plan rather than a negotiation.
• A quarterly step back on the roadmap, tech debt and the partnership itself.
• Coffee with no agenda. The trust you build there is what makes the hard conversations easier.

Some things are worth writing down, so you don't renegotiate them every month:

• Who acts as project manager, and what that includes.
• How customer commitments get made. Never by one of you alone.
• The tie-breaker for soft borders. Product calls default to the PM, technical calls to the EM, and joint calls go up together if you can't agree.

And a few behaviors that are simple to say and harder to do:

• Disagree in private, commit in public.
• No surprises. If I know about an escalation, a customer promise or a people issue, she hears it from me first, and the other way around.
• Ask "what are you optimizing for?" before arguing. Most disagreements turn out to be about different goals, not one side being wrong.

Covering for each other depends on shared context. The most practical tool I know for that is a shared EM–PM canvas: a Slack canvas, or any doc you both actually open, holding brain dumps, 1:1 notes, TODOs, priorities and plans for the next iteration. It doubles as the 1:1 agenda, and when one of you is on a customer visit or stuck in an incident, the other can pick up where they left off.

Back to the sentence

The one-liner still holds. PM owns what and why, EM owns how, who and how well. The table couldn't capture the last part, together they own outcomes, because that part isn't a division of work. It's the overlap, and it only holds up with soft borders and a lot of talking.

We don't get it right every time. We still disagree, and every now and then one of us steps on the other's toes. When that happens, we say it out loud, explain what each of us is prioritizing and why, and adjust. That's what keeps the overlap working in our favor.

There's plenty I haven't figured out. Should project management default to the PM or the EM? How should disagreements escalate when the two sides have different managers? How far will AI blur the roles? I suspect the answers differ from team to team.

If you're an EM or a PM, here's a small first step: sit down with your counterpart this week and write down who runs the project, who makes customer commitments, and how you break a tie. It takes half an hour, and you'll probably find at least one thing you each assumed differently.