Working with product managers and stakeholders

Strong engineering teams ship because their cross-functional relationships work.
That means aligning with product, collaborating with design, and staying in sync with everyone from support to sales. It’s not politics for its own sake; it’s how work moves.

Here’s what matters most.

Partnering with product

The EM–PM relationship is a daily collaboration. You bring engineering capacity, tradeoffs, and execution; they bring customer insight, priorities, and strategy. When it’s healthy, PMs also act as a shield, absorbing a lot of the organizational cross-winds so the team can build.

A few tactics that help:

• Share your capacity model early (vacations, onboarding, KTLO [keep the lights on]) so scope matches reality.
• Translate technical debt into business risk or velocity impact so it competes fairly with feature work.
• Agree on who decides what: product owns the "why/what," engineering owns feasibility, sequencing, and staffing.

I put it this way on the podcast:

“This goes back to the note what your counterpart's agenda is. If you understand what their goals are, you can better tailor your needs to align with their goals.”

Working with design

Design is a core partner, not a service desk. Two recurring friction points: sequencing and feasibility.

What’s worked for us:

• Involve design in planning so their effort is modeled like any other dependency.
• When design is bandwidth-constrained, let engineers build a low-fidelity version and iterate with design reviews.
• If you don’t have a mature design system, budget for the ripple effects of component changes across the app.

Beyond EPD: the wider stakeholder map

At larger companies you’ll mostly interface within your product area. In smaller orgs you’ll also sync with support, customer success, sales, marketing, and other EMs. That means:

• Triage escalations against roadmap work with clear tradeoffs.
• Surface inter-team dependencies early, especially in monoliths or shared platforms.
• Use embeds or shared channels when work spans teams for weeks, not days.

Make collaboration work (habits that scale)

• Communicate early and often. Kickoffs, weekly check-ins, and async updates prevent rework.
• Plan concurrently, not serially. Get product, design, and engineering in the room at the start to reduce “throw it over the wall” delays.
• Meet people in their tools. Figma/Storybook for design; Jira/Asana for product; keep a lightweight project doc for status, risks, and decisions.
• Build product-minded engineers. Teach “customer-back” thinking so the team can keep moving when specs are still forming.

Try this

Before saying yes to a mid-flight scope change, ask:
What’s the business case for adding this now, and what slips if we do?
If it’s worth it, make the tradeoff explicit and visible. If not, fast-follow it post-launch.

What to read

📚 Inspired by Marty Cagan — practical patterns for product–engineering collaboration, from discovery to delivery.
🎧 The Mel Robbins Podcast — especially her “Let Them Theory” discussion on focusing energy on what you control.

Listen to the full episode: Working with Product Managers & Stakeholders