OKR
Unlike SMART goals, OKRs are not a task-tracking tool: they are a tool for strategic alignment and learning. The central question they answer is not "Did we deliver what we said we would?" but "Did we create the impact we wanted?"
Origin
The system was developed by Andy Grove at Intel in the 1970s as an evolution of Peter Drucker's management by objectives (MBO). John Doerr learned it while working at Intel and introduced it to Google in 1999, when the company had just over 40 employees. Google adopted it and has used it ever since. The publication of the book Measure What Matters (Doerr, 2018) popularized the system beyond the technology sector.
The Structure of an OKR
The Objective
The objective describes the aspirational direction: what you want to achieve during the cycle. It should be:
- Qualitative: no numbers. Numbers belong in the KRs.
- Inspiring: it should generate energy and guide decisions, not be a form to fill in.
- Clear: anyone in the organization should be able to read it and understand where the team is heading.
- Non-prescriptive: it describes the destination, not the path. "Become the benchmark for agile training in the Spanish-speaking market" is an objective; "launch three new courses" is not: it describes activities, not the impact being sought.
Key Results
Key Results are the operational definition of the objective's success. To write them correctly:
- Use the format "From X to Y by date Z": it expresses a measurable shift between two points in time. "Increase the course completion rate from 42% to 60% by June 30."
- They must measure outcomes (results, impacts), not outputs (deliverables, tasks). A KR that uses verbs such as "deliver," "launch," or "complete" describes work, not impact.
- The multiple-paths test: a KR measures an outcome when several different solutions could achieve it. If the KR can only be achieved in one specific way, it is probably measuring a task.
- Two to four KRs per objective. More than four usually indicates that the objective is too broad or that tasks are being included.
Outcome vs. output: the key distinction
The distinction between outcome and output is the cornerstone of OKRs:
- An output is something that gets produced: a feature, a document, a deployment. It can be marked as "done" on the day it is delivered.
- An outcome is the change that output generates: a different user behavior, a business metric that moves, a problem that gets solved.
When success is defined as "launch feature X," the team optimizes for delivery, not for generating value. The feature may be deployed, the team celebrates, and yet no user changes their behavior and no metric moves. OKRs that measure outcomes avoid this trap: the team cannot declare success until the intended change happens in the real world.
| A KR is probably an output if... | A KR is probably an outcome if... | |
|---|---|---|
| Signals | It includes verbs such as "deliver," "launch," and "implement." It can be marked "done" on the day of deployment. | It measures a change in user behavior or in business metrics. Multiple solutions could achieve it. |
| Example (digital product) | "Launch the reporting module" | "Increase weekly report usage from 18% to 40%" |
Leading and lagging indicators
Key Results should combine two types of indicators:
- Leading indicators (predictive indicators): metrics that anticipate the final result and make it possible to act while there is still time during the cycle. Example: "first-week activation rate" predicts future retention.
- Lagging indicators (result indicators): metrics that reflect the final business result, but whose trend is only known once the cycle has already ended. Example: "annual recurring revenue."
An OKR made up only of lagging indicators doesn't allow decisions to be made during the quarter: by the time you detect that something is going wrong, it's already too late to correct course. Including leading indicators in the KRs makes check-ins useful: the team can adjust tactics in time.
The OKR Cycle
OKRs usually run on a quarterly cycle:
- Definition (weeks 1-2): the team defines the quarter's objectives and KRs. The starting point (baseline) for each KR must be documented.
- Check-ins (every 2-3 weeks): periodic reviews to update KR progress and make decisions. A check-in is not a status report: it is a conversation about what to do differently.
- Final evaluation: at the end of the quarter, each KR is scored (usually between 0 and 1) and the learning is captured.
The score is not the goal: learning is the goal. A KR scored at 0.3 because the hypothesis was wrong is more valuable than a KR scored at 1.0 because it was too easy.
OKRs and Scrum
OKRs and Scrum are complementary: they operate on different time scales and answer different questions.
- OKR answers "What strategic direction are we working toward this quarter, and how will we know if we are making progress?" It operates on a quarterly or annual scale.
- Scrum answers "What will we build over the next few weeks to move in that direction?" It operates on a sprint scale.
The Product Backlog serves as the bridge: the user stories that enter the backlog should be traceable to a KR. If a story cannot be connected to any key result for the quarter, its priority warrants a conversation.
The Product Owner (in its evolution into the Product Architect role) uses OKRs to prioritize the backlog and to push back on feature requests that do not contribute to any agreed key result.
Common pitfalls
Feature factory
An organization operates as a "feature factory" when it measures success by velocity and volume of delivery rather than by the impact generated. The symptoms are KRs that measure task completion percentages, roadmaps defined by delivery dates without success metrics, and teams that celebrate deployments without validating whether anything has changed for users.
Sandbagging
Sandbagging occurs when teams deliberately propose easy goals to make sure they will meet them. It appears especially when OKRs are tied to negative consequences for falling short. The solution is to decouple OKRs from individual compensation and to build a culture where learning from failure is as valid as success.
Mechanical cascading
Cascading OKRs (from leadership down to teams) carries the risk that teams accept objectives without checking whether they have the capacity, skills, or authority to influence them. A team that accepts a KR over which it has no real levers is guaranteeing failure.
Common mistake
Writing Key Results that are task lists. "Deliver module X, launch campaign Y, and complete report Z" are three outputs, not three key results. KRs framed as tasks create the same perverse incentive as the feature factory: the team focuses on completing work, not on generating impact. If all three items have been delivered by the end of the quarter but nothing has changed for users, the KRs are marked as achieved while the real objective has not been met.
Resources
📄 OKRs y estrategia de producto [OKRs and Product Strategy, in Spanish]Scrum Manager study guide · February 2026
🏦 OKRs y estrategia de producto [OKRs and Product Strategy, in Spanish]Skill Arena · Scrum Manager
📄 Product Owner v.2.0 [in Spanish]Free download · Scrum Manager
References
- Doerr, John. (2018). Measure What Matters: How Google, Bono, and the Gates Foundation Rock the World with OKRs. Portfolio/Penguin.
- Grove, Andrew S. (1983). High Output Management. Random House.
See also
Want to advance in agility? You can search for course and exam calls or go at your own pace by becoming a member of the Agile Club. This membership includes exclusive resources, e-learning classrooms, and access to Skill Arena: a space to practice and measure your agile skills at your own pace.