🪞Giving and Receiving Feedback
The skill PMs use most often and practice least. Senior PMs make giving and receiving feedback a habit, not an event.
Engineers, designers, and stakeholders will tell you the unvarnished truth about your work — but only if you make it safe and easy to do so. PMs who don't seek feedback get blindsided by performance reviews and stall in their careers.
Feedback should be **specific, timely, and forward-looking.** Vague ('be more strategic'), late ('three months ago you...'), or backward-looking ('you should have...') feedback doesn't change behavior. Make giving and asking for feedback a weekly habit, not a quarterly event.
How to give feedback
SBI format. Situation, Behavior, Impact. "In yesterday's design review (situation), when you cut Maria off mid-explanation (behavior), the team got quieter for the rest of the meeting and we lost their input (impact)."
Three rules:
- Specific over vague. "Be more strategic" doesn't help. "In the OKR doc, the rationale section was missing — add it next time" does.
- Timely. Within 48 hours of the event. Six months later, it's a complaint, not feedback.
- Forward-looking. End with "next time, try X." Not just "you shouldn't have Y."
How to ask for feedback
Most people don't volunteer feedback unless explicitly asked. Make it easy:
- Specific ask. "What's one thing I could have done better in today's design review?" Better than "any feedback?"
- Receive without defending. Even if you disagree, say "thank you, let me think about that." Defensiveness shuts off the channel forever.
- Close the loop. "You told me X two weeks ago. Here's what I changed." Shows you took it seriously.
The feedback rhythm
Three cadences:
- Daily/weekly: Tactical feedback in the moment. "Hey, your write-up was really clear, want to flag what worked." Or "the metric definition was off — let's tighten next time."
- Monthly: 1:1 with each direct stakeholder (your EM, your designer, your skip). Ask: what's one thing I should keep doing? One thing to stop?
- Quarterly: Structured 360 — ask 5-8 peers for feedback. Aggregate themes. Make one change.
The hardest feedback to give
To senior people. Don't avoid it — frame as "I want to share something I observed; happy to be wrong." Most senior leaders crave it and rarely get it.
To peers in your power band. People avoid because of conflict aversion. The cost of avoiding it is much higher than the cost of giving it.
Receiving feedback you disagree with
Three steps:
- Don't defend in the moment. Listen, ask clarifying questions, thank them.
- Sit with it for 24 hours. Usually some part of it is true; you can see it once you've cooled down.
- Respond if needed. "I thought about your feedback. I agree with X, here's where I'd push back on Y. Can we discuss?"
Defensiveness kills the channel. Engagement strengthens it.
Real-world examples
Bridgewater's 'radical transparency' practice — including the 'baseball card' tool where every employee's feedback is visible — is extreme but instructive. Their data shows employees who get consistent specific feedback grow 2-3x faster. Most product orgs don't go this far but the principle holds.
Go deeper — recommended reading
Interview questions (1)
Q1Tell me about a piece of difficult feedback you received and what you did with it.behavioralmid▼
STAR.
Situation: My EM told me in our 1:1 that engineers had been complaining I was changing scope mid-sprint and making them feel like their estimates didn't matter.
Task: Hear it, validate, and change behavior.
Action: First reaction was defensive — 'the requests came from sales, not me.' I sat on it for 24 hrs. Then I looked at the last 8 sprints — there had been mid-sprint scope changes in 6 of them. Engineers were right.
Three changes: (1) I started declining mid-sprint scope changes from sales; if it was urgent, it went into the next sprint, never mid-sprint. (2) Weekly 1:1 with the tech lead — checking in on what was working and what wasn't. (3) I publicly named the change in the next sprint planning: 'I've heard the feedback. Here's how I'm changing how I work.'
Result: Two sprints later, the engineers spontaneously commented in retro that the rhythm felt better. Velocity went up 20% the next quarter. More importantly, the trust improved — engineers started bringing me harder problems because they knew I'd respect their constraints.
Reflection: The lesson: defensive in the moment, action within 48 hrs. Don't try to be perfect at receiving feedback — try to act on it.