The Four PM Annoyances
The four PM behaviours that quietly destroy engineering trust — and the fix for each
- Difficulty
- Easy
- Time to result
- ~weeks to results
- Steps
- 4
- Confidence
- 95%
Camille Fournier's diagnostic list of the four specific things product managers do that erode their relationship with engineers: hoarding credit, dismissing details, playing telephone, and hoarding ideas. Each has a concrete counter-move. The fourth is the most consequential — when engineers are shut out of the creative loop on the product, they find a creative outlet in the technology instead, and over-engineer.
Origin
Developed by Camille Fournier from ~20 years as an engineering leader (CTO at Rent the Runway, VP Technology at Goldman Sachs, Global Head of Engineering and Architecture at JP Morgan Chase, Head of Platform Engineering at Two Sigma), watching the PM-engineer relationship succeed and fail across companies of very different scales.
Core principles
- 01The PM is the front-facing person by default, so credit accrues to them unless they actively push it away.
- 02You do not have to understand every technical detail — but acting like details don't matter signals a lack of empathy for the work.
- 03Being a middleman occasionally is fine; being one habitually means you're losing information in translation.
- 04Creativity is conserved. Suppress an engineer's product voice and the creativity reappears as framework obsession and rewrites.
- 05The best PMs are not threatened by other people having ideas — they know engineers having ideas doesn't mean engineers can do the product job.
How to run it
- 1
Stop hoarding credit — give the mic away
In demos, launch announcements and exec reviews, deliberately hand the presenting to the engineers who did the work, especially when it was a big technical lift. Don't settle for a thank-you slide; let them speak.
Pro tip Fournier's tell for a good PM: they talk the least in the room and encourage other people to do the presenting.
Watch out A generic 'thanks to the team' at the end of your own presentation reads as credit-hoarding with a fig leaf.
- 2
Treat details as legitimate, even the ones you can't follow
When engineers go deep on something that seems small, stay patient and curious rather than redirecting to 'just tell me when it'll be done' or 'why is this taking so long'. Engineering done well IS the details.
Pro tip You are allowed to not understand a detail. You are not allowed to signal that it doesn't matter.
Watch out Some details genuinely won't matter to the product. Sit through them anyway — the cost of patience is far lower than the cost of appearing dismissive.
- 3
Kill the telephone game
Track how often you say 'let me get back to you'. If it's frequent, either the asker is aiming questions at the wrong level, or you need to connect them directly to the engineer. Put the right people in one room or one Slack thread instead of relaying answers you don't understand.
Pro tip Use a group setting (group meeting or a chat thread) rather than a 1:1 hand-off, so the filtering role isn't lost entirely.
Watch out Filtering is a real part of the job — connecting people directly costs engineers focus time. The goal is that relaying is occasional, not the default.
- 4
Share the idea space
Give engineers a real channel to propose product and customer ideas, and be honest that most won't ship. The point is that someone listens and takes them seriously. In exchange, help them appreciate what the product job actually involves — measurement, customer understanding, business framing.
Pro tip Watch for over-engineering as a symptom: obsessive framework debates and rewrite pushes are often displaced creative energy.
Watch out Don't overcorrect into abdication — engineers having good ideas does not mean they understand the whole product job.
In the wild
Fournier says she can reliably predict where she'll find engineers building things they shouldn't be — obsessing over the right framework or architecture that won't move product delivery. It's the places where their creativity and voice on the actual business or product have been quashed and ignored, so they take control of the one space they do own: the technology choices.
→ Rather than treating gold-plating as a discipline problem, she treats it as a diagnostic for a PM who has closed the creative loop — and fixes the loop.
The best PMs Fournier has worked with aren't threatened by a team full of smart people with ideas. They invest in relationships so engineers feel free to share ideas, while also making visible what product actually brings — how to measure an input, how to understand the customer, what makes a bet succeed commercially.
→ Engineers share ideas, accept that most won't go anywhere, and stop feeling ignored — because someone is genuinely listening.
Common mistakes
Being the permanent middle person
Relaying questions to engineers, half-understanding the answer, and carrying it back to the asker wastes everyone's time and loses signal in translation. Senior engineers find this especially maddening.
Owning every idea
PMs who want to originate every product idea and every detail push engineers' creativity into the codebase, where it shows up as unnecessary rearchitecture and framework churn.
Fixing credit with words instead of stage time
Saying thank you is not the same as stepping back and letting engineers announce and present their own work. The sore point is visibility, not gratitude.
Is it for you?
Best for
Product managers embedded with an engineering team who sense friction, low buy-in, or unexplained gold-plating and want a specific behavioural checklist rather than vague 'build trust' advice.
Not ideal for
Solo founders or one-person teams with no PM/engineering split, and situations where the real problem is strategic misalignment rather than working relationship.
From the transcript
“I find the best PMS are the ones that talk the least and encourage other people to do the presenting”
“when they just don't understand the details and act like they don't matter”
“the third is playing telephone anybody in a manager role can fall victim to this”
“I see Engineers start to over engineer things because Engineers are like well I need to take control of something”
From the episode
The things engineers are desperate for PMs to understand
Camille Fournier (author of “The Manager’s Path,” ex-CTO at