How Developers Can Build Better Relationships with Product Managers

Early in my career, I didn’t have the best relationships with Product Managers. I thought they were handing off incomplete work for me to figure out on my own. In my mind, their job was to give me fully thought out requirements, and mine was to build exactly what they described. When requirements were vague, I pushed back. When they changed their minds, I got frustrated. What I didn’t do was stop and think about what was going on from their side.

Over time, I made mistakes. Luckily, I had mentors who were patient enough to call me out and show me a better way. I eventually realized something that should have been obvious from the start. PMs and engineers are not on opposite sides. We are solving the same problem, just from different angles.

Pushing Back Can Be Tricky

Pushing back on requirements, especially in a PM led organization, can feel like stepping on a landmine. It implies their work isn’t good enough, which can make people defensive. Some PMs might even tell you they won’t know what they need until they see it in action, which often leaves engineers feeling like they’re building in the dark.

Engineers want clarity upfront. PMs want flexibility to adjust as the product evolves. That tension is always going to exist, but great teams learn how to navigate it.

Most developers have that one PM they love working with. The one who just gets it. They understand the project, anticipate technical challenges, and make it clear why the work matters. Collaborating with them feels natural. It is enjoyable and productive. But what happens when you don’t have that ideal PM?

Understanding What a PM Actually Does

The textbook definition of a Product Manager says they are responsible for ensuring Product Market Fit. But in reality, it is rarely that clean. PMs don’t work in a vacuum where they can focus solely on customer needs.

Requests often come down from sales, support, or leadership. Teams that aren’t thinking about Product Market Fit at all. Sometimes PMs are running with half formed ideas from an executive meeting. Other times, they are juggling multiple features at once while fielding demands from different stakeholders.

If you assume every request is perfectly thought out, you’ll get frustrated. If you assume every request is garbage, you’ll also get frustrated. The truth is usually somewhere in between. Many PMs are stuck in the middle, trying to manage priorities from every direction and make sense of chaos.

Shifting Your Mindset

Before assuming a PM doesn’t understand the problem, take a step back. Everyone on the team is playing the same game, but not everyone has the same rules. PMs are working under different pressures and expectations.

Take the time to ask questions:

• When did you get assigned to this product?

• How many PRDs are you juggling right now?

• Are there other launches or priorities pulling your attention?

You might learn that they just got pulled onto the project last week, or they’re managing five products at once, or leadership is pressuring them for timelines before they’ve had the chance to figure out what’s realistic. When you understand their situation, you can work with them instead of reacting against them.

Like any relationship, it is something you build over time. Think of it like a real life state machine. Each interaction moves you forward in stages. Before diving into deeper conversations, make sure you’ve built some trust. Once that foundation is in place, take the time to understand what they’re being measured on. Developers are judged on code quality, complexity, and hitting deadlines. PMs have their own grading scale, which depends on the organization, but they’re often based on delivering value, hitting feature deadlines, or achieving certain business outcomes.

Just like developers have their own sense of internal worth, PMs do too, and often it doesn’t align with what’s being asked of them. Instead of assuming they’re focused on the wrong things, try to see it from their perspective. What does their manager expect? Where can they bring the most value based on their expertise and passion? When you start seeing things from their side, collaboration becomes a lot easier.

Taking a Pass at Their Documents Does Not Mean Rewriting

One of the best ways to collaborate with a PM is to take a pass at their documents before you start coding. That doesn’t mean rewriting the PRD. It means asking the right questions, taking notes, and making sure you actually understand what’s being asked.

Don’t skim the document. Read it once, twice, even three times if needed. Look for gaps and patterns. Over time, you’ll start to recognize who wrote the document just by reading the first paragraph.

Never start building after a quick skim. No matter the quality of the document, treat it like the architect’s source code. Read closely, take notes on anything unclear, and bring your questions to the PM before diving into development. These questions don’t just help you. They give the PM insight into how you’re thinking through the problem.

I look for requirements that are oversimplified. What seems simple to a user, like a single button, might involve complex logic behind the scenes. That button could trigger a Kafka event, connect to multiple databases, and run through layers of validation with extensive testing. The reverse is also true. Sometimes, overly detailed requirements can be solved with a one liner or by using an existing library. What seems complex can often be simplified, and what seems simple can hide unexpected complexity.

Spotting these hidden challenges or realizing when something has been over explained starts with reading the document carefully.

Once you’ve gone through the document, the next step is making sure gaps are addressed. Instead of saying, "This requirement doesn’t make sense," ask targeted questions:

• "The flow assumes X happens first, but what should happen if Y occurs instead?" (Especially important outside strict industries like finance or aerospace where every scenario isn’t fully mapped out.)

• "The success criteria mention response times under 100ms. Is that a hard requirement or just a target?" (Show them current response time graphs. If the current response is 500ms, explain that optimizing down to 100ms could be an entirely separate feature.)

• "This feature looks like it’s designed to scale to thousands of users from day one. Are we expecting that level of traffic immediately, or can we phase it in?" (This decision affects DBAs and SREs who need to plan for infrastructure.)

This approach does two things. First, it shows that you’ve thought through the request instead of reacting blindly. Second, it helps the PM clarify their own thinking early, reducing surprises down the line.

Practical Strategies for Working Together

Pushing back isn’t about shutting down ideas. It’s about collaborating to get better outcomes. If requirements are unclear, don’t just say, "This is incomplete." Offer to help refine them.

Saying, "I’d like to take a pass at this and get back to you before we start building," turns the conversation into a partnership, not a debate.

If time allows, ask for space to do early discovery work. If the project involves unfamiliar technology, spin up a quick prototype and throw it away. The second attempt will always be better than the first and it’s easier to estimate effort after you’ve actually touched the problem.

Think about scaling realistically. PRDs often assume features will need to handle ten thousand users from day one, but that’s rarely the case. Breaking a feature into phases based on real user growth makes life easier for everyone.

Better Communication, Better Products

One of the most common mistakes engineers make is sending vague, open ended messages that shift all the work onto someone else. A message that just says, "Thoughts?" might take you ten seconds to send but could leave someone else spending an hour trying to figure out what you actually need.

Instead of, "Not sure about this feature. Thoughts?" try, "Since we didn’t define an unhappy path, I used our standard error screens. Does that work?" This keeps the conversation moving forward and respects everyone’s time.

Avoid Surprises

PMs should never see a feature for the first time during a demo. Unless they’ve specifically asked for a surprise, which never happens, send them a preview beforehand. Give them time to process and think about feedback before showing it to the wider team.

If you made an assumption where requirements were unclear, call it out. A simple message like, "We didn’t have a defined unhappy path, so we used our standard screens. Does that work?" keeps everyone aligned and prevents last minute surprises.

Dev vs. Product Is a Losing Battle

If Product and Engineering aren’t aligned, every estimate and progress update becomes meaningless. Developers might think everything is on track, while the PM believes key elements are missing. When that happens, Product usually wins because they’re the ones communicating with leadership and customers.

The solution isn’t to win the battle. The solution is to stop thinking of it as a battle in the first place. Product and Engineering are not adversaries. The goal isn’t to prove who’s right. It’s to build the best product possible.

A strong PM dev relationship doesn’t mean agreeing on everything. It means learning how to navigate disagreements without derailing the team. The best engineering teams don’t just build features. They help shape them.

If you take the time to understand where your PM is coming from, improve how you communicate, and stay involved in refining requirements, you’ll go from feeling like you’re fighting against Product to building something great together.

Winning Is Not the Goal. Building Is.

The best engineers don’t just shape problems. We shape how they’re solved. But no matter how skilled you are, you can’t do it alone.

Product and Engineering are not on different sides, even if it sometimes feels that way. The goal isn’t to win an argument. It’s to build something that works. Something users actually want to use. Something that makes sense for the business. Something your peers can be proud of.

Disagreements should happen. They should push the product forward. Just don’t make them personal.

You can build a better product together.