How to Work Effectively With Product Managers as an Engineer

The best products I've worked on were built by engineers and PMs who trusted each other. The worst were built by teams where engineering and product were in constant tension, each side feeling like the other didn't understand their constraints.

The difference was never about having better PMs or better engineers. It was about how the two groups communicated.

Understanding What PMs Actually Do

Early in my career, I saw PMs as "the people who write tickets." That's like saying engineers are "the people who type code." Technically true. Completely misses the point.

PMs are responsible for deciding what to build and why. They synthesize input from users, business stakeholders, data, and engineering to make prioritization decisions. The good ones are constantly juggling competing demands with incomplete information.

When a PM asks you to estimate a feature, they're not trying to hold you to a deadline. They're trying to prioritize. If feature A takes 2 weeks and feature B takes 2 months, that information changes the roadmap.

How I Communicate With PMs

Lead With the "Why," Not the "How"

PMs don't need to know about your database schema. They need to know: will this work for users? How long will it take? What are the risks?

Bad: "We need to refactor the data layer to use Room instead of
SQLite directly, which requires migrating the schema and updating
all the DAO interfaces."

Good: "The current data storage approach is causing crashes for
about 2% of users and makes it hard to add new features quickly.
I'd like to spend a week upgrading it. After that, new features
in this area will be 30-40% faster to build."

The second version tells the PM what they need to know: the user impact, the time investment, and the payoff.

Say "Yes, and" Instead of "No"

When a PM proposes something that's technically problematic, my instinct used to be "that won't work." Now I say: "Here's what that would require, and here's an alternative that gets 80% of the value at 20% of the cost."

PMs are flexible on implementation. They're less flexible on outcomes. If you can deliver the outcome through a simpler path, they'll usually take it.

Share Constraints Early

The worst surprise for a PM is discovering, two weeks into development, that something is much harder than expected. I share blockers and risks as soon as I see them.

"I started looking at this and the API doesn't support the query we need. I have three options: work around it on the client side (adds complexity), ask the backend team for a new endpoint (adds a dependency and 2 weeks), or scope down the feature to what the current API supports. Which direction should we go?"

This turns a problem into a collaborative decision instead of a unilateral delay.

Give Honest Estimates With Context

"It'll take 3 weeks" is less useful than "it'll take 3 weeks, broken down as: 1 week for the core feature, 1 week for edge cases and error handling, and 1 week for testing and polish. If we cut the edge cases, we could ship a basic version in 2 weeks."

This gives the PM options. They can decide whether the edge cases matter for the initial launch or can come later.

The Relationship That Works

The best PM-engineer relationships I've experienced share these traits:

Mutual respect for expertise. The PM doesn't tell me how to architect the system. I don't tell them how to prioritize the roadmap. We each trust the other's judgment in their domain.

Shared context. We both understand the business goals, the user problems, and the technical constraints. Neither side is operating with information the other doesn't have.

Direct communication. Disagreements happen openly, not passively. If I think a feature is a bad idea, I say so with reasons. If the PM disagrees with my technical approach, they ask questions.

Flexibility on both sides. Sometimes engineering priorities take precedence (addressing tech debt, fixing reliability issues). Sometimes product priorities take precedence (a time-sensitive launch, a competitive response). Neither side "wins" every time.

The engineer-PM relationship isn't about alignment on every decision. It's about trust that the other person is making the best call they can with the information they have.