OKRs (Objectives and Key Results) are a goal-setting framework that aligns teams around measurable outcomes. Popularised by Andy Grove at Intel and later by John Doerr at Google.
Structure
An Objective is qualitative — what you want to achieve. It should be ambitious, inspiring, and time-bound.
A Key Result is quantitative — how you’ll measure progress. Each objective has 2–5 key results.
| Good | Bad | |
|---|---|---|
| Objective | Become the go-to platform for small business invoicing | Improve the product |
| KR 1 | Increase monthly active users from 10k to 25k | Ship 15 features |
| KR 2 | Reduce time-to-first-invoice from 8 min to 3 min | Complete the redesign |
| KR 3 | Achieve NPS of 50+ from small business segment | Make customers happy |
The bad examples describe outputs (features shipped, work completed). The good examples describe outcomes (user behaviour, measurable impact).
Setting Good OKRs
- 3–5 objectives per quarter — more than that and focus is lost
- 2–5 key results per objective — enough to cover the objective, few enough to track
- 70% target — if you hit 100% every time, your OKRs aren’t ambitious enough. 70% achievement is healthy
- Outcomes, not outputs — “reduce churn by 15%” not “build retention dashboard”
- Team-level, not individual — OKRs drive team alignment, not individual performance reviews
- Quarterly cadence — set quarterly, check in monthly or bi-weekly, score at end of quarter
OKRs vs KPIs
| OKRs | KPIs | |
|---|---|---|
| Nature | Aspirational targets with a timeframe | Ongoing health metrics |
| Duration | Quarterly | Continuous |
| Target | Stretch (70% = good) | Threshold (100% = expected) |
| Example | ”Reduce onboarding drop-off from 40% to 20%" | "Uptime ≥ 99.9%” |
KPIs monitor the business. OKRs change the business. Both are needed.
Common Mistakes
Too many OKRs — ten objectives with four KRs each is forty things to track. Nobody can focus on that. Ruthlessly cut to 3–5 objectives.
Output-based Key Results — “Launch feature X” is a task, not a key result. Ask “what will change if we launch it?” and measure that instead.
No check-ins — OKRs set in January and reviewed in March are just wishes. Check in bi-weekly to course-correct.
Cascading removes autonomy — if every team’s OKRs are dictated by the layer above, you’ve recreated command-and-control with fancier language. Teams should set their own OKRs aligned to company objectives, not receive them.
Tying OKRs to compensation — this incentivises sandbagging. Keep OKRs aspirational and separate from performance reviews.
Confusing OKRs with a to-do list — OKRs define direction and success criteria. The backlog defines the work. They’re complementary, not the same thing.
Links
- Measure What Matters — John Doerr
- Google’s OKR Playbook
- Prioritisation Frameworks — deciding what to work on within your OKRs
- Product Mindset — the thinking behind outcome-driven goals