Consider a product-minded individual contributor heading into a review after a crowded half year. The work was real, useful, and visible to the team, but their draft self-review still read like a task list. They had shipped a process change, helped unblock a launch, and improved a messy handoff with another function. A clearer explanation of that work could give a manager language to reuse in calibration and promotion discussions. That is where knowing what to say in a performance review changes the outcome.
The first draft sounded busy, not persuasive
The draft looked fine at first glance.
- Worked with cross-functional partners on launch readiness
- Improved team process documentation
- Helped resolve issues during rollout
- Supported teammates across multiple projects
None of those lines were false. The problem was that they gave no sense of ownership, judgment, scope, or result. A manager reading them would need to do the interpretation work themselves.
That is a common failure mode in performance reviews. You know the background, so your shorthand feels complete. The reader needs enough detail to understand what changed and why your part mattered.
The turning point was choosing one example and expanding it properly
Instead of trying to improve every bullet at once, they picked one accomplishment that had strong raw material.
The situation was a recurring handoff problem between planning and execution. Information arrived late, requirements changed in motion, and the downstream team lost time reconciling differences. This person did not own every part of the workflow, but they were close enough to see the pattern and credible enough to propose a fix.
Their original line said this:
Improved process documentation for a cross-functional workflow.
That line described activity, but it hid the useful parts. It did not say what was broken, what decision they made, how much ownership they took, or what happened after the change.
Here is what they changed in the writeup
They rewrote the example around four questions.
What problem was actually happening?
They replaced the generic phrase with a concrete statement. Inconsistent handoff information created rework and confusion across teams.
What did they personally do?
They named the parts they owned. They audited recent handoffs, found the repeated failure points, drafted a tighter intake structure, aligned on required fields with partner teams, and introduced a simple review step before work moved downstream.
What changed because of that work?
They added outcome detail. After the change, handoffs became easier to review, fewer items bounced back for clarification, and partner teams had a more predictable starting point. Even without a dramatic metric, the result was clear and believable.
What does this show about level?
They made the signal explicit. This was not just cleanup. It showed pattern recognition, initiative beyond assigned tasks, and influence across team boundaries without formal authority.
The stronger version answered what to say in a performance review
The revised paragraph read more like this:
I noticed that recurring gaps in our handoff process were slowing execution and creating avoidable clarification loops between teams. I reviewed recent examples, identified the information that was most often missing or inconsistent, and proposed a tighter intake structure with a lightweight review step before work moved forward. I partnered with adjacent stakeholders to align on what needed to be captured up front, then documented and rolled out the change. The result was a smoother handoff process with less back-and-forth and clearer starting context for the downstream team. This work mattered because it improved execution for multiple people, not just my own tasks, and showed I can spot system-level friction and reduce it.
This version worked better because it gave the manager something portable. They could repeat the example in a review discussion without needing extra translation.
What this one example teaches you
One well-built example does a lot of work in a performance review.
First, a strong review point needs the decision, the ownership, and the result.
Second, it shows that not every strong review point needs a dramatic launch or a large metric. Operational clarity, quality improvements, and reduced friction can all count when you explain them well.
Third, it shows why capture matters before review season. The revised paragraph was easier to write because the person had fragments of evidence from the time the work happened: meeting notes, stakeholder reactions, and a record of what changed in the process. A tool like ImpactLogr helps you keep those fragments in one place so they are easier to turn into review language later.
For a practical checklist of the evidence to save as you go, see this guide to what to document before your performance review.
How to use this approach in your own review
When you are deciding what to say in a performance review, start with one accomplishment and pressure-test it with these prompts:
- What was the actual problem?
- What did I decide, change, or drive?
- What part was mine?
- What changed afterward?
- Why does this matter at my level?
If your answer is still only a task summary, keep going. The useful material is usually one layer deeper than your first draft.
You do not need a polished paragraph every week. You need enough captured detail that future you can reconstruct the story without guessing. That can be a short note on the situation, your action, the visible result, and any proof worth saving. Just do not store sensitive internal documents or private customer details in a personal system.
Build better review language before the next cycle
A stronger self-review starts long before the form opens. If you want a simple place to collect work examples and turn them into clearer review talking points later, open an ImpactLogr account for your next review cycle.