Understanding OKRs: everyday examples that measure real progress
“Launch the new onboarding guide” sounds like a clear goal. But a team could publish every page and still leave new colleagues unable to set up their development environment. Finishing the work and improving the experience are different things to measure.
Objectives and Key Results, or OKRs, connect a desired change with evidence of progress. An objective describes the change you want. Key results describe what you will measure by an agreed date. Initiatives are the activities you try to achieve it. Separating those three parts makes planning more useful.
What belongs in an OKR?
An objective could be “Help new starters become confident with the development setup”. “Write a guide” is an initiative. “Increase successful independent setup from six of ten starters to nine of ten” could be a key result, provided the team defines the task and collects comparable evidence.
Google’s re:Work guide explains the distinction between outcomes and a shared task list. It is preserved guidance originally published in 2016, not evidence about adoption in 2026. The examples below are fictional exercises you can adapt.
Two everyday worked examples
Learning a coding skill
Objective: Become able to build and explain a small accessible form by the end of a six-week practice period.
Possible key results are: pass six agreed behaviour checks on a form you build; explain validation, submission and error handling without reading a generated answer; and complete two unfamiliar change requests with no more than one hint per request. Agree how those last two results will be observed before starting.
The checks might cover a labelled email input, keyboard access, required fields, a useful error message, valid submission and visible confirmation. Keep the test cases written down so “works” has a stable meaning.
Watching tutorials and completing exercises are initiatives. They can help you get there, but hours watched do not demonstrate the outcome. This example uses practical completion criteria instead of pretending every learning goal needs a percentage.
Improving a booking journey
Objective: Make it easier for customers to complete a booking during the next quarter.
Imagine a fictional service where 400 of 1,000 eligible booking attempts succeed, a 40% completion rate. A proposed key result is to reach 55% by quarter end, using the same event definitions and excluding internal test traffic throughout.
A second result could reduce booking-related support contacts from 20 to 12 per 100 completed bookings. A third could improve an agreed usability task from five of eight representative participants completing it unaided to seven of eight. Small usability sessions offer diagnostic evidence, not a reliable estimate of the whole population.
Possible initiatives include clearer availability information, fewer repeated fields and better error recovery. Test the assumptions before committing to a large rebuild. Keep a guardrail, such as no increase in cancellation rate, to catch improvements that simply move the difficulty further along the journey.
Avoid the AI adoption trap
“Get everyone to use the AI assistant” measures adoption of a tool. It does not establish whether the tool helps anyone finish their work. For an AI drafting pilot, consider a defined outcome such as reducing the median time to produce a review-ready handover while meeting an agreed factual quality standard.
Record the baseline, include correction and review time, and count failed or abandoned attempts. Agree a quality check for unsupported statements and missing decisions. Faster drafts with more unnoticed errors should not count as an improvement. These are measurement suggestions, not claims that AI will save time.
Write results you can interpret
Define the measure before the target
Purpose: Make the result understandable to someone outside the team.
For each key result, record the baseline, target, deadline, data source, calculation and person responsible for updating it. For a rate, specify both numerator and denominator. If the baseline is unknown, first establish it and then agree a target rather than inventing a starting number.
Check whether the team can influence the result and which dependencies need help from elsewhere. Name any trade-off that must remain acceptable, such as accessibility, support workload or service reliability. A target that rewards excluding difficult users needs redesigning.
Hold a short weekly check-in
Purpose: Use evidence to decide what to change next.
Ask what moved, what the evidence suggests, what remains uncertain and which initiative to continue, change or stop. A result may take time to appear, so include useful observations without relabelling activity as success.
If the context changes, record the original target and the reason for a revision. Quietly lowering it destroys the comparison. Agree in advance whether a goal is a delivery commitment or an exploratory stretch goal. A 70% score is not a universal definition of success, and safety or essential service commitments should not be treated casually as stretch targets.
Try it with one goal
Write one sentence beginning “By the end of this period, people will be able to…”. Add two or three pieces of evidence that would show that change. List possible activities separately. Then ask: could every activity finish while the objective remained unmet? If yes, you have found a useful distinction to carry into planning.
Sources and review
Reviewed 19 October 2026. Foundational context: Google re:Work on setting goals with OKRs. The worked examples, targets, guardrails and check-in questions are illustrative recommendations, not reported business results.
You May Also Like
Your Ultimate Guide to a Successful Product Launch: Step-by-Step with Real-World Example
Guide to Stakeholder Mapping: Real-World Examples and Best Practices
