Why Product Managers Are Often Seen as the Idiot in the Room

Let me open with a quote I heard recently, during a moment of loose banter with the team. Someone said, with the particular deadpan timing that only engineers seem to have mastered: "Respect your PM. You might have gotten a dumber one."

The room laughed. The PM in question laughed too, which is probably why they were well-liked. But underneath the joke is a real dynamic that most Product Managers will recognise, whether they admit it or not.

The relationship between a PM and their team is one of the stranger ones in professional life. It sits somewhere between leadership and service, between strategic direction and daily facilitation, between having genuine authority over the product and having essentially no formal authority over the people who build it. The PM is accountable for outcomes they cannot directly control, responsible for decisions that require input from people who often know more than they do, and visible enough that when things go wrong, they are a natural focal point for frustration.

In that context, it is perhaps not surprising that the PM sometimes ends up as the punching bag. What is worth examining is why it happens, and what the PMs who avoid it do differently.

The Love-Hate Dynamic

Before we get into the specific failure modes, it is worth being honest about the structural reasons why PM-team relationships are difficult.

The PM sits at the intersection of multiple competing interests. Engineering wants to build things properly, which requires time, clear requirements, and protection from arbitrary changes. Business leadership wants outcomes delivered on schedule, which requires urgency, flexibility, and a willingness to make pragmatic compromises. Customers want their problems solved, which requires the team to stay close to real-world feedback rather than internal assumptions. Sales wants features that close deals. Support wants fixes that reduce ticket volume.

The PM is the person trying to hold all of those interests in balance simultaneously, which means they are, by definition, the person who is failing to fully satisfy any of them at any given moment. That is not a character flaw. It is an inherent feature of the role.

What separates the PMs who are genuinely respected from the ones who become the team's punching bag is not that the respected ones avoid hard trade-offs. It is that they navigate them in ways that build trust rather than erode it. And that navigation almost always comes down to a small number of specific behaviours, each of which corresponds to a specific failure mode.

But before you go there:

=================

I and Aakash Gupta are starting the 3rd edition of our “Land PM Job” Cohort on May 4th.

Most PMs don’t fail interviews because they lack frameworks. They fail because they don’t have a system. This program shows you how to turn your experience into a story, your story into interviews, and interviews into offers.

Hundreds of PMs have already gone through this system, many landing interviews within weeks and offers shortly after. Instead of sending 100+ cold applications into the void, you focus on a targeted, high-conversion approach that actually gets responses. The expected outcome is simple: more interviews, better conversations, and a real shot at landing a PM role in today’s AI-shaped market.

Secure your seat today:
https://www.landpmjob.com/

===========

Now, back to the article:

1. The Technical Knowledge Gap

Not every Product Manager writes code. That is entirely reasonable, and any engineer who expects their PM to have deep technical knowledge is expecting the wrong thing from the wrong person.

What is not entirely reasonable is a PM who makes no effort to understand how the technology works at even a conceptual level, who cannot follow a conversation about system architecture, who treats engineering complexity as an inconvenience rather than a real constraint, and who consequently makes decisions that are technically incoherent without realising it.

The engineers on the other side of that conversation do not feel they have a strategic partner. They feel they are explaining their work to someone who will never quite understand it, which is an exhausting and demoralising position to be in over any extended period.

The standard to aim for is not technical expertise. It is technical fluency, which is a meaningfully different thing. Fluency means being able to follow the conversation, ask questions that reveal genuine curiosity rather than polite nodding, understand why a seemingly simple request might require significant architectural work, and know enough to distinguish between a technical constraint that is genuinely fixed and one that is a matter of preference or estimation.

This fluency is built through deliberate practice. Ask your engineers to explain things until you understand them, not just until you feel you have spent enough time on the question. Ask why and how at every opportunity, and do not perform understanding you do not have. Engineers can tell the difference immediately, and the performance of comprehension is more damaging to trust than honest ignorance.

For the engineers reading this: if your PM is genuinely trying to learn and is asking questions in good faith, that effort deserves to be met with patience rather than exasperation. Communication is a two-way process, and the cost of bringing a PM up to the necessary level of understanding is almost always lower than the cost of the decisions that get made in its absence.

2. The Top-Down Pivot Problem

Here is a scenario that every PM who has worked in a corporate environment will recognise.

Leadership makes a decision that materially changes the product direction. The decision may have been made with good reasons that were not fully communicated downward, or it may have been made with less rigour than the product team would have applied, or it may simply reflect a strategic priority that the team was not previously aware of. The PM finds out, along with everyone else, and is now responsible for implementing a change they did not shape and may not fully understand.

The team looks to the PM for an explanation. And the PM, caught between loyalty to leadership and honesty with the team, defaults to the easiest option: forwarding the email, offering a brief summary, and moving on to the implementation details.

This is a mistake, and it is one that compounds over time. Each instance of information being filtered or sanitised in this way adds a small amount of erosion to the team's trust in the PM as a source of honest communication. Individually, each instance is minor. Cumulatively, they produce a team that has stopped believing that the PM will tell them what is actually going on, which makes everything harder.

The more effective approach is transparency about the situation as it actually is, including its ambiguities. This does not mean criticising leadership or performing scepticism about decisions to seem relatable to the team. It means acknowledging that the context is complicated, sharing what you know and what you do not know, explaining the reasoning as best you understand it, and being honest when you think the pivot creates challenges that need to be worked through together.

Teams do not need their PM to be a cheerleader for every decision that comes from above. They need their PM to be a reliable and honest interpreter of reality. The PM who consistently provides that, even when reality is complicated or uncomfortable, earns the kind of trust that survives difficult moments.

3. The Micromanagement Trap

There is a specific and particularly damaging form of micromanagement that PMs are prone to, which is different from the version that gets discussed in most management literature.

Standard micromanagement involves excessive oversight of work that is well-understood by both parties. The PM version involves attempting to direct work that the PM does not have the knowledge to direct well, which combines the morale cost of micromanagement with the practical cost of being guided by someone who does not understand the domain.

An engineer who is being second-guessed on implementation decisions by a PM who cannot evaluate those decisions has a legitimate grievance. It is not that the oversight is unwelcome in principle; it is that oversight without competence is not oversight at all. It is interference.

The discipline required here is one of clear role definition. The PM's domain is the what and the why: what the product needs to achieve, for whom, and why that matters. The engineering team's domain is the how: the technical decisions, the implementation approaches, the architectural choices that the PM is not qualified to make. These domains can and should overlap in collaborative ways, but the PM who regularly wanders into engineering territory without being invited there will find that the invitation to be involved in strategic conversations gets withdrawn in return.

Setting the destination is a meaningful and important job. It does not require also trying to pilot the ship.

4. The Chemistry Problem

Some PM-team relationships simply do not click, and it would be dishonest to suggest that every interpersonal dynamic can be repaired through the right professional behaviours.

That said, a significant proportion of PM-team friction that gets attributed to chemistry is actually the downstream consequence of the professional failures described above. When the PM is technically competent enough to be a genuine partner, communicates honestly even when it is uncomfortable, and respects the boundaries of their role, many of the interpersonal tensions that seemed personal turn out to have been professional.

Where genuine rapport is missing, the investment required to build it is often more modest than it appears. It does not require the PM to become a different kind of person or to perform warmth they do not naturally have. It requires making space for the kinds of human interactions that are easy to skip when the calendar is full and the backlog is long.

Regular one-to-ones that are genuinely about the person rather than the work. Acknowledging team members' contributions publicly and specifically. Noticing when someone is having a hard time and saying something about it. Being present in the informal moments, the Slack conversations, the end-of-day chat, and the occasional lunch reminds everyone involved that they are working with people rather than resources.

None of this is complicated. All of it requires the PM to be consistently willing to prioritise it, which is harder than it sounds when the alternative is answering emails.

5. The Motivation Question

Nobody does their best work on tasks they find meaningless. This is not a controversial claim, and yet roadmaps consistently contain work that is assigned without apparent consideration of whether it is the kind of work that brings out the best in the people being asked to do it.

The PM who treats task assignment as a purely logistical exercise, matching capacity to work items without regard for where the team's strengths, interests, and growth ambitions lie, is missing one of the most straightforward levers available to them for improving both output quality and team morale.

This does not mean the roadmap should only contain exciting work. Maintenance, technical debt, compliance requirements, and unglamorous infrastructure investments are all real and necessary, and part of the PM's job is to ensure that work gets done even when nobody is enthusiastic about it.

What it does mean is that the PM should be thinking actively about the balance between the work that is necessary and the work that is engaging, and about how to structure assignments in ways that give team members regular opportunities to work on things they find genuinely interesting and that develop skills they care about building. Rotation, pairing, and deliberate matching of growth opportunities to individual interests are all practical tools that require attention but not significant additional resources.

A team that feels it is growing is a very different team from one that feels it is grinding. The PM has more influence over that distinction than most of them exercise.

6. The Quality and Velocity Trade-Off

"Ship fast" is one of those product mantras that sounds compelling in a conference talk and reveals its costs gradually and painfully in practice.

Speed is genuinely valuable. Time to market matters. Momentum matters. The discipline of shipping frequently and learning from real-world usage rather than extended internal deliberation is a real and important principle. None of that is in dispute.

The problem is when speed becomes a value that consistently overrides quality, without any corresponding plan for addressing the technical and experiential costs that accumulate as a result. A codebase that has been pushed hard for several quarters without meaningful investment in quality becomes progressively harder and more expensive to work in. A product experience that has accumulated a backlog of rough edges and known bugs loses the trust of its users incrementally, in ways that are difficult to recover from quickly. Engineers who are repeatedly asked to cut corners without being given time to address the consequences become, quite reasonably, resentful.

The PM who understands this builds recovery time into the planning cycle rather than treating it as optional. After a period of sustained delivery pressure, space for refactoring, bug fixing, and technical investment is not an indulgence; it is the maintenance that keeps the engine running. Skipping it saves time in the short term and costs considerably more time in the medium term.

Burnout and a degraded codebase are not great KPIs for a successful quarter, however impressive the feature count looks.

The Bigger Picture: What Kind of PM Do You Want to Be?

I want to close with something that the six failure modes above have in common, because the pattern is worth naming explicitly.

Every one of them is a form of the PM prioritising their own comfort or convenience over the needs of the team. The PM who avoids learning technical concepts avoids the discomfort of revealing ignorance. The PM who forwards the email rather than explaining the pivot avoids the difficulty of an honest conversation. The PM who micromanages is managing their own anxiety rather than trusting the team. The PM who skips informal relationship-building is protecting their own time. The PM who assigns uninspiring work is optimising for roadmap coverage rather than team engagement. The PM who pushes for speed without building in recovery time is meeting their own delivery commitments on the team's behalf.

Seen in that light, the question "why is the PM seen as the idiot in the room?" has a fairly consistent answer: because the team has picked up, accurately, that the PM is not consistently putting their interests first.

The reversal of that dynamic requires something simpler than it might appear. It requires the PM to ask regularly, and genuinely, what the team needs to do their best work, and to make providing that a higher priority than protecting their own comfort.

No PM is perfect, and no team expects them to be. What teams respond to, consistently and over time, is the sincere and visible effort to be useful, honest, and present. That is not a standard that requires exceptional talent. It requires showing up, paying attention, and being willing to do the uncomfortable things when they are called for.

That, in the end, is what gets a PM out of the idiot seat and into the one they actually want to occupy.

A question worth sitting with: if you asked the engineers on your team to describe you to a new colleague, what do you think they would say?

The gap between the answer you hope for and the answer you suspect is probably the most honest indicator of where the work needs to happen.