Write a performance review

Theo,

You bring strong execution and partnership to the team. The engineering lead called out that you keep work unblocked, write clear specs, and consistently show up for sprint reviews. Your squad shipped 14 features, with 12 delivered on time, and Sales described you as very responsive. Those are meaningful strengths.

Overall rating: Below expectations

This rating reflects the gap between the outcomes we set and the outcomes delivered. Timeline weekly use increased from 22% to 23%, against a goal of 30%. Time to first plan improved from 3.0 days to 2.6, against a goal of 1 day. Delivery was strong, but the intended customer outcomes moved only modestly.

There is also a signal to examine in the shipped work: six of the 14 features are used by fewer than 2% of teams. Five were Sales requests, including two for a single customer each. Low usage does not automatically mean a feature was the wrong investment—some work serves a specific strategic need—but we need clearer evidence and rationale for those choices. Your designer also wished we had tested more before building, and questioned whether three shipped items were useful. Taken together, this points to an opportunity to strengthen discovery, prioritization, and post-launch learning—not simply to ship more.

I also need to own a miss on my part. In our Q3 1:1, you asked whether you were on track, and I told you yes based on velocity. I should have discussed the goal metrics and the gap then. I didn’t, and that deprived you of a timely chance to adjust. I’m sorry. Going forward, I’ll make our 1:1s include progress against outcomes, not just delivery and stakeholder updates.

What to work on

• Start with the user problem and intended outcome; use research and testing to check the problem and proposed solution before committing to build.
• Balance stakeholder responsiveness with product judgment. For Sales requests, make the target customer, broader strategic value, and trade-offs explicit.
• Define success measures before launch, then review adoption and learn from the results. Treat low usage as a prompt to investigate, not as a verdict by itself.

Goals for the next half

1. Raise Timeline weekly use from 23% to 26% by the end of the half. Identify the biggest adoption barriers and review usage trends regularly.
2. Reduce time to first plan from 2.6 days to 2.0 days. Instrument the activation journey, find the main points of friction, and prioritize improvements against them.
3. For each substantial feature bet, document the target user, problem evidence, expected outcome, and success measure before development. Validate larger bets with target teams before building, and review adoption after launch so we can iterate or change course.

I believe your execution strengths give you a solid base for this next step: making sure the team’s delivery translates into measurable customer value.

Annual Review: Theo Brandt

Prepared by: Ana Ruiz, Group PM Overall rating: Meets expectations

Theo, I want this review to be direct, because you deserve a clear picture. I also need to own a mistake of mine, which I cover below.

Results against your goals

Neither goal was met. Time to first plan improved by about 13%, which is real progress but a small fraction of the gap. Timeline usage was essentially flat.

Strengths

Delivery and team health. Your squad shipped 14 features, 12 on time. Your engineering lead says you keep the team unblocked, write clear specs, and never miss a sprint review. That reliability is hard to build, and the team trusts you.

Collaboration. Your designer called you "great to work with." Sales called you "very responsive." You treat partners as partners, and that is a real asset.

Responsiveness to stakeholders. You moved quickly on requests and kept people informed.

What to work on

1. Connecting what you ship to the outcomes you own. Your goals were about Timeline adoption and onboarding speed. Most of the year's output didn't aim at either. Six of the 14 shipped features are used by fewer than 2% of teams. Five of those six were Sales requests, and two of those were built for a single customer each. Responsiveness is a strength, but here it substituted for prioritization. Saying yes to five Sales asks used capacity that could have gone toward your goals.

2. Validating before building. Your designer said, "I wish we'd tested more before building; we shipped three things I'm not sure anyone uses." I agree. Moving fast on unvalidated work produces output, not impact. Fewer, better-tested bets would serve you and the team better.

3. Using data to drive decisions. Our 1:1s focused on delivery and stakeholder updates, not on whether your metrics were moving. Part of your job is to look at usage numbers regularly and change course when they don't move. I'd like you to make that a habit.

Where I fell short

In your Q3 1:1 you asked whether you were on track for your goals. I told you yes, citing great velocity. That wasn't accurate. Velocity was great, but the goal metrics weren't moving, and I never raised it. You asked the right question and got a misleading answer. I should have flagged this months earlier, when you had time to change course. Some of this outcome is on me, and it's a main reason I'm rating you Meets rather than Below expectations.

Rating rationale

Meets expectations reflects strong execution and collaboration, weighed against two missed outcome goals and a significant share of shipped work with minimal adoption. Without the missing mid-year feedback, I'd have had a harder conversation with you about the lower end of this rating. I don't see evidence for Exceeds, and I think the evidence supports Meets rather than Below, given partial progress on onboarding and the feedback gap on my side. To be clear, this is a solid-but-not-yet-sufficient year on outcomes, and the next half needs to show a shift.

Goals for the next half

1. Onboarding: Reduce time to first plan from 2.6 days to 1.8 days. Identify the two or three biggest drop-off points in the first-plan flow within the first month, and bring me a proposal for addressing them.
2. Timeline adoption: Raise weekly Timeline usage from 23% to 27%. Start with research into why teams who try Timeline don't return, and share findings with me by the end of month one.
3. Validation before build: Every feature above a small-effort threshold needs a written success metric and some evidence of demand (user tests, prototype feedback, or data) before engineering starts. Requests from a single customer need a case for broader value.
4. Post-launch review: Check usage of each shipped feature 60 days after launch and report the results to me. If something is underperforming, tell me what you'll do about it.
5. Sales partnership: Work with Sales on a lightweight way to evaluate requests so that "yes" is reserved for asks tied to our goals or to broad demand, and "not now" comes with a clear reason.

How we'll work together

We'll spend the first part of every 1:1 on your goal metrics, not just delivery. I'll tell you plainly where you stand each quarter, including when the news is uncomfortable. If you disagree with anything here, I want to hear it. I'd also like to hear what support would help most.

You've built a team that executes well and trusts you. The next step is pointing that capability at the metrics that matter. I'm confident you can do it.

Ana

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.