Write a performance review

Annual Review: Theo Brandt

Reviewer: Ana Ruiz, Group PM Period: Full year

Summary

Theo, you run a reliable delivery team. Your squad shipped 14 features, 12 on time, and engineering and sales both value working with you. This year's problem is that shipping didn't move the two goals we set. Timeline weekly use went from 22% to 23%, against a target of 30%. Time to first plan dropped from 3.0 days to 2.6, against a target of 1 day. We measured the work by output, and the outcomes didn't follow.

Results Against Goals

Goal 1: Raise weekly Timeline use from 22% to 30%. Result: 23%. Missed by 7 points. Most of the year's shipping was not aimed at this metric, and the adoption plan never got the attention it needed.

Goal 2: Cut time to first plan from 3 days to 1. Result: 2.6 days. Real progress, a 13% improvement, but well short of target. Some of the gain likely came from onboarding changes that were not in the roadmap.

Delivery: 12 of 14 features shipped on time. This is strong and I want to be clear about it.

Adoption of what shipped: Six of the 14 features are used by fewer than 2% of teams. Five of those six came from Sales requests, and two were built for a single customer. Your designer flagged three shipped features that nobody seems to use. I think they're right.

Strengths

• Reliability. You keep the team unblocked and hit sprint reviews. Engineering trusts your planning.
• Clear specs. Engineering's feedback on your specs is consistent and specific.
• Stakeholder responsiveness. Sales knows you take their requests seriously and act on them.
• Communication with the team. The designer describes you as good to work with, which matters in a squad where tradeoffs get hard.

What to Work On

Validate before you build. The designer's point is the most important feedback in this review. Three shipped features have no evident users, and you had the means to check before building them. Before you commit to a feature, define the usage metric it has to move and run a cheap test to check the need. If you can't name the metric, don't build it yet.

Connect requests to goals. Sales requests are valuable, but five of your last shipped features came from one channel, and two were for single customers. Treat a request as a hypothesis about usage, not a commitment. Ask how many teams the request affects and how it connects to goal 1 or goal 2. Say no, or propose a different version, when the answer is weak.

Treat goals as the status report. Shipping on time is a good sign, but it doesn't tell us whether goals are on track. Report the goal metric first in every update, even when the number is bad.

Rating

Below Expectations.

This rating is based on the two goals you were given. Both moved in the right direction, but neither reached its target, and the delivered features did little to move them. Calibration requires written evidence for this rating, and the evidence is above: the goal results, the usage data on shipped features, and the designer's observation about untested builds.

Your delivery and team relationships are real strengths and are not part of the rating decision. The rating reflects impact on the goals. I'm also not ignoring that the gap was harder to see than it should have been. I'll address my part in the next section.

Where I Fell Short

In the Q3 1:1, you asked directly whether you were on track. I said yes and pointed to your velocity. I never looked at whether the goal metrics were moving, and they weren't. That was my failure, not yours. You asked the right question, and I gave you a reassuring answer based on the wrong evidence. If I had given you the real numbers in Q3, you would have had a full quarter to change course. I'm sorry for that. I'll change how I run goal check-ins, starting with the next half.

Goals for the Next Half

1. Timeline weekly use: 23% to 28%. Within the first six weeks, interview 10 teams that tried Timeline and stopped using it, and bring me a written summary of why. Then propose and run one adoption experiment, with a success threshold set before launch. I'll review the findings with you at the six-week mark.

2. Time to first plan: 2.6 days to 1.5 days. Identify the two or three steps in onboarding that take the most time for new teams, and ship changes against those steps. Report the number every two weeks.

3. Usage gate on all new features. Every feature in the roadmap must have a named usage metric and a pre-build validation step, agreed with the designer. Features without both don't enter the build queue. We'll review the first three together.

4. Sales request triage. Set up a simple process with Sales. Requests are scored by how many teams they affect and how they tie to the goals. Single-customer requests need a specific justification or a different solution. I'll help with the first conversation with the Sales lead.

Theo, you have the delivery discipline to do this. What you need is to point that discipline at the outcomes we set out to change. Let's start the first six weeks with the Timeline interviews.

Theo Brandt — Annual Review

Manager: Ana Ruiz, Group PM, Plotwise Overall rating: Below expectations

Theo, you brought reliability, clarity, and strong collaboration to the squad this year. You kept delivery moving and earned positive feedback from Engineering, Design, and Sales. However, the product outcomes we committed to were substantially below target. This rating reflects that gap—not a lack of effort or commitment.

I also owe you an acknowledgment: I did not give you clear feedback about that gap during the year. When you asked in Q3 whether you were on track, I said, “Yes, great velocity.” That answer confused delivery progress with goal progress and gave you the wrong signal. We should have discussed the metrics and changed course together. You should not be hearing this assessment for the first time in an annual review.

Strengths

Reliable execution. Your squad shipped 14 features, 12 on time. Your engineering lead highlighted your clear specs, consistent participation in sprint reviews, and ability to keep the team unblocked. These are important strengths that make the squad more effective.

Strong working relationships. Design described you as great to work with, and Sales praised your responsiveness. You listen to partners and follow through on commitments. That trust is an asset to preserve as you become more selective about what the squad builds.

What to work on

Own outcomes, not just delivery. Your two annual goals were: - Increase weekly Timeline usage from 22% to 30%. Actual usage reached 23%. - Reduce time to first plan from 3.0 days to 1.0 day. Actual time reached 2.6 days.

Both metrics improved, but neither came close to its target. For a PM, successful delivery is a means to improving customer outcomes, not the end measure of success. This substantial shortfall is the primary evidence for the Below expectations rating.

Strengthen prioritization and validation. Six of the 14 shipped features are used by fewer than 2% of teams. Low adoption does not automatically mean a feature lacks value, but it requires us to examine whether the investment was justified. Five features came from Sales requests, including two for individual customers. Those requests may have legitimate business value; they still need an explicit rationale relative to our broader goals.

Design’s feedback that we should have tested more before building reinforces this development area. Before committing engineering time, establish the customer problem, intended audience, evidence of demand, and expected impact. After launch, check whether that impact materialized.

Make tradeoffs visible. Being responsive should not mean accepting every request. Bring partners a clear recommendation: what we should build, what we should decline or defer, and why.

Goals for the next half

1. Improve the two core outcomes. Increase weekly Timeline usage from 23% to 26% and reduce time to first plan from 2.6 days to 2.0 days, using consistent measurement definitions. In the first month, identify the biggest barriers and establish monthly checkpoints toward those targets.

1. Validate before committing. For every substantial roadmap investment, document the problem, target users, supporting evidence, success metric, and opportunity cost. Test the riskiest assumption before building, or explicitly document why an exception is warranted.

1. Close the post-launch learning loop. Review each substantial release within six weeks against its success metric. Audit the six low-adoption features and recommend whether to improve, maintain, or retire each, accounting for customer and business value.

1. Lead outcome-based prioritization. Bring a monthly roadmap recommendation grounded in metric progress and customer evidence, including explicit tradeoffs for stakeholder requests.

My commitment is to make our 1:1s outcome-focused, review these checkpoints with you, and give direct feedback when progress is off track. Your execution strengths provide a solid foundation. The next step is applying that discipline to choosing and validating work that produces measurable customer value.

Annual Performance Review Employee: Theo Brandt, Product Manager Manager: Ana Ruiz, Group Product Manager Review Period: FY Annual Review Overall Rating: Meets Expectations

---

Performance Summary & Overall Rating

Overall Rating: Meets Expectations

Theo has had a productive year characterized by high operational output, exceptional execution rigor, and strong squad leadership. He shipped 14 features—12 of them on time—and built great trust across engineering and sales.

However, our primary product goals were tied to outcome metrics rather than feature velocity: 1. Weekly Timeline View Adoption: Target 30% | Actual: 23% (baseline 22%) 2. Time to First Plan: Target 1.0 day | Actual: 2.6 days (baseline 3.0 days)

While the delivery machine Theo built is top-tier, the strategic impact of what was delivered fell short of our targets. Six of the 14 features shipped are used by fewer than 2% of teams, reflecting an emphasis on shipping volume and ad-hoc requests over high-leverage product discovery.

I also want to acknowledge my own role here: when you asked in Q3 whether you were on track, I pointed to your velocity and said yes, rather than re-anchoring our conversations on our metric shortfalls. Your execution on what was put in front of you was excellent; our focus now must pivot from output to measurable impact.

---

Strengths

• Execution Rigor and Delivery Reliability: Theo is an exceptional delivery PM. Shipping 14 features with an 85% on-time delivery rate is a testament to his clarity and organizational discipline. As his Engineering Lead noted, “Theo keeps the team unblocked, his specs are clear, and he never misses a sprint review.” His squad runs with rhythm and confidence.
• Stakeholder Responsiveness and Partnership: Theo is highly collaborative and service-oriented. Sales commended him as “very responsive,” appreciating that he delivered five key requests to support revenue efforts.
• Squad Morale and Clarity: The squad feels supported and clear on day-to-day priorities. Theo shields the team from ambiguity during delivery sprints.

---

Areas for Growth

• Shift from Output to Outcomes: High velocity without metric movement does not move Plotwise forward. Five of the shipped features were sales requests (two serving only a single customer), and nearly half the year’s releases see under 2% usage. Theo must practice saying "not now" to low-leverage requests to protect squad capacity for the core metrics we need to move.
• Pre-Build Discovery and Validation: As our product designer noted, “I wish we’d tested more before building; we shipped three things I’m not sure anyone uses.” Theo should partner earlier with design and analytics to de-risk value and usability before committing engineering time. Building prototypes and running customer problem interviews will prevent spending sprint cycles on features that fail to achieve adoption.
• Metric Ownership in Day-to-Day Decisions: Moving forward, every feature spec should define a clear hypothesis, adoption target, and post-launch metric check. Our 1:1s will also reflect this shift—prioritizing metric movement over sprint status.

---

Goals for the Next Half (H1)

1. Drive Timeline Weekly Adoption from 23% to 28% * Success Measure: Rather than building net-new surfaces, focus on instrumenting workflows, user onboarding, and targeted iterations on the current Timeline experience to increase recurring weekly team usage. 2. Reduce New Team Time-to-First-Plan from 2.6 Days to 1.5 Days * Success Measure: Conduct discovery sessions with recently onboarded teams, identify drop-off bottlenecks, and ship validated onboarding improvements with design. 3. Establish a Customer Discovery & Validation Gate * Success Measure: Implement a lightweight validation process for all incoming feature ideas (especially commercial requests). No feature will be queued for full development without documented user validation and an estimated TAM/adoption threshold (>5% of active teams or explicit strategic tier-1 value). 4. Post-Launch Adoption Audits * Success Measure: Conduct 30- and 60-day post-launch usage reviews for all new releases, tracking engagement against targets and sunsetting or iterating on low-performing functionality.