How to Work Effectively With Your PM
A Three-Step Working Model for New Engineering Managers and Their Product Managers
You’ve been promoted. Your relationship with product management just changed — and nobody told you.
For years, your PM was the person who wrote tickets. They decided what, you figured out how. Then you crossed over — became an EM — and suddenly the PM isn’t handing you tickets anymore. They’re sitting across the table expecting you to co-own the outcome.
Nobody warned you about this shift, and your PM is wondering why the new engineering leader keeps waiting for instructions instead of showing up with opinions.
Here’s the playbook for making this relationship actually work.
The Shift Nobody Explains
As an IC, your PM relationship was simple: they decided what to build, you built it. Maybe you grumbled about it over lunch, but ultimately you could just put your headphones on and code.
That’s gone now. Your PM expects you to have opinions about the roadmap, push back on bad bets, and bring the engineering perspective to the table unprompted. And right now? You’re probably still nodding along in meetings and then venting to your tech lead about how the priorities make no sense.
How I learned this the hard way
I’ve been on both sides of this dysfunction. When I first became an EM, I transitioned in October — right before the annual planning cycle kicked off in November. My PM did the whole exercise: put the spreadsheet together, lined up priorities, presented the roadmap. And I was very much not in the driver’s seat. I wasn’t even in the passenger seat. I was in the goddamn trunk of the car.
I asked questions — “Why is this valuable?” “What’s the expected impact?” — but I didn’t pitch in. I didn’t bring my own perspective. The insight I was missing: I owned the team, which meant I owned what the team delivers, which meant the roadmap was my accountability (too.) It was supposed to be a partnership, and I was treating it like a briefing.
The wake-up call came from my own team. I brought the roadmap to them, and someone asked, “What’s the bandwidth allocation for technical improvements? We’ve got debt, performance work, new patterns we could adopt — where does that fit?” I didn’t have an answer.
So I went back to my PM: “Hey, I think we need to add some technical work.” He said, “Great, what do you want to add?” I had no idea. I went back to my team. Then back to the PM. I was a ping-pong ball bouncing between the two of them, trying to put the footprint of an engineering leader on the roadmap without knowing what that footprint should look like.
It was frustrating for everyone — especially my PM, who just wanted me to show up with a point of view.
What I learned to do from there: build a technical roadmap on the side, maintained over time with my tech lead. We’d nurture ideas, scope them when planning came around, and explain the product value behind each technical investment. Once you can articulate why a technical improvement matters for users and system stability, it’s very hard for a PM to push back. But that muscle took time to build — and it only started building after that humbling first planning cycle.
The Co-Pilot Model
I call this The Co-Pilot Model because that’s what your PM relationship should be: two people in the cockpit, both responsible for landing the plane, but with different instruments in front of them.
Your PM is watching the market, users, and business metrics. You’re watching architecture, team capacity, and technical debt. Neither view is complete alone — I’ve seen the crash, and it looks like a team shipping features nobody uses while the PM panics because engineering “isn’t moving fast enough.”
Three principles:
Shared context, separate expertise. You each bring a unique lens, but you both need to understand why the other’s decisions matter.
Complementary challenge. Your PM pushes for speed and scope; you push for quality and sustainability. Neither of you should “win” — the user should win.
Joint accountability. When a feature flops, you don’t get to say “well, the PM wrote the spec.” You own outcomes together.
The three conversations below are how you start building this.
The Three Conversations That Matter
The difference between a functional and dysfunctional PM relationship comes down to three recurring conversations. Most teams have none of them.
Conversation 1: The Why Sync
Frequency: Every 2-4 weeks, 30 minutes
Purpose: Align on the why behind the work, not the what. This is the conversation most teams skip entirely. You talk about what and when, but never why this thing matters more than the other twelve things you could be doing.
In a Why Sync, you ask your PM:
“What’s changed in the market or with our users since we last talked?”
“Which bet on the roadmap are you most uncertain about?”
“If we could only ship one thing this quarter, what would it be and why?”
And your PM should be asking you:
“What technical risk are you most worried about right now?”
“Is there anything on the roadmap that’s significantly harder than I think it is?”
“What technical investment would give us the most product value?”
The point is to make sure you’re both operating from the same understanding of reality, instead of renegotiating the roadmap every two weeks. When context is shared, a hundred small daily decisions get easier.
What happens without a Why Sync
I learned this the expensive way. Early in my EM tenure, one of my engineers and I got fired up about simplifying the integration patterns for an API our team owned. We brainstormed the design, did the engineering spec, ran through product design — weeks of preparation. We had high conviction this was the right thing to build. Our PM was theoretically aligned too, but stretched thin on other priorities, so we ran ahead.
Then we took it to the product review forum. One of the senior product leads looked at our plan and asked a question that stopped us cold: “You’re optimizing this integration flow — which is great — but you have double-digit users on this API. Why are you spending time optimizing instead of recruiting users to actually build on it?”
They were right. We’d been solving an engineering problem without the product context. The priority wasn’t a better integration experience — it was adoption. I’d failed to engage my PM deeply enough, and they hadn’t had the bandwidth to catch it. Engineering ran ahead of product, and when product caught up, they were baffled.
We had to put the project on pause. My engineer was disappointed — understandably. We pivoted to growth experiments to drive adoption instead.
Two years later, we actually did build the optimized integration experience, and it worked beautifully. The difference: thousands of users benefiting from it instead of dozens. A month of wasted preparation taught me that every project kickoff needs real alignment between me and my PM — not just theoretical agreement, but both of us actively confirming *this is the right thing to build right now*.
Making it work
As a new engineering leader, you probably don’t have a strong intuition for product strategy yet. That’s fine — nobody expects you to. But you do need to understand the strategic context well enough to make good tradeoff decisions without escalating every call to your PM. The Why Sync builds that muscle.
Your team will come to you with prioritization questions you can’t answer without product context — “Should I fix this bug or finish the feature?” is a product question disguised as an engineering one. Without the Why Sync, you’ll either escalate every call to your PM (eroding their confidence in you) or guess wrong and own the fallout.
Here’s the Slack message I send: ”Hey [name] — I want to make sure I have enough product context to make good tradeoff calls without pinging you on every decision. Could we grab 30 minutes every couple of weeks to sync on the ‘why’ behind the roadmap?”
Conversation 2: The Tradeoff Table
Frequency: When scoping any meaningful piece of work
Purpose: Make scope/quality/timeline tradeoffs explicit and shared
Here’s how most scoping conversations go: PM writes a spec. Engineering says eight weeks. PM says four. Everyone argues, escalates, and ships something mediocre.
The Tradeoff Table is a reframe. Instead of arguing about whether something is “possible,” you lay out options:
Now you’re not fighting about estimates — you’re choosing between options together. Either way, the decision is transparent.
The key move: Never show up with a single estimate. Always bring options. This is how you stop being an order-taker.
The sentence that reframes the conversation: ”I want to make sure we’re choosing the same tradeoff on purpose, not landing on one by accident. Here are three ways we could scope this — what feels right given what you’re hearing from users?”
Conversation 3: The Retro Loop
Frequency: After every significant ship (not a process ceremony — a real conversation)
Purpose: Learn together from what actually happened
Not your team’s sprint retrospective — a private conversation between you and your PM about what you shipped and what you both learned. Questions to cover:
“Did users actually use this the way we expected?”
“What surprised us — technically or from a product perspective?”
“Where did our assumptions break down?”
“What would we do differently if we were starting over?”
Over time, these conversations build shared pattern recognition — a joint sense for “what works here” that’s worth more than any process. They also create psychological safety: you’re both admitting what you got wrong, which makes it easier to challenge each other next time.
Here’s how I propose it: ”Hey [name] — now that [feature] has been live for a couple of weeks, I’d love to grab 20 minutes to compare notes. Did it land the way we expected? What surprised us?”
When Your PM Is the Problem
Everything above assumes a willing PM. But sometimes the relationship still isn’t working. Before you escalate, answer one honest question: is your PM actually blocking progress, or are you not stepping up?
The mirror test
Before pointing fingers, check yourself:
Have you actually tried the conversations above — or just thought about trying them?
Are you bringing options and opinions to the table, or still waiting for instructions?
Have you told your PM directly what you need from them, in specific terms?
Does your PM know you’re frustrated — because you’ve told them directly?
If you can honestly answer yes to all four, the problem might genuinely be on the other side. If not, start there first.
Giving hard feedback to your PM
When your PM is underperforming or checked out, you owe them directness before anything else.
The script: ”Hey [name], I want to talk about how we’re working together. I’ve noticed [specific behavior], and the impact on the team is [specific consequence]. I want us to figure this out together, because the current pattern isn’t sustainable.”
Three rules:
Be specific, not general. “You’re not engaged enough” is useless. “The last three specs arrived the day before sprint planning” is actionable.
Name the impact, not the intent. You don’t know why they’re checked out. You do know the team is making decisions without product context.
Do it in private, and do it early. The longer you wait, the more likely it leaks sideways.
When to escalate
If direct feedback hasn’t changed anything, involve your manager. Escalate when:
You’ve had the direct conversation at least twice and the behavior hasn’t changed
Your team’s delivery or morale is measurably suffering
The PM is making commitments to stakeholders without engineering input
Trust has eroded to the point where you can’t give feedback effectively
When you do, lead with facts: *”I’ve raised X with [PM name] twice. Here’s what I asked for, here’s the impact on the team. I need your help figuring out the next step.”*
Five Anti-Patterns That Will Tank the Relationship
Knowing what to do is half the battle. Here’s what to stop doing.
The Ticket Machine. You treat your PM as a requirements factory — they write specs, you build them, nobody talks about whether the specs make sense. Before building anything, ask “What problem are we solving, and how will we know we solved it?”
The Back-Channel Complainer. You disagree with your PM’s priorities but vent to your team instead of saying it to their face. Your PM finds out eventually — they always do — and now they don’t trust you. Disagree directly, in private, with data: ”I see this differently — can we grab ten minutes before we commit?”
The Scope Creep Enabler. Your PM keeps adding “just one more thing” and you absorb it silently because you want to be a team player. Use The Tradeoff Table every time: ”We can absolutely add that. Here’s what it costs. What should we cut to make room?”
The Technical Gatekeeper. You use complexity as a weapon — “that’s not possible” when you mean “that’s hard.” PMs can smell this from a mile away. Be honest about effort, explain why something is hard, and bring a simpler alternative that gets 70% of the value.
The Absent Partner. You skip product reviews, don’t read specs until sprint planning, and can’t name your team’s top three metrics. Block 30 minutes a week to read what your PM is writing — you don’t need to become a product expert, just informed enough to ask good questions.
I’ve lived #2 firsthand. After a reorg, I started working with a PM whose work ethic didn’t match my team’s intensity. I tried to steer them — more rigor, less ad-hoc — but the feedback didn’t stick, and I wasn’t experienced enough to make it land. So the frustration leaked. My “venting” to my manager turned into ammunition that went up the chain. Senior leadership delivered harsh feedback, and eventually the PM left the organization.
The worst part wasn’t that he left. It was that my inability to be direct destroyed the collaboration long before anyone intervened. Avoiding hard conversations to keep the peace is a recipe for a worse explosion later.
Start With One Conversation
If this all feels like a lot, start with one thing: schedule a Why Sync with your PM this week. Thirty minutes. No agenda beyond “let’s make sure we’re seeing the same picture.”
You’ll be surprised how much changes when you simply show up with curiosity about their world. Most PMs have never had an engineering partner ask “what are you most uncertain about?” Try it. Watch what happens.
How you’ll know it’s working
This takes time — your PM relationship probably won’t feel like a real partnership next week, and that’s fine. But if you commit to these conversations, here’s what the progression looks like:
Month 1: Your PM stops being surprised by timeline pushback. Scoping conversations get shorter because you’re both working from the same context.
Month 3: You can answer your team’s prioritization questions without escalating to your PM. You have enough product context to make the call yourself — and your PM trusts you to make it.
Month 6: Your PM proactively asks your opinion before making commitments to stakeholders. You’re not just informed — you’re consulted. That’s the co-pilot dynamic working.
If you’re three months in and still getting blindsided by roadmap changes, the conversations aren’t going deep enough.
Your PM relationship is the first real test of whether you’ve made the transition from builder to leader. As an IC, you could be great in isolation. That’s over now. Your impact lives or dies in the space between you and the people you share ownership with — and your PM is the first one across the table.
Get this right and everything else gets easier. Get it wrong and no amount of engineering excellence will save you.
If you found this useful, subscribe to Stratechgist for more practical leadership playbooks. You can also find me on LinkedIn — I post about engineering leadership, career growth, and the messy reality of crossing from IC to leader.