🎯OKRs Basics
Objectives and Key Results — the goal-setting framework that almost every tech company uses and most use badly.
OKRs are the operating system most product teams run on. If you don't understand the philosophy and the common failure modes, you'll be the PM whose OKRs are theater while the team ships whatever feels urgent.
OKRs separate ambition (Objective: directional, qualitative) from measurement (Key Results: specific, measurable, achievable in the quarter). The point isn't to hit 100% — it's to align teams on the few things that matter, force trade-offs, and create accountability. OKRs done badly are theater; done well, they're a forcing function for focus.
The format
Objective. A qualitative, ambitious statement of intent. "Make our product the easiest way to onboard a new team."
Key Results. 2-5 specific, measurable outcomes that, taken together, mean you achieved the objective. "Reduce time-to-first-value from 8 days to 2 days. Increase D7 activation from 32% to 50%. Reach NPS of 50+ for first-week users."
The objective is the what and why. The KRs are the how we'd know.
Good vs bad KRs
Bad KR: "Launch the new onboarding flow." This is a feature, not a result. You shipped it but the metric didn't move — did you succeed?
Good KR: "Move D7 activation from 32% to 50% for new signups by end of Q3."
The discipline: KRs are about outcomes, not output. The team can be measured on whether the outcome happened, not whether they shipped something.
How many OKRs
Per team, per quarter: 1-2 objectives, 2-4 KRs each. More than that, you're not prioritizing.
Per PM, the same. If you have 5 OKRs you're committed to, you're committed to none.
The 70% rule
OKRs are designed to be ambitious. The Google convention is that hitting 100% on every KR means you set them too low. The target is roughly 70% achievement — meaning some quarters you hit 100% and feel great, some you hit 50% and learn from it.
The mistake: making OKRs into commitments where missing one is a fireable offense. That makes people sandbag — set KRs they know they'll hit. Defeats the purpose.
OKRs vs commitments
Some companies separate OKRs (aspirational, 70% target) from Commitments (must-do, 100% target). The distinction is healthy. The bug: when OKRs and Commitments collapse into one, you get sandbagged OKRs that don't drive ambition.
Setting OKRs as a PM
Process I use:
- Read the company's annual strategy. What does this team need to contribute?
- Look at the team's metrics. What's the biggest gap?
- Draft 1-2 objectives that tie to strategy and address the gap.
- Draft 2-4 KRs for each, ambitious but plausible.
- Pressure-test with engineering and design. Are these achievable? What would have to be true?
- Get manager and skip-level alignment.
- Publish. Reference weekly.
The cardinal sin: OKR theater
OKRs set in January, never looked at again, then 'graded' in December — pointless. OKRs need a weekly or biweekly check-in cadence to actually steer the team's behavior.
Key frameworks
John Doerr's *Measure What Matters* is the canonical OKR text. Read it.
If you're consistently hitting 100% of KRs, they're not ambitious enough.
Real-world examples
Google adopted OKRs in 1999 via John Doerr (who imported them from Intel). Larry Page and Sergey Brin's quarterly OKR meetings became a cultural touchstone — and the practice spread to most of Silicon Valley.
Go deeper — recommended reading
Interview questions (2)
Q1Walk me through how you'd set OKRs for a new team.executionmid▼
Six steps:
- Understand the company strategy. Read the annual plan, talk to your VP. The team's OKRs have to ladder up to something.
- Look at the team's current metrics. Where's the biggest gap? Where's the most leverage?
- Draft 1-2 objectives. Ambitious, qualitative. 'Make X the easiest way to do Y.'
- Draft 2-4 KRs per objective. Measurable outcomes — not features shipped.
- Pressure-test with engineering and design. Are these plausibly achievable? What's the risk?
- Cadence. Weekly or biweekly check-in. Update progress. Adjust if a KR turns out to be wrong.
The non-obvious mistake: writing KRs that are really features ('launch new onboarding'). KRs should be outcomes ('move D7 activation from X to Y'). The team can hit the feature KR and still fail the actual goal.
Q2Your team hit all their OKRs but the business metric didn't move. What happened?strategysenior▼
Two most likely diagnoses:
- The KRs were proxies for the wrong thing. You measured what you could measure rather than what mattered. A common pattern: KR was 'ship feature X' or 'increase feature adoption,' but feature adoption doesn't actually drive the business metric. Fix: re-derive KRs from the business metric working backwards.
- The KRs were set too low (sandbagged). Team hit 100% on every KR, which usually means the targets were achievable without doing the hard work. Fix: in the next OKR cycle, push for the 70% rule — ambitious enough that 70% is a strong outcome.
Less likely but possible: external factors (market shift, competitor launch, macro) made the business metric uncorrelated with the team's work. Investigate, but don't use as an excuse.
Either way, the meta-lesson: OKRs that don't tie causally to a business metric are theater. Spend Q1 of the next year re-deriving the metric chain.