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

Ana Ruiz, Group PM, Plotwise

Overall rating: Below expectations

Theo, you brought strong execution discipline, clear communication, and dependable partnership to the team this year. However, our two primary goals were to increase weekly Timeline use and shorten the time new teams take to build their first plan. We made only modest progress on both:

• Weekly Timeline use: increased from 22% to 23%, against a goal of 30%.
• Time to first plan: decreased from 3.0 days to 2.6 days, against a goal of 1 day.

Those results are the basis for this rating. Your squad shipped 14 features, 12 on time, but delivery volume and timeliness did not translate into the customer outcomes we committed to achieve. Six of those features are used by fewer than 2% of teams. Low adoption does not automatically make a feature unsuccessful, but it does require us to establish what value it created and whether it justified the investment.

I also owe you an acknowledgment of my part in this. In Q3, you explicitly asked whether you were on track, and I told you yes, citing great velocity. That was misleading: I should have distinguished delivery performance from progress against your goals. Our 1:1s focused too heavily on delivery and stakeholder updates, and I did not address the stalled metrics. You should not be hearing this assessment for the first time in an annual review. That management failure is mine; it does not erase the outcome gap, but it matters to how we understand the year and move forward.

Strengths

Reliable execution and engineering partnership. You keep the team unblocked and provide clear specs. The engineering lead specifically highlighted both, along with your consistent participation in sprint reviews. Shipping 12 of 14 features on time reflects real delivery discipline.

Strong collaboration and responsiveness. Design describes you as great to work with, and Sales values your responsiveness. You create productive working relationships and follow through on commitments. Those strengths are important foundations for effective product leadership.

What to work on

Shift from managing delivery to managing outcomes. The roadmap needs a clearer connection to Timeline adoption and first-plan speed. For each meaningful investment, define the customer problem, expected metric movement, and how we will assess success after launch. When the metrics are not moving, bring that into our discussions early and recommend a change in approach.

Validate demand before committing engineering capacity. Design’s concern that we should have tested more, together with the low usage of several shipped features, points to a need for stronger discovery. Use prototypes, customer conversations, and lightweight experiments to test the riskiest assumptions before building.

Make prioritization trade-offs explicit. Five shipped features were Sales requests, including two for individual customers. Those requests may have legitimate business value, but responsiveness alone is not a sufficient reason to prioritize them. Assess their customer reach, strategic or commercial value, cost, and opportunity cost—and make clear when an exception is worth taking.

Goals for the next half

1. Increase weekly Timeline use from 23% to 27%. Identify the main adoption barriers, test proposed solutions, and prioritize the interventions with the strongest evidence.
2. Reduce time to first plan from 2.6 days to 1.8 days. Diagnose where new teams stall and measure whether each onboarding improvement reduces that friction.
3. Strengthen investment decisions. For every substantial roadmap item, document the problem, supporting evidence, intended outcome, and success measure before committing to build. Review results within six weeks of launch and decide whether to iterate, expand, or stop.

We will confirm metric definitions and tracking at the start of the half, then review progress monthly. I will give you explicit feedback on whether you are on track, help resolve prioritization conflicts, and avoid treating velocity as a substitute for impact.

You have a strong execution foundation. The next step is to apply that strength to fewer, better-supported bets that measurably improve customers’ experience.

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.