By Sahil Singh, Founder of Glue
There's a quiet tension in almost every product team. Product managers and engineers work toward the same goals, ship the same features, sit in the same standups. But they operate with fundamentally different views of the product. PMs see user stories, roadmaps, and metrics. Engineers see code, systems, and dependencies. The product manager developer relationship breaks down not because of bad intentions, but because of an information asymmetry that neither side created.
I've seen this pattern at every company I've worked with. It's not a people problem. It's a visibility problem.
The Trust Gap in Numbers
Let's put some data behind what most teams feel intuitively.
95% of product managers don't have a coding background (airfocus). That's not a criticism. You don't need to code to be a great PM. But it means nearly every PM on every team is making technical trade-off decisions without being able to independently verify what's happening under the hood.
Meanwhile, PMs spend roughly 52% of their time firefighting rather than doing strategic work (Pragmatic Institute). More than half the workweek goes to reactive tasks: chasing down status updates, clarifying requirements, mediating scope disputes. That's not product management. That's project management by default.
On the engineering side, the cost is just as real. Research from Gloria Mark at UC Irvine shows that it takes an average of 23 minutes to refocus after an interruption. Every "quick question" from a PM who can't find the answer themselves costs far more than the two minutes it takes to answer.
And the downstream impact? PMI reports that 70% of project failures trace back to poor requirements and miscommunication, not bad code.
The trust gap isn't about competence. It's about two groups of smart people trying to collaborate while looking at completely different information.
Why PMs Ask "Dumb" Questions
Engineers often get frustrated when PMs ask questions that seem basic. "What service handles checkout?" "Who owns the notification system?" "Why can't we just add a field to this API?"
These aren't dumb questions. They're evidence that the PM has no way to find the answers independently.
Most product managers I've talked to don't want to interrupt engineers. They know it's disruptive. They know it costs focus time. But when the alternative is making a prioritization decision with zero technical context, what choice do they have?
The typical PM toolkit includes Jira tickets, Confluence pages, and maybe a stale architecture diagram from two years ago. None of these reflect the current state of the codebase. None of them update automatically. None of them answer the question: "What is actually happening in our code right now?"
So PMs ask engineers. And they feel bad about it. And engineers feel frustrated by it. And both sides start developing subtle resentments that erode the product manager developer relationship over time.
I've watched this cycle play out dozens of times. The PM starts hesitating to ask questions. The engineer starts giving shorter answers. The PM makes assumptions. The assumptions turn out to be wrong. The engineer loses trust. The PM loses confidence.
Nobody wanted this outcome. The system created it.
Why Engineers Get Frustrated
Let's be honest about the engineering perspective, because it's equally valid.
Engineers aren't frustrated because they dislike PMs. They're frustrated because they're being used as a human search engine for information that should be accessible without them.
When a PM asks "how does the payment flow work?", the engineer has to stop what they're doing, context-switch out of deep technical work, verbally summarize a system they've spent months building, and then spend 23 minutes getting back into their original task.
Multiply that by three or four questions a day, across a team of PMs, and you've just burned a significant chunk of engineering capacity on knowledge transfer that could be automated.
Engineers also get frustrated when PMs push back on estimates without understanding the underlying complexity. "Why does this take three sprints?" is a reasonable question. But answering it requires explaining dependency chains, technical debt, testing requirements, and architectural constraints to someone who can't see any of those things directly.
The frustration isn't personal. It's structural. Engineers are the only people who can see inside the product, and that makes them the bottleneck for every question anyone else has about how things work.
If you've been in this position, you know it's exhausting. You want to build. Instead, you're translating. Understanding software architecture as a PM shouldn't require scheduling a meeting with a senior engineer every time.
Fixing the Root Cause: Visibility
Most advice for improving the product manager developer relationship focuses on process: better standups, refined ticket templates, shared OKRs, team-building activities. These help at the margins. But they don't fix the root cause.
The root cause is that PMs can't see their own product.
They can see the UI. They can see the analytics. They can see the backlog. But they can't see the system itself: the services, the dependencies, the ownership, the complexity, the history of changes. That information lives in the codebase, and the codebase is locked behind a skill barrier.
Fixing this doesn't mean teaching PMs to code. (There's a whole separate debate about whether PMs should learn to code, and the answer is more nuanced than you'd expect.) It means giving PMs a way to access codebase knowledge without writing code.
This is what Glue's PM workspace is designed to do. It connects to your repositories and lets PMs ask plain-language questions about the codebase. "What services does the checkout flow touch?" "Who last modified the recommendation engine?" "What are the dependencies for the user profile service?"
No code reading required. No engineer interrupted.
When PMs can answer their own questions, several things happen at once. They stop interrupting engineers for basic context. They make better-informed prioritization decisions. They write more accurate requirements. And engineers start trusting their judgment more, because the questions they do ask are now the hard, strategic ones that genuinely benefit from a collaborative conversation.
The trust gap closes not because people try harder, but because both sides finally have access to the same information.
What This Looks Like in Practice
Picture a sprint planning session. The PM proposes adding a new notification type. Instead of the engineer saying "that's more complex than you think" and the PM saying "how complex?", both of them can look at the same system view.
The PM already knows the notification service has four downstream dependencies, that the last major change introduced a bug that took two weeks to resolve, and that the primary author is on parental leave.
That PM doesn't need to ask "dumb" questions anymore. They're walking into the conversation with context. And the engineer, instead of feeling interrogated, feels like they have a partner who understands the terrain.
That's what a healthy product manager developer relationship looks like. Not one where the PM learned to read code, but one where the information barrier was removed.
If your team is stuck in the cycle of misaligned expectations and quiet frustration, the answer probably isn't another retro. It's giving everyone the same view of what you're building.
Start with Glue and see what happens when your whole team can see the product.
FAQ
Why don't engineers trust product managers?
The lack of trust usually stems from information asymmetry, not personal conflict. Engineers can see the full complexity of the codebase, including dependencies, technical debt, and risk. PMs typically cannot. When PMs push back on estimates or propose features that ignore hidden complexity, engineers feel their expertise is being dismissed. The fix is giving PMs independent access to technical context so their questions and decisions reflect the reality of the system.
How can PMs build trust with engineering?
The most effective way is to reduce how often you need to ask engineers for basic technical context. Tools like Glue let PMs explore the codebase through natural-language questions, which means you show up to conversations already informed. Engineers trust PMs more when PMs demonstrate an understanding of technical constraints. You don't need to code, but you do need to know what's going on under the surface.
Should product managers learn to code?
It depends on what you mean by "learn to code." Writing production-quality software isn't necessary and probably isn't a good use of a PM's time. But developing code literacy, the ability to understand how systems are structured, what dependencies exist, and why certain changes are complex, is extremely valuable. Modern code intelligence tools make this possible without learning a programming language. For a deeper take, read our post on whether PMs should learn to code.