PM Peer Review: How to Write One That Actually Helps

You have six peer review forms open in different tabs. Three are for engineers. One is for a designer. One is for another PM. One is for a data analyst you worked with on a cross-team project last quarter. You work with each of them differently, and you're about to write some version of "great partner, always responsive, pleasure to work with" for all six.

That helps nobody. Not them, not their managers, and not the calibration committee that's going to skim your feedback and learn nothing from it.

Product managers sit at an unusual spot during review season. You're not reviewing someone who does the same job as you. You're reviewing people across functions, which means you see things their direct teammates don't. How an engineer handles changing requirements. Whether a designer pushes back when user research conflicts with a stakeholder request. How another PM navigates a priority conflict between two teams. That cross-functional perspective is rare. But only useful if you write it down in a way that's specific enough to matter.

Why PM peer feedback carries more weight than you think

When a manager walks into calibration, they're building a case for their direct report's rating. Peer feedback is one of the inputs they lean on, and cross-functional peer feedback is the input they trust most for a simple reason: it's harder to game.

Same-team peers often echo each other. If an engineering team thinks their tech lead is strong, all the peer reviews from that team will say roughly the same thing. But a PM's perspective on that tech lead comes from a different angle entirely. You saw how they responded when the requirements shifted mid-sprint. You noticed whether they flagged technical risks early or waited until the deadline to surface them. You know whether they communicated trade-offs clearly or just said "that's hard" without explaining what it would cost.

Calibration reviewers notice this kind of signal because it adds dimension. Research from Prodify Group on PM feedback practices recommends that every PM evaluation include input from at least one engineering lead, one to two designers, one to two engineers, and a PM peer. Those cross-functional voices aren't optional extras. They're the data points calibration committees use to validate whether a rating holds up outside the person's own team.

The problem is that most PMs waste this advantage. They write the same two sentences for everyone: some variation of "collaborative" and "strong communicator." That tells a calibration reviewer nothing they couldn't have guessed. Feedback that could apply to literally anyone on your team is a placeholder, not a peer review.

What makes PM peer feedback different from engineering peer feedback

When an engineer reviews another engineer, they can evaluate technical work directly. Code quality. Architecture decisions. How someone handled an incident. The reviewer and the reviewee share a common frame of reference.

PMs don't have that shared frame when reviewing engineers, designers, or data scientists. You're observing from the outside of their function. You can't evaluate whether their code was clean or their design system was well-structured. What you can evaluate is how they operated in the spaces between functions, and that's where the most important behavioral signal lives.

Think about what you actually notice as a PM that same-function peers don't.

You see how someone handles ambiguity. When requirements changed or priorities shifted, did they adapt or dig in? Did they ask clarifying questions, or did they build the wrong thing and blame the spec?

You see how someone communicates across the technical divide. Could they explain a constraint to a non-technical stakeholder? Did they translate design rationale into terms the engineering team could evaluate?

You see how someone responds to pushback. When you challenged a timeline or questioned a design direction, did they defend their position with evidence or just get defensive?

And you notice when someone takes ownership beyond their lane. The engineer who flagged a user experience problem even though it wasn't their domain. The designer who raised a data question that caught a flaw before it shipped.

Those are the observations calibration reviewers need, and only cross-functional partners can provide them.

How to structure a PM peer review that actually lands

The fastest way to write useful feedback is the Situation-Behavior-Impact pattern. Coda's guide to PM feedback recommends it because it keeps feedback grounded in what you actually observed, not what you assumed about someone's intent.

Start with the situation (when and where this happened), then describe the behavior (the specific, observable action the person took), then explain the impact (what resulted for the team, project, or outcome).

Compare these two versions of the same feedback for an engineer:

Weak:

"Alex is a great engineer and easy to work with."

Stronger:

"During the Q3 payments migration, the original scope grew by 40% after we discovered new compliance requirements. Alex proactively mapped out which components were affected before I asked, flagged two dependencies that would have caused a two-week delay if caught later, and presented the options to the team with clear trade-off analysis. That saved us at least a sprint and kept the launch on track."

The second version gives Alex's manager a concrete story to bring into calibration. It shows initiative, technical judgment, and communication. The first version tells the manager nothing. If you want more side-by-side comparisons like this, the peer review examples collection covers a range of roles and scenarios.

Writing reviews for different roles

Your feedback should reflect what you actually observe, and that changes depending on the person's function.

For an engineer on your team

Focus on how they handle the messy middle of product development. You see the full lifecycle, not just the code review, which gives you a perspective their engineering peers can't match.

Ask yourself:

• When the spec was ambiguous or incomplete, did they surface questions or make assumptions?
• Did they flag risks and trade-offs early, or did problems only emerge at the deadline?
• How did they communicate progress and blockers? Did you have to chase them, or did they keep you informed?
• Did they push back on scope with good reasoning, or just accept everything?

For a designer you collaborate with

PMs and designers share the closest working relationship on most product teams. You see how they navigate the tension between user needs, business goals, and engineering constraints, which makes your perspective on their work especially useful in calibration.

Think about:

• Did they ground their design decisions in user research, or did they lead with personal preference?
• How did they respond when the business need conflicted with the ideal user experience?
• When engineering pushed back on feasibility, did they adapt creatively or just hand over a simpler version?
• Did they communicate design rationale in terms the full team could evaluate, or did they speak only to other designers?

For another PM

Reviewing a PM peer is the hardest one because you're evaluating someone who does the same job as you. The temptation to compare or compete is real. Resist it. Focus on what you observed firsthand.

The things worth writing about:

• How did they handle priority conflicts between teams? Did they facilitate a real decision, or did they avoid the conflict?
• Were their product decisions grounded in evidence, or did they lean on opinion and seniority?
• How did they communicate up and across? Was leadership well-informed, or were there surprises?
• Did they say no to things that didn't matter, or did they try to do everything?

The mistakes PMs make in peer reviews

The most common one is writing about the project instead of the person. "The payments launch went well and the team hit all milestones." That's a project update. It doesn't tell anyone what the individual contributed. Calibration reviewers skip this kind of feedback entirely.

A related trap: confusing "I liked working with them" for performance. Someone can be pleasant and still underperform. Someone can be blunt and be the highest-performing person on the team. Your job is to describe what they did and what resulted, not whether you enjoyed the collaboration.

Many PMs also go vague to avoid conflict. If someone struggled with something, writing "could improve communication" is so generic it's invisible. Be specific instead: "During the API redesign, there were two weeks where the engineering team didn't know the requirements had changed because the updates were only shared in a PM doc, not in the team's Slack channel. Once we moved to daily standups, the information gap closed." That gives the person something concrete to change.

Then there's the peer review that's all praise and no growth areas. Calibration committees distrust it. Harvard Business Review research found that some feedback recipients consistently receive vaguer, less actionable feedback, which can stall their development. If you care about helping someone, include at least one specific area where they could improve.

One more: writing different quality feedback based on seniority. The junior engineer deserves the same specificity as the senior staff designer. Calibration committees read all of it, and your feedback quality reflects on your own judgment.

A quick template for each review

If you're staring at an empty form, use this structure. It works for any function.

Start with one paragraph on what they did well. Name a specific situation. Describe the behavior. Explain the impact. Don't just say "strong collaborator." Show it.

Then write one paragraph on a pattern you observed. This is the most useful part of a PM's peer review because you see patterns across a full product cycle. Did they consistently surface risks early? Did they regularly translate technical constraints into business terms? Name the pattern, give an example, explain why it matters.

Close with one paragraph on where they can grow. Be specific and generous. You're not writing a performance warning. You're telling someone what would make them even more effective. Frame it as an observation, not a judgment: "One area I think would make a big difference is..." followed by a concrete behavior change.

Those three paragraphs should take you 10 to 15 minutes per person, and if you need to move even faster, the 15-minute peer review guide breaks down a tighter workflow. That's more useful than 90% of the peer reviews submitted during review season.

---

Your peer review travels into calibration, gets read by someone who has never worked with your colleague, and influences how they get rated. As a PM, you have a vantage point that nobody else on the review list has. You see across functions. You see how people operate under ambiguity, pressure, and changing priorities.

Write that down. Be specific. Be honest. That's what actually helps.

CareerClimb helps you log wins and observations throughout the review period so you're never reconstructing six months of feedback from memory the night before reviews are due. Download CareerClimb