Product Manager Performance Review Template (With a Competency Model)

What should a product manager performance review include?

A useful PM review answers one question for the person reading it: what are they doing well, and what exactly stands between them and the next level? Lenny Rachitsky's template in The Power of Performance Reviews is built around that second half. His test for choosing development areas is one line: "What is most holding the person back from the next level?" He also caps them at one or two, because "more than two makes it very hard to make meaningful progress on any."

The template below keeps that structure and adds a competency rating, so the development areas come from a model rather than from whatever was top of mind the week you wrote the review.

Section	What goes in it	Length
1. Role and level	Title, level, time in level, product area	1 line
2. Accomplishments	The biggest results of the period, with evidence	3 to 5 bullets
3. Strongest skill	The one thing they do best, and where to use it more	2 to 3 sentences
4. Narrative	How far they have come, how this period went, what is next	4 to 6 sentences
5. Competency rating	Each competency rated against their current level	1 table
6. Development areas	One or two, each with examples and a concrete suggestion	1 short paragraph each
7. Gap to next level	What operating at the next level would look like, and when you will review it	1 paragraph

Which competency model should a PM review use?

Pick one named model and use it for every PM on the team, every cycle. Ravi Mehta's model, set out in How To Become a Peak Product Manager, has 12 competencies grouped into four areas:

Area	Competencies
Product execution	Feature specification, product delivery, quality assurance
Customer insight	Fluency with data, voice of the customer, user experience design
Product strategy	Business outcome ownership, product vision and roadmapping, strategic impact
Influencing people	Stakeholder management, team leadership, managing up

In What's Your Shape?, Mehta suggests rating each competency on a three-point scale from "Needs Focus" to "On Track" to "Outperform", then plotting the result as a shape. The point of the shape is that nobody is strong everywhere. Mehta cites a McKinsey and Egon Zehnder survey of over 5,000 people that found leaders at the highest-performing companies were average or even deficient at many important leadership competencies, and draws the conclusion for teams: "Individuals should be spiky; teams should be well-rounded."

For a review, that changes what counts as a problem. A junior PM who outperforms on feature specification and needs focus on strategic impact is on a normal path. A senior PM with the same shape is not, because Mehta's model expects PMs to move towards strategy and influencing people as they grow.

What does the template look like?

Copy this into your review document and fill it in order. Sections 5 to 7 are where most of your writing time should go.

PRODUCT MANAGER PERFORMANCE REVIEW
Review period:            Reviewer:

1. ROLE AND LEVEL
   Title / level / time in level / product area

2. ACCOMPLISHMENTS (3 to 5)
   - Result, with the metric or evidence behind it
   - Best peer comments (anonymised)

3. STRONGEST SKILL
   What they do best, and where they could use it more

4. NARRATIVE (4 to 6 sentences)
   Where they started -> how this period went -> what comes next

5. COMPETENCY RATING (Needs focus / On track / Outperform, for current level)
   Product execution:   specification | delivery | quality assurance
   Customer insight:    data | voice of the customer | UX design
   Product strategy:    outcome ownership | vision and roadmap | strategic impact
   Influencing people:  stakeholders | team leadership | managing up

6. DEVELOPMENT AREAS (max 2)
   For each: the competency, two examples from this period,
   one concrete suggestion, what "good" would look like

7. GAP TO NEXT LEVEL
   Next level: 
   Competencies not yet at that level:
   What operating at that level would look like in their area:
   Review date:

How do you write the gap to next level section?

Most reviews fail here, because the section is written as advice ("be more strategic") instead of as a description of work. A useful gap section has four parts: the next level, the one or two competencies below that level, what operating at that level would look like in this PM's actual product area, and a date.

A worked example, with a hypothetical PM. Priya is a PM on the checkout team of a grocery delivery app, one year in level. Her accomplishments are strong: she shipped saved payment methods on schedule, and checkout errors dropped after her quality push. Her competency shape outperforms on product delivery and quality assurance, is on track on fluency with data and stakeholder management, and needs focus on product vision and roadmapping and on strategic impact.

A weak gap section says: "To reach senior PM, Priya needs to think more strategically." A useful one says:

Next level: senior PM. The gap is product vision and roadmapping. This half, the checkout roadmap was a list of requests from operations and finance, and Priya delivered them well. At senior level, she would bring her own view of where checkout should be in a year, backed by customer and basket data, and defend the trade-offs with operations and finance in the quarterly planning review. We will review progress at the midpoint of next half, using her next roadmap proposal as the evidence.

The second version tells Priya what to do, what evidence will count, and when. It also gives you something to point to in a promotion discussion six months later.

How do you gather evidence for a PM review without bias?

Start a month early. Rachitsky suggests agreeing 5 to 8 peer reviewers with the PM, then asking each one three questions: what the PM should start doing, continue doing, and stop doing, and why. Ask the PM for a self-review with their top accomplishments and the areas they want to develop.

Before the peer responses arrive, write down your own view: what they did well, what is holding them back, and the one or two development areas you expect. Rachitsky's reason is that this step reduces bias and keeps you from being swayed entirely by what peers say. For a PM, add hard evidence to the opinions: the metrics their area moved, the specs and decision records they wrote, and what customers said about what they shipped.

What goes wrong when heads of product run PM reviews?

The strongest objection to competency models is that they turn reviews into box-ticking: twelve ratings, each defensible, that add up to no clear message. That failure is real, and it happens when the rating table becomes the review instead of the evidence for it. Keep the narrative and the gap section as the parts the PM reads first; the table is there to show the pattern behind them.

Three other failures are common in product teams:

• Rating output instead of outcomes. A PM who shipped a lot is not automatically strong on business outcome ownership. Ask what changed for users and the business.
• Reviewing against your own shape. A head of product who came up through growth tends to mark down PMs whose strengths are in user experience or strategy. The competency model is the correction for that.
• Surprises. Nothing in section 6 or 7 should be new to the PM. If it is, the problem is the 1:1s during the period, not the review.

How does the review connect to promotion?

Promote PMs who are already operating at the next level, and use the gap section to make that visible over time. If each review names the gap and the next review shows it closing, the promotion case is already written by the time it reaches a calibration meeting. If the gap section changes every cycle, the PM has no stable target, and neither do you. For the PM's side of the same conversation, how to get promoted to senior PM covers what evidence to bring.

How can a new head of product learn to run reviews?

Performance reviews are usually the first management task a new product leader has no practice at. The Head of Product bootcamp lists building and leading product teams (hiring, leveling, coaching, feedback and performance) among its public learning topics, over 2 weeks with 4 live sessions and 8 self-paced microlessons in the Product Leadership Track. If you are new to the role, head of product vs product manager explains why the management side is usually the harder half, and the head of product first 90 days guide covers the people decisions that come before the first review cycle.

Builders Camp runs live and self-paced bootcamps in product management and AI product building. See the Head of Product bootcamp for the next cohort and the self-paced version.