The first OKRs I helped write for a product team were really a project plan with a new heading. "Objective: Improve the app. Key result: Launch the new home screen. Key result: Ship offline downloads."
We hit every key result. I'm still not sure whether the app improved.
When I was part of moving the Travelxp product and engineering organisation toward outcome-driven delivery, OKRs were one of the tools we used. They helped, but only once we stopped writing them as task lists.
The basic idea
An objective is a short statement of what you want to achieve. Key results are measurable signs that you got there. The point is to agree on outcomes and leave the team room to figure out how. 1
Simple to describe. Easy to get wrong.
Output key results vs outcome key results
| Output (what you'll do) | Outcome (what changes) |
|---|---|
| Launch new onboarding flow | More new subscribers start a video in their first session |
| Ship payment retry feature | Fewer bookings lost to temporary payment failures |
| Release Smart TV app v3 | Play failure rate on TV platforms goes down |
| Build AI summary feature | Teams using summaries spend less time on weekly reports |
The output version tells you whether the team was busy. The outcome version tells you whether it mattered. Outputs can still appear in your plan, just not as key results.
Examples for a product team
These are illustrative.
Objective: Make the first week feel worth paying for.
- Increase the share of new subscribers who watch something meaningful in their first seven days.
- Reduce cancellations in the first 14 days.
- Keep support contacts per new subscriber flat or lower.
Objective: Make booking feel reliable.
- Reduce checkout sessions that end in a payment error.
- Reduce support contacts about booking status.
- Maintain overall checkout completion.
Notice that each objective has one key result acting as a guardrail. That stops the team from hitting the main number in a way that causes damage somewhere else.
Mistakes I keep running into
Too many objectives. If a team has five objectives a quarter, it effectively has none. Two or three is plenty.
Key results nobody can measure yet. If the tracking doesn't exist, the first week goes into building it, and the key result becomes "we think it went up." Check data availability before committing.
Grading that rewards sandbagging. If hitting 100% is celebrated and 70% is treated as failure, teams will set easy targets. Be clear about whether these are stretch goals or commitments.
Setting and forgetting. OKRs written in week one and reviewed in week twelve don't guide anything. A short monthly check is enough to keep them useful.
Disconnected from the roadmap. If the roadmap and the OKRs point in different directions, the roadmap wins. Make sure the main roadmap items clearly support a key result. The outcome-based roadmap example shows one way to line them up.
Where the north star fits
If you have a north star metric, OKRs are a way of choosing which input to focus on this quarter. The north star stays steady. The objectives change as you learn.
Keep them honest
At the end of the quarter, write a few lines on each key result: what happened, what you learned, and what you'd do differently. A missed key result with a clear lesson is more valuable than an easy one hit by accident.
If the team ends the quarter knowing more about what moves their users, the OKRs did their job, whatever the score says.