01 / UNDERSTAND
What are objectives and key results?
OKRs pair an objective with key results that make progress toward it observable. The objective describes the change a team wants to achieve; the key results specify measurable outcomes within a stated period. An initiative is work you choose; a key result is evidence of change.
The approach developed through Intel and was introduced to Google by John Doerr. It can focus design work when measures represent the experience the team intends to improve, rather than the number of screens or workshops it produces.
Why use OKRs?
A roadmap can make activity visible without showing whether it helped anyone. OKRs connect an intended outcome to evidence a team can review, leaving room to change the intervention as it learns. Their value depends on a credible measurement contract and authority to act. A numerical target alone cannot resolve an unclear strategy or an outcome the team cannot influence.
When to use it
USE IT WHEN
A team has a clear direction but needs shared evidence of progress.
Several possible initiatives could serve the same outcome.
The team can measure the result and adjust its work during the period.
When to choose another method
Use Research Plan when the outcome or baseline is not yet understood.
Use North Star Metric for a durable product value model.
Use Product Roadmap to coordinate delivery after priorities are agreed.
What you’ll need
Agree the scope, period, team and decision authority. Establish baseline definitions and data quality before choosing targets. Distinguish an expected commitment from an intentionally ambitious aspiration or a learning objective. Decide which guardrails protect users and operations. Name the review cadence and what evidence would justify changing an initiative or revisiting the target.
What makes an OKR reviewable
Keep the elements that help answer your question and support a decision.
A clear change that matters to people and the organisation.
Observable outcomes with baseline, target and deadline.
Population, source, definition and data limitations.
Actions believed to contribute to the outcomes.
Consequences that should not deteriorate for a score to improve.
Owners and decisions when progress or assumptions change.
02 / PUT IT INTO PRACTICE
How to write and use design OKRs
Keep evidence and assumptions distinct. Revisit your work when new information changes your understanding.
01
Choose a meaningful objective
Describe the intended change without prescribing an interface.
Make repair booking dependable, rather than launch a new confirmation screen.
02
Establish the baseline
Check definitions and measurement before selecting a target.
Count accepted bookings with correctly delivered confirmations.
03
Write key results
Specify outcome, population, baseline, target and period.
Move reliable confirmation from 80% to 95% within the quarter.
04
Set expectations
Clarify whether the result is committed, aspirational or primarily for learning.
Do not assume that a familiar scoring convention applies to every objective.
05
Add guardrails
Name ways the result could improve while the experience worsens.
Keep unresolved access needs and repeat contact visible.
06
Choose initiatives
Select plausible actions while allowing their replacement as evidence develops.
Test status ownership and message timing before committing to a redesign.
07
Review and decide
Use progress and guardrails to adjust work, not merely grade the team.
A better score with more excluded requests triggers an investigation.
Example: making repair booking dependable
Fictional scenario: a team sets the objective “Make repair booking dependable.” Over an illustrative quarter, one key result aims to raise correctly delivered confirmation within the agreed window from 80% to 95% of accepted bookings. Another aims to reduce repeat contacts caused by unclear status from 20 to 10 per 100 accepted bookings. These baselines and targets are invented, not benchmarks.
The team proposes a status ownership change and a revised confirmation message as initiatives. It monitors unresolved access needs so performance cannot improve simply by excluding harder requests.
The visual separates objective, two key results and initiatives, with a guardrail strip below. Shipping the message is not achieving the objective. At review, the team checks the outcome definitions and who remained outside the measured population before deciding whether the intervention worked.
03 / BELOW THE SURFACE
Below the surface: a key result can succeed while the objective fails
A target measures a chosen proxy, and the team can change the conditions around that proxy.
OUTCOME
What changed for the person receiving the service?
Separate activity from evidence.
COUNTEREXAMPLE
How could the target rise without delivering the objective?
Choose a relevant guardrail.
REVIEW
What decision follows from the evidence?
Adjust work rather than merely assign a grade.
Suppose a booking is counted only after every field is complete. Restricting entry to simple cases could improve confirmation reliability while residents with unusual needs receive less help. The numerical key result might be reached without the intended service improvement.
Construct a counterexample before approving the OKR: how could the team meet this target without delivering the objective? That counterexample reveals the guardrail you need. Monitor excluded demand or unresolved need alongside the selected rate where feasible.
This is an editorial review practice, not an alternative OKR framework. It also explains why blindly averaging key result scores can hide a serious miss. Preserve the meaning of each result and investigate tradeoffs before declaring the objective achieved.
OKRs companion worksheet
The original companion records an objective, key results, measurement rules and initiatives. Its review page keeps guardrails, assumptions and decisions beside progress. It does not impose a universal scoring convention or target attainment threshold.
Practical tips
Write the measurement definition with the target.
Keep initiatives separate from outcomes.
Review guardrails before declaring success.
Common mistakes
Using a launch checklist as key results.
Applying aspirational scoring to every commitment.
Averaging scores while ignoring a consequential failure.
What you’ll get
A focused outcome plan with credible evidence and explicit boundaries. Use review findings to continue, replace or stop an initiative, and record any revision to the objective or measurement contract.