Koru
Performance Review Goals Examples for Knowledge Workers
Performance review goals examples you can adapt for product, engineering, operations, support, marketing, and individual contributor growth, with a worksheet for making goals specific.
Good performance review goals say what will change, how you will know, and what evidence you will bring back later. Weak goals sound like intentions: "communicate better," "be more strategic," "take ownership." Strong goals turn those intentions into observable work.
Use this structure:
Goal formula
Structure
Outcome + behavior + evidence + review date
Example
"By the end of Q3, I will reduce repeated launch handoff questions by creating one owner-approved checklist, testing it on two launches, and bringing the before/after examples to my next review."
Performance review goals examples by type
Use these examples as starting points. Replace the bracketed parts with your actual work, team, and review cycle.
| Goal type | Weak goal | Stronger goal |
|---|---|---|
| Delivery | "Deliver projects on time." | "For the next two launches, I will define owners, risks, and sign-off dates in week one so the team can spot timeline issues before the final review." |
| Communication | "Improve communication." | "I will send a weekly written update for [project], including decisions made, open risks, and the next blocker to resolve." |
| Ownership | "Take more ownership." | "I will own [process/workstream] from planning through retrospective, and document what changed, what slipped, and what I would repeat." |
| Collaboration | "Work better cross-functionally." | "I will run one shared triage with [team] before each milestone so decisions are captured once instead of repeated across channels." |
| Quality | "Improve quality." | "I will identify the top recurring issue in [workflow], test one prevention step, and bring before/after examples to the review." |
| Growth | "Become more strategic." | "Before taking on [larger scope], I will write a short decision note for each major tradeoff and ask my manager to review one note per month." |
| Leadership | "Show leadership." | "I will mentor [person/group] through [specific task], agree on a measurable outcome, and collect feedback on what helped." |
| Customer impact | "Be more customer-focused." | "I will review [number] customer conversations or tickets each month and turn the repeated issue into one product, support, or process recommendation." |
The pattern is not complicated. A goal becomes review-ready when someone can ask, "Did this happen?" and you can answer with evidence.
A worksheet for turning vague goals into review-ready goals
Before you accept a goal, pressure-test it.
| Question | Your answer |
|---|---|
| What should be different by the next review? | A process, skill, decision quality, customer issue, delivery rhythm, team habit |
| What behavior will you practice? | Write updates, escalate earlier, clarify owners, run retros, ask for feedback, document decisions |
| What evidence will prove progress? | Before/after example, shipped artifact, stakeholder feedback, quality signal, decision note, metric |
| What support do you need? | Manager review, stakeholder access, clearer scope, data, training, pairing |
| When will you check progress? | Monthly 1:1, midpoint review, project retrospective, end-of-quarter review |
If you cannot answer the evidence row, the goal is probably too vague.
Examples for common knowledge-worker goals
If your goal is better communication
Too vague
"I want to improve communication with stakeholders."
Review-ready
"For the next product launch, I will send a Friday update that names decisions made, risks, and next steps. At the retrospective, I will ask Product, Support, and Sales whether the updates reduced repeated questions."
If your goal is more ownership
Too vague
"I want to take more ownership of projects."
Review-ready
"I will own the onboarding checklist refresh from kickoff to retrospective. That means naming the current failure points, getting sign-off from Legal and Support, testing the checklist on the next launch, and documenting what changed."
If your goal is stronger prioritization
Too vague
"I want to be more strategic with priorities."
Review-ready
"For each major Q3 project decision, I will write a short tradeoff note: options considered, recommendation, risk, and what would make me revisit the decision. I will review one note per month with my manager."
If your goal is leadership without being a manager
Too vague
"I want to develop leadership skills."
Review-ready
"I will lead the support handoff improvement for the beta launch. My goal is to align Product, Support, and Implementation on one checklist, then collect feedback from each team after the first two customer handoffs."
If your goal is quality improvement
Too vague
"I want to improve quality in my work."
Review-ready
"I will track the top repeated issue in the reporting workflow for four weeks, test one prevention step, and bring one before/after example to the Q3 review."
These examples are intentionally plain. Performance review goals do not need to sound impressive. They need to survive contact with real work.
Goal examples by role
Product
"By the next roadmap review, I will document the top three customer problems behind [feature request] and separate evidence from opinion in the proposal."
Engineering
"For the next platform project, I will write the risk section before build work starts and review it halfway through the project."
Customer success
"I will turn the most repeated onboarding issue into a revised handoff note and test it with the next five accounts."
Operations
"I will reduce manual review in [workflow] by documenting the current steps, removing one duplicate approval, and tracking the exception cases."
Marketing
"For the next campaign, I will connect each content asset to one customer question and review which questions produced qualified conversations."
People or recruiting
"I will create a clearer interview feedback template for [role] and review whether hiring managers submit more specific evidence after two hiring cycles."
What to avoid in performance review goals
Some goals fail because they are too broad. Others fail because they depend on things you do not control.
| Avoid | Why it fails | Better |
|---|---|---|
| "Get promoted." | It is an outcome you influence, not fully control. | "Build evidence for the next-level scope by owning [project] and reviewing gaps with my manager monthly." |
| "Improve stakeholder management." | No observable behavior. | "Create one shared decision log for [project] and confirm open risks in the weekly update." |
| "Be more proactive." | Too easy to interpret differently later. | "Escalate risks within 48 hours of identifying a blocked dependency." |
| "Develop executive presence." | Vague and often loaded with bias. | "Practice presenting tradeoffs clearly by writing a one-page recommendation before leadership reviews." |
| "Work faster." | Can encourage shortcuts. | "Reduce rework in [process] by clarifying requirements before build starts." |
How to track goal evidence during the cycle
Once the goal is written, create a small evidence trail. You do not need a formal document. You need a few dated notes that answer: what happened, what changed, and what did I learn?
- 01
Write the goal in observable language
Use the outcome + behavior + evidence + review date structure. If a manager gave you a vague goal, translate it before you start.
- 02
Capture one note when evidence appears
Save the project decision, customer comment, before/after example, metric, or stakeholder feedback while it is still fresh.
- 03
Review it before the midpoint
Do not wait for the final review. Bring one example to a 1:1 and ask, "Is this the kind of progress you meant?"
Where Koru fits
Koru's point of view is simple: a goal is only useful if you can later show what happened around it.
For example, this weekly note:
Sent the first launch update using the new format: decisions, risks, next steps. Support replied with fewer follow-up questions than usual, but Sales still asked about customer messaging in a separate thread. Need to add a "customer-facing answer" line next week.
can become this review sentence:
Review-ready goal update
"I improved the launch update format by separating decisions, risks, next steps, and customer-facing answers. After the first update exposed a gap for Sales, I added that section and used the format for the next two launches."
That is more useful than "I communicated better." It gives the goal a trail.
Related reading
Comparison
Notion Career Journal Template vs Koru
Compare a Notion career journal template with Koru for career tracking, brag documents, STAR stories, and interview preparation.
Comparison
Koru vs Spreadsheets for Career Tracking
Compare Koru with Google Sheets and Excel for tracking career achievements. Learn why free spreadsheets often fail for career journaling and what makes purpose-built tools stick.
Career Development
Best Career Journal Apps in 2026
Compare the top career journaling apps for tracking achievements, preparing for interviews, and building your professional narrative. Tested and reviewed by career development experts.
Professional Development
Best Achievement Tracking Tools in 2026
Compare the best tools for tracking work accomplishments, building brag documents, and preparing for performance reviews. Reviews include AI-powered trackers and traditional methods.