How to Work With Your Product Manager

Why the EM-PM relationship is different from most at work

The EM and PM are peers with complementary authority. The product manager owns what the team builds and why - they are accountable for product direction, customer outcomes, and stakeholder alignment. The engineering manager owns how the team builds and who does the work - they are accountable for technical quality, delivery predictability, and the wellbeing and development of the engineers. Neither has authority over the other. Both are accountable for the team's success.

This interdependence is what makes the relationship both powerful and fragile. A PM's commitments to stakeholders are only as credible as the EM's honest capacity signals. An EM's team can only move fast and sustainably if the PM provides consistent, well-sequenced priorities. When either side withholds information or starts working around the other, the team pays the price.

Building the partnership from the start

Whether you are new to a team or starting a new relationship with a PM, the first conversation should not be about the roadmap. It should be about how you are going to work together. Skipping this conversation is one of the most common mistakes. Teams fall into dysfunctional patterns because two intelligent people simply assumed they shared the same expectations.

• Have the working agreement conversationAsk directly: how do you prefer to communicate, how do you want to handle disagreements, what does good look like for each of us, and what are the things that most frustrate you in a working relationship? Share your own answers honestly. This conversation sets the tone for everything that follows and takes thirty minutes to do well.
• Share your constraints openlyTell your PM what your team can and cannot absorb. Be specific about capacity, current technical investments, and anything that is likely to slow you down. PMs who make commitments without this context are not reckless - they are working blind. Give them the information they need to make good calls.
• Get into their worldAttend the PM's stakeholder reviews occasionally, even if you are not required to. Read the product briefs and customer research they share. Understanding the business context for what you are building helps you make better technical decisions, raise better questions, and get your engineers invested in the outcomes rather than just the tickets.
• Establish regular one-to-onesA weekly 30-minute sync is not overhead - it is the investment that prevents a hundred misalignments. Use it to share what is coming up for each of you, flag anything that needs the other person's attention, and check in on the relationship itself. The agenda should be loose enough to follow what actually matters, not a rigid template you both stop reading.

Aligning on priorities

The most persistent tension in any EM-PM relationship is the balance between product features and technical investment. PMs have a roadmap under constant stakeholder pressure. EMs have a codebase that needs maintenance, a platform that needs investment, and engineers whose morale suffers when they are only ever building new features on top of systems they know are fragile.

Resolving this tension is not about winning arguments. It is about building a shared understanding of the trade-offs and making decisions together. That requires the EM to make technical debt and risk legible to the PM, and the PM to make business constraints and stakeholder pressure legible to the EM. Both sides need context they do not naturally have.

For more on communicating technical constraints to non-technical stakeholders, see the guide on how to make the business case for technical debt - the same framing principles apply directly to your PM conversations.

How to handle disagreements

You and your PM will disagree. You should disagree - it is a sign that both of you are bringing something real to the table. The question is whether disagreements get resolved in a way that produces better decisions, or whether they build into silent resentment and passive resistance. How you handle disagreement when it is small determines whether it escalates into something harder.

• Say it directly and earlyIf you disagree with a prioritisation decision, a scope change, or a commitment made to stakeholders, say so directly and promptly. Do not let it sit. The longer you wait, the more entrenched both positions become. A direct early conversation almost always goes better than a delayed one, and the relationship stays cleaner for it.
• Separate the what from the howMost EM-PM disagreements are about where each person's authority ends. If a PM is specifying how something should be built, that is worth pushing back on - the how is yours. If you are resisting what to build for technical reasons, frame it as a risk, not a veto: "We can build it this way, but here is what it costs us technically - is that trade-off worth it given what you know about the business case?"
• Disagree and commitSometimes the PM will make a decision you disagree with and it is their call to make. Say that you disagree and explain why. Then commit to executing it well. Do not undermine the decision with your team after the conversation. The ability to disagree and commit - genuinely, not reluctantly - is one of the most important professional skills in a peer relationship.
• Know when to escalateIf a disagreement involves something that puts your engineers at risk, crosses an ethical line, or is genuinely unresolvable between the two of you, involve your shared manager. Escalating is not failure - it is appropriate when the stakes are high enough. The mistake is escalating every disagreement, or never escalating when you should.

Communication rhythms that work

Good EM-PM communication is not about volume. It is about making sure the right information reaches the right person at the right time, without requiring either side to chase. A few simple rhythms do more for alignment than a dozen channels and a calendar full of status meetings.

The shared decision log is underused. When two people make a decision in conversation, both leave with a slightly different version of it in their head. Writing down the decision and the reasoning - even in a simple shared document - protects both sides and prevents the same conversation happening again two weeks later. It also makes it far easier to explain to your engineers why things are the way they are.

Protect the weekly one-to-one. Cancel it when the world is on fire and you will spend the next fortnight rebuilding the alignment you lost. The EM-PM sync is often the first meeting to get cut in a busy week - which is exactly when you most need it. For a guide on writing useful meeting notes from your syncs, so nothing falls through the gaps, see our full guide.