What OKRs are and why they matter for PMs
OKRs (Objectives and Key Results) are a goal-setting framework that connects ambitious qualitative goals (Objectives) to measurable outcomes (Key Results). The Objective answers "where are we going?" and the Key Results answer "how will we know we got there?" Unlike task lists or project plans, OKRs define outcomes, not outputs. "Ship the new dashboard" is a task. "Users can self-serve 80% of reporting questions without requesting analyst help" is a Key Result.
For PMs, OKRs solve a fundamental alignment problem: how do you ensure that your team's daily work connects to the company's strategic direction? Without OKRs (or an equivalent), teams drift toward whatever feels urgent or interesting, and "aligned" means "the CEO told me to build this." With OKRs, every feature and initiative should trace back to a Key Result, which traces to an Objective, which traces to company strategy. This chain of logic makes prioritization defensible and scope trade-offs transparent.
OKRs also shift the conversation from "did we ship the thing?" to "did shipping the thing produce the outcome we expected?" This is the most valuable and most uncomfortable shift. It means a team can ship everything on their roadmap and still "miss" their OKRs if the shipped features didn't move the metrics. That discomfort is the point — it forces teams to care about impact, not just activity.
Writing effective OKRs
OKR Writing Template Core Method
Use when: writing team-level OKRs for a quarter.
An Objective should be:
- Qualitative — no numbers in the Objective (those go in Key Results).
- Inspirational — it should feel meaningful, not bureaucratic.
- Time-bound — typically one quarter.
- Actionable — the team can influence the outcome. Bad: "Improve onboarding." Good: "Make new users successful from day one.".
Each Objective gets 2-4 Key Results. A Key Result should be:
- Measurable — a specific number you can track.
- Outcome-oriented — measures impact, not output.
- Stretch but achievable — 70% completion should feel like strong performance.
- Unambiguous — at the end of the quarter, there's no debate about whether you hit it. Bad: "Improve activation rate." Good: "Increase 7-day activation rate from 34% to 45%.".
The format: Objective: [qualitative goal] — KR1: [metric] from [baseline] to [target]. KR2: [metric] from [baseline] to [target]. KR3: [metric] from [baseline] to [target]. Always include the baseline. "Increase NPS to 50" means nothing if you don't know whether you're starting from 10 or 48.
Anti-Pattern Checklist Tool
Use when: reviewing OKRs before committing to them.
Check for common failure modes:
- Output KRs — "Ship feature X" or "Launch campaign Y" are outputs, not outcomes. Rewrite as the impact: "Feature X increases retention by 5%.".
- Business-as-usual KRs — "Maintain 99.9% uptime" is BAU, not a stretch goal. OKRs are for improvement, not maintenance.
- Too many KRs — more than 4 per Objective dilutes focus. If you have 8 KRs, you have 2 Objectives.
- Sandbagged KRs — if you're confident you'll hit 100%, the target isn't ambitious enough.
- Uncontrollable KRs — "Increase revenue by 30%" when revenue depends on sales team performance the PM can't influence. Scope KRs to what your team controls.
Common mistake
Setting OKRs that are actually a disguised project plan. If your three Key Results are "Complete research (Q1)," "Build MVP (Q2)," and "Launch to 100% (Q3)," those are milestones, not Key Results. They measure schedule adherence, not impact. Ask: "If we complete all three on time but users don't adopt the feature — did we succeed?" If the answer is no, your KRs need to measure adoption, not completion.
Cascading and alignment
Cascade vs. Alignment Model Core Method
Use when: connecting company OKRs to team OKRs.
There are two approaches to connecting OKRs across levels: Cascading — company KRs become team Objectives. If the company KR is "Increase NRR from 105% to 115%," your team's Objective becomes "Improve retention for enterprise accounts" with KRs that contribute to the company-level metric. This creates tight alignment but can feel mechanical. Alignment — teams set their own OKRs based on their understanding of company strategy, then check that their OKRs are directionally consistent with company OKRs. This preserves team autonomy but risks drift.
The best approach is usually a hybrid: cascade the Objectives (team Objectives should clearly support company Objectives), but let teams define their own Key Results (teams know better than executives which specific metrics they can move). This gives teams ownership of their targets while ensuring strategic alignment.
OKR Alignment Workshop Technique
Use when: starting a new quarter and need to ensure team OKRs connect to company strategy.
Run a 2-hour workshop at the start of each quarter: (1) Leadership presents company OKRs and the strategic context behind them (30 min). (2) Teams draft their OKRs in breakout groups (30 min). (3) Teams present back, highlighting how their OKRs connect to company OKRs (30 min). (4) Cross-team discussion to identify overlaps, dependencies, and gaps (30 min). The output: aligned team OKRs and a visible dependency map. The workshop format ensures alignment happens through conversation, not through a spreadsheet passed through email.
Check-in cadences and grading
Weekly Check-In Format Core Method
Use when: OKRs are set at the start of the quarter and forgotten until the end.
A weekly OKR check-in takes 10 minutes in your existing team meeting. For each Key Result, report: Current value (where the metric is today), Trend (improving, flat, declining since last week), and Confidence (on track / at risk / off track). If a KR is "at risk," briefly state why and what you're doing about it. Don't debate solutions in the check-in — flag the risk, then schedule a separate problem-solving session.
The discipline of weekly check-ins transforms OKRs from a quarterly exercise into a weekly operating rhythm. Teams that check in weekly hit their OKRs at roughly 2x the rate of teams that only look at OKRs at the beginning and end of the quarter.
OKR Grading Rubric Core Method
Use when: the quarter ends and you need to evaluate OKR performance honestly.
Grade each Key Result on a 0.0-1.0 scale:
- 0.0-0.3 — no meaningful progress. Either the wrong KR or execution failed.
- 0.4-0.6 — some progress but fell short. Expected for truly ambitious stretch goals.
- 0.7-0.8 — strong delivery on a stretch target. This is the "sweet spot" — it means you set ambitious goals and made substantial progress.
- 0.9-1.0 — exceeded the target. If this happens consistently, your targets aren't ambitious enough.
Grade honestly. The purpose of grading isn't performance evaluation (OKRs should never be tied to compensation) — it's learning. A 0.3 score should trigger a retrospective: was the target wrong, the approach wrong, or the priority wrong? A 1.0 should trigger a question: did we sandbag, or did we genuinely outperform?
Practical tip
Never tie OKR scores to individual performance reviews or compensation. The moment OKRs affect bonuses, teams sandbag their targets. You'll get perfect 1.0 scores on unambitious goals instead of honest 0.6 scores on stretch goals. OKRs are a learning and alignment tool, not an accountability weapon.
Goal-setting alternatives
Goal-Setting Alternatives Framework
Use when: OKRs aren't working for your team and you need a different approach.
OKRs aren't the only option:
- NCTs (Narratives, Commitments, Tasks) — used at Spotify. A Narrative explains the strategic context, Commitments are the outcomes you're betting on, and Tasks are the work to get there. More story-driven than OKRs.
- V2MOM (Vision, Values, Methods, Obstacles, Measures) — used at Salesforce. More comprehensive than OKRs, includes obstacles and values alongside goals. Heavier to write but forces deeper thinking.
- North Star + Input Metrics — one team-level North Star Metric that defines success, plus 3-5 input metrics the team directly controls. Simpler than OKRs, less structured.
- Bets — frame goals as "bets" with stated hypotheses: "We bet that improving onboarding will increase activation by 15%." More honest about uncertainty.
The best framework is the one your team will actually use. If OKRs feel like compliance paperwork, try NCTs or Bets. If your team lacks strategic context, V2MOM forces it. If your team is small and focused, North Star + Inputs may be all you need.
Real-world examples
Case study
Google: Where OKRs were popularized
Google adopted OKRs from Intel (via John Doerr) in the late 1990s and has used them ever since. Their implementation emphasizes stretch goals (0.7 is a good score), public transparency (everyone's OKRs are visible to everyone else), and separation from performance reviews (OKRs inform evaluation but don't determine it). The company sets OKRs at the company, team, and individual level, with quarterly cadence. Their most famous practice: Larry Page would set "10x" Objectives that seemed impossible, forcing teams to rethink their approach entirely rather than incrementally improving existing work.
Why it works: Cultural commitment at the top. When the CEO's OKRs are public and graded honestly, the entire organization takes the practice seriously. When OKRs are just a PM exercise, they become paperwork.
Case study
Figma: Team-level OKRs with product trio ownership
Figma sets OKRs at the team level (not individual), with the product trio (PM, designer, tech lead) jointly accountable for the Key Results. This means the engineer who ships the feature and the PM who defined the outcome share the same success metric. Their check-in practice: a weekly "health check" where each trio rates their OKR confidence (green/yellow/red) with a one-sentence explanation. Yellow and red items get airtime in the team lead sync.
Why it works: Shared OKR ownership between the trio eliminates the "PM sets goals, engineering delivers" dynamic. The trio debates the Key Results together, which means the targets are both ambitious and feasible — engineering's feasibility sense prevents sandbagging, and PM's ambition prevents complacency.
Common pitfalls
OKR theater: writing OKRs nobody references
Teams spend a week writing beautiful OKRs, file them in a document, and never look at them until grading time. The solution isn't better OKRs — it's weekly check-ins that make OKRs a living operating document. If your team doesn't reference OKRs in sprint planning and prioritization decisions, they're theater.
Too many OKRs
A team with 5 Objectives and 15 Key Results has prioritized nothing. OKRs are a focus tool — they work by making the team uncomfortable about what they're NOT doing. 1-3 Objectives with 2-3 KRs each. If everything is a priority, nothing is.
Changing OKRs mid-quarter
If you change OKRs every time the situation shifts, you never get the sustained focus that makes OKRs valuable. The rule: you can change the approach (how you pursue a KR) but not the target (the KR itself) within a quarter. If the target is genuinely wrong, that's a learning for next quarter's OKR-setting, not a reason to revise mid-cycle. The exception: major strategic pivots that make the Objective irrelevant.