Objectives and Key Results

Define what must change, how success will be observed and how the team will learn before the cycle ends.

In one minute

An OKR has:

• an Objective: a meaningful, clear and action-oriented description of what the team wants to accomplish;
• a small set of Key Results: measurable outcomes that collectively demonstrate achievement.

Use the formula:

We will [Objective], measured by [Key Results].

Projects and tasks are initiatives. They may influence a Key Result, but completing them does not prove that the desired change happened.

Best for: a small number of cross-functional priorities that need alignment, measurable progress and adaptation.
Avoid when: work is primarily routine, success cannot yet be measured or the method is being used as individual performance scoring.

The problem it addresses

Plans often mix aspirations, projects and metrics without explaining which outcomes matter. Teams can complete a roadmap while customer, operational or financial results remain unchanged.

OKRs separate direction from evidence and activity. The intended output is a short, visible set of priorities and a review rhythm that changes decisions during the cycle—not a quarterly reporting form.

When to use it

Use OKRs when:

• leaders need to make trade-offs among competing priorities;
• several teams contribute to one measurable outcome;
• the route to the outcome is uncertain and initiatives may change;
• a strategic priority needs a shorter execution cycle;
• progress can be checked before the end of the period;
• teams need shared outcome language across functions.

Two or three Objectives with three to five Key Results each is a practical upper bound for a team cycle, not a universal law.

When not to use it

Do not use OKRs:

• as a complete operating plan for routine obligations;
• to turn every task or metric into a goal;
• when leaders refuse to stop lower-priority work;
• when data are unavailable or can be easily manipulated;
• as a direct formula for pay or individual ranking;
• as rigid top-down cascading that removes team judgement.

Use project planning for committed deliverables and operational controls for service levels that must remain within limits.

Inputs required

• strategic context and a decision horizon;
• baseline performance and trustworthy measures;
• authority to allocate or stop work;
• clear team scope and dependencies;
• metric definitions, owners and data sources;
• capacity constraints;
• an agreed review cadence;
• rules for committed and aspirational OKRs if both are used.

Step-by-step process

1. Choose the cycle and level

Define the period, accountable team and strategic context. Quarterly cycles are common, but the cadence should match how quickly the work can produce evidence.

2. Select a few meaningful Objectives

Each Objective should describe an important change, not business as usual.

Weak: “Improve onboarding.”
Better: “Make first value fast and predictable for new customers.”

3. Define outcome Key Results

Choose three to five measures that collectively prove the Objective. Include baselines and targets.

Example:

• reduce median time to first completed workflow from 10 days to 4 days;
• increase customers completing setup without support from 42% to 70%;
• increase 30-day activation from 55% to 68%.

4. Test the logic

Ask:

• If all Key Results are achieved, is the Objective truly achieved?
• Can the team influence the measures?
• Could the numbers improve while the real outcome gets worse?
• Are important quality or safety guardrails missing?

5. Align dependencies

Identify shared metrics, required contributions and conflicts with other teams. Prefer negotiated alignment to mechanical cascading.

6. Choose initiatives

List the projects and experiments most likely to move the Key Results. Make clear that initiatives can change when evidence changes.

7. Review progress regularly

At each check-in, update:

• current value;
• confidence of reaching the target;
• important evidence;
• blockers and dependencies;
• decision about initiatives.

8. Close and learn

Assess each Key Result using the agreed rule. Discuss causality, unintended effects and what should change in the next cycle. Do not carry an Objective forward automatically.

Visual model

Text alternative: strategic context informs an Objective. Three outcome Key Results define success. Initiatives attempt to move the results, and regular reviews adapt the initiatives before cycle-end learning.

Interactive example

Scenario

A customer-support team proposes this OKR:

Objective: Launch a better help centre.
KR1: Publish 30 articles.
KR2: Implement a new search tool.
KR3: Train all support agents.

Your move

Rewrite the Objective and Key Results around customer and operational outcomes.

Worked answer

Objective: Help customers resolve common problems quickly without losing confidence.

• KR1: Increase successful self-service resolution from 28% to 45%.
• KR2: Reduce repeat contacts for the ten highest-volume issues from 18% to 10%.
• KR3: Maintain customer effort score at 5.5/7 or better while self-service use increases.

Publishing articles, implementing search and training agents remain candidate initiatives. They are useful only if they change the outcome measures.

Facilitation notes

• Draft Objectives from strategic choices, not from department task lists.
• Bring metric owners into the writing session.
• Ask teams to identify a gaming risk for each Key Result.
• Make dependencies visible before targets are approved.
• Use check-ins for decisions, not status theatre.
• Record why an OKR was changed or stopped.
• Keep performance conversations broader than an OKR score.

Expected output

A sound OKR cycle produces:

• 1–3 priority Objectives per team;
• 3–5 outcome Key Results per Objective;
• baselines, targets, metric definitions and owners;
• dependencies and guardrails;
• a changeable initiative portfolio;
• regular progress and confidence records;
• an end-of-cycle learning review.

Common mistakes

1. Writing tasks as Key Results. Completion does not prove impact.
2. Creating too many Objectives. Everything important becomes nothing prioritised.
3. Using a metric without a baseline. Progress becomes ambiguous.
4. Ignoring guardrails. One metric improves by damaging quality, safety or trust.
5. Cascading mechanically. Teams optimise fragments rather than shared outcomes.
6. Waiting until the end. A final score without adaptation is retrospective reporting.

Quality checklist

• Each Objective describes a meaningful change.
• Key Results collectively demonstrate the Objective.
• Key Results measure outcomes rather than task completion.
• Baselines, targets, owners and sources are defined.
• Gaming risks and guardrails have been considered.
• Dependencies are agreed by the teams involved.
• Check-ins can change initiatives before cycle end.
• Evaluation is separated from simplistic individual ranking.

Template

Objective:

Why now:

Cycle and owner:

Knowledge check

Which item is the strongest Key Result for the Objective “Make customer onboarding fast and predictable”?

A. Redesign the onboarding screens.
B. Run six customer interviews.
C. Reduce the 90th-percentile time to first value from 18 days to 7 days.
D. Improve collaboration with Sales.

Answer: C. It measures a defined outcome with a baseline and target. The others are initiatives or vague intentions.

Related tools

• Preceded by: strategy analysis and prioritisation
• Often combined with: Balanced Scorecard, Customer Journey Mapping
• Supports: quarterly execution, cross-functional alignment and outcome reviews
• Not to be confused with: KPI dashboards, project plans or individual performance ratings

References

1. What Matters. “OKRs Explained, with John Doerr.” Official learning resource (opens in a new tab).
2. Google. “Google’s OKR Playbook.” Reproduced with permission by What Matters. Playbook (opens in a new tab).
3. Doerr, J. Measure What Matters. Portfolio, 2018.
4. Grove, A. S. High Output Management. Vintage, revised edition, 1995.

Sources reviewed 28 July 2026.