Want Respect From Engineers? Do the One Thing They Won't
If you want to get respect from engineers as a PM, start doing the one thing they mostly don't care about: customer research.
Engineers don't wake up excited about customer interviews or market analysis. That's not their passion. They wake up excited about solving elegant technical problems, writing clean code, and building systems that scale.
But the quality of what they build depends entirely on the clarity of what you, as a PM, bring to the table.
TL;DR: Engineers respect PMs who do thorough preparation before a single line of code is written. Customer research, usage data analysis, and deep problem understanding aren't just "PM tasks." They're what prevents scope creep, deadline pressure, and wasted effort. When you do that work well, engineers can focus on what they love: solving problems through great engineering. That's when they see you as a partner, not a manager.
Two scenarios. Same team. Different PM.
Imagine two scenarios playing out in the same sprint planning meeting.
Scenario 1: The PM who adds chaos
A PM walks into sprint planning and says: "We need to consider one more scenario..."
At first, it sounds harmless. Just one more thing to think about. Fine.
But then it happens again next week. And the week after. Each sprint, new edge cases surface. Scope quietly expands. Requirements shift after engineering has already started building.
What follows:
- Deadlines shift
- Management raises eyebrows
- Pressure kicks in
- Engineers start dreading PM conversations because each one means "more work we didn't know about"
This PM is discovering the problem while engineering is already solving it. That's backwards. And engineers feel it every single day.
Scenario 2: The PM who brings clarity
A different PM has done extensive research before sprint planning. They've spoken with customers. They've looked at usage data. They've found the subtle but critical nuances of what truly matters.
When they walk into sprint planning:
- They know exactly why the work matters (and can explain it in 30 seconds)
- They know what's in scope and what's explicitly out of scope
- They've thought through edge cases before engineering has to discover them
- They know how realistic the timeline is because they've scoped the problem properly
This PM prevents unnecessary pressure. They can shield the team from distractions because their clarity is strong enough to say "no" to incoming requests with confidence.
The difference is huge
As you can see, the contrast between these two PMs is enormous. And engineers feel it immediately. They might not articulate it as "good research vs. bad research." But they'll say things like:
- "Working with [PM name] is smooth. They always know what we're building and why."
- "I trust [PM name]'s specs. When they say this is the scope, it stays the scope."
- "With [other PM], every sprint feels like we're discovering new requirements mid-build."
That trust isn't earned through personality or charm. It's earned through preparation.
What thorough preparation actually looks like
Let's be specific about what "doing customer research" means in this context:
Before writing a single spec:
- Talk to 5-10 customers who have the problem you're solving
- Understand their current workaround (not just the pain, but how they deal with it today)
- Identify edge cases from real usage patterns, not hypothetical scenarios
- Look at support tickets and usage data for the related feature area
- Talk to sales and CS about what they hear from customers
Before sprint planning:
- Define explicit scope boundaries (what's in, what's out, and why)
- Document known edge cases with clear decisions on each
- Clarify the "done" criteria so there's no ambiguity about what shipping means
- Anticipate engineering questions and have answers ready
During execution:
- Be available for quick decisions (don't become a blocker)
- When new information surfaces, assess it against the research already done
- Shield the team from new requests by having a strong rationale for current scope
The prep work before engineering starts is where PM value lives. Everything during execution is just maintaining the clarity you already built.
Why engineers respect research (even though they don't do it)
Engineers are problem-solvers. They want to solve the right problem, solve it well, and ship it without wasted effort.
Customer research gives them exactly that:
- The right problem: "Here's what users actually need, validated through conversations"
- Clear constraints: "Here's what's in scope, here's what's out, here's why"
- Confidence in direction: "We're not going to pivot mid-sprint because I've done the homework"
- Protected time: "I can push back on random requests because our direction is evidence-based"
When you provide this clarity, engineers can focus on what they love: solving problems through great engineering. They're not context-switching between coding and trying to figure out what they're supposed to build. They're not worried about scope changes. They're not frustrated by ambiguity.
The respect equation
Respect from engineers isn't earned through:
- Constant check-ins ("how's it going?")
- Being in every meeting
- Having strong opinions about code architecture
- Micromanaging timelines
Respect is earned through all the preparation before a single line of code is written.
| PM action | Engineer perception |
|---|---|
| Shows up to planning with clear scope based on research | "This person did their homework. I trust the direction." |
| Can explain why this matters to users (with evidence) | "The work feels meaningful. Not arbitrary." |
| Has already considered edge cases | "I can focus on engineering, not discovery." |
| Shields the team from random requests | "This PM has my back." |
| Admits uncertainty honestly ("I'll find out") | "This person is honest. I can trust what they tell me." |
The common failure: research as a one-time event
Some PMs do customer research at the beginning of a project and then never again. That's better than nothing. But the real value comes from continuous, lightweight research that keeps you ahead of the team.
Continuous research looks like:
- A 30-minute customer call every week (not a big project, just a habit)
- Scanning support tickets for your feature area weekly
- A quick check on usage data before each sprint planning
- A running doc of patterns you notice across conversations
This keeps your knowledge fresh. So when an edge case comes up mid-sprint, you often already know the answer. You don't need to "go find out." You can decide on the spot because you've been close to the problem continuously.
That responsiveness, the ability to make quick, confident decisions without slowing the team down, is what engineers value most in a PM.
When you do this well, everything changes
The dynamic shifts from:
Without research: PM brings requirements → Engineers find gaps → PM scrambles to fill gaps → Scope changes → Frustration all around
With research: PM brings clear, validated requirements → Engineers build with confidence → Minimal surprises → Trust compounds → The team moves faster sprint over sprint
And that's when engineers see you not as someone who just "manages" but as a true partner in building great products.
They start bringing you technical insights proactively. They flag risks early because they trust you'll handle them well. They suggest alternative approaches because they know you'll evaluate them fairly.
That partnership is the highest form of PM-engineering collaboration. And it starts with customer research.
The bottom line
Respect from engineers isn't about being technical. It's not about writing code or understanding system architecture (though that helps).
It's about doing the work they can't (or won't) do: understanding customers deeply, scoping problems clearly, and bringing that clarity to the team before they start building.
Do that consistently, and you'll never have to ask for respect. You'll have earned it through the only currency that matters in engineering teams: making their work better.
How ProductResume helps
If you're a PM who drives clarity through research and preparation, your resume should reflect that. Bullets like "conducted customer research" are generic. Bullets like "identified 3 critical workflow gaps through 15 customer interviews, reducing post-launch scope changes by 60%" show the impact of your research. Score your PM resume to see whether your experience communicates this kind of preparation-driven impact.