OKRs in product management (definition)

OKRs separate what a team believes is strategically important (the objective) from the evidence it will accept that the needle moved (the key results). Andy Grove invented the structure at Intel in the 1970s under the name iMBOs. John Doerr brought it to Google in 1999 when the company had 40 employees. Those are the two canonical origin points; knowing both is basic table stakes before any interview.

Structure

The objective is qualitative and motivating. It names a meaningful change in the world, not a list of work. The key result is quantitative and falsifiable: you either hit the number or you did not. Two to four key results per objective is the workable range. More than that and the team is tracking a dashboard, not committing to a theory of change.

The test almost every candidate fails: if the key result would still be complete even if the product shipped broken and nobody used it, it measures output, not outcome. “Launch three onboarding improvements” passes the broken-product test. “Reduce median time-to-first-value from 14 minutes to 6 minutes” does not. Only one of these is a key result.

The three archetypes

Most PMs know one OKR type. Interviewers at Google and Alphabet operate with three, and the distinction changes how you interpret 70% attainment:

• Committed OKRs: must be 1.0. These cover operational necessities where falling short is a real failure: uptime, compliance, safety thresholds. Missing one is a problem to diagnose, not a signal of ambition.
• Aspirational OKRs: 70% attainment is the intended target. 100% means you aimed too low; 40% means the target was wrong or the strategy was. This is what most people mean when they discuss OKRs.
• Learning OKRs: the point is to generate signal, not hit a number. The key result is structured as a hypothesis test. Performance is evaluated on whether the team learned what it committed to learning, not on the magnitude of the outcome.

Naming the archetype that applies to each objective in an interview is a senior-PM tell.

Counter-metrics: the question interviewers wait for

Strong PMs track what a feature might break alongside what it should move. If you optimize email open rate, you also watch unsubscribe rate and support ticket volume. Interviewers at Google and Meta listen for counter-metric discipline and cut candidates who focus only on the metric they are trying to move. Naming the counter-metric before you are asked is one of the clearest signals of operating experience. Spotify and LinkedIn formalized this as “health metrics”: the objective moves the needle, the health metric ensures the rest of the product does not degrade.

OKRs vs. KPIs vs. tasks

KPIs are standing metrics that indicate product or business health. They do not expire. OKR key results are time-bound targets encoding this quarter’s strategic bet. Tasks and initiatives are the work the team does to move the key results. “Launch feature X by Q3” is a task. It belongs on the roadmap, not in the key results column.

Why programs fail

McKinsey reports that 70% of organizations that formally adopted OKRs saw improved strategic alignment, but abandonment rates remain high. The failure mode is almost always the same: quarterly reviews become theater. The team writes OKRs, grades them generously, and resets without connecting the shortfall to next quarter’s roadmap. Candidates who can diagnose this credibly, and describe what a living OKR review looks like, stand out against candidates who only recite best practices.

The 2026 angle: viability is the hard constraint now

AI-assisted development has collapsed the cost of shipping features. A team can ship in days what used to take a quarter. That changes what OKRs are for. They are no longer a pacing mechanism. They are the primary filter on viability and whether users actually change behavior.

Two traps specific to AI products: first, “launch an AI feature” is an initiative. The key result should be a downstream behavior change: time-to-insight, resolution rate, tasks completed without human correction. Second, quality metrics require baselines that often do not exist when you write the OKR. When the key result is “hallucination rate below 2%,” the right move is a measurement OKR first (“establish a baseline eval on 200 representative tasks”), then a performance OKR once the data exists. Candidates who have shipped AI features know this pattern.

Interview: weak vs. strong

For how OKRs connect to the single number a team aligns around, see North Star Metric. For the roadmap decisions OKRs inform, see roadmap. For how AI changes what counts as a good key result, see feasibility is free.