Key Result

Origin & evolution

The key result is Andy Grove's contribution to the older Management by Objectives tradition. Where Drucker had objectives, Grove added the measurable counterpart and paired the two, documenting the method in High Output Management (1983). His insight🔦InsightUser ResearchA synthesised finding from researchView reference → was that an objective alone drifts, so each one needs🫀NeedUserA user need, pain, desire, or constraintView reference → indicators that pace it: the key results answer "How will I know I am getting there?"

John Doerr formalised the structure he learned from Grove and brought it to Google in 1999, later writing it down in Measure What Matters (2018). Two of Doerr's conventions became near-universal. The first is the count: three to five key results per objective, few enough to stay focused and enough to triangulate. The second is the scoring scale, 0.0 to 1.0, where aspirational key results target roughly 0.7 and consistently hitting 1.0 is read as a sign the targets were set too low. Google's re:Work guide codified both for a generation of teams.

Christina Wodtke added the quality test in Radical Focus (2016): a good set of key results should be hard but possible, and it should include a counter-balancing measure so the team cannot win the number while damaging the product. Grove had already named this as pairing indicators in High Output Management, measuring both an effect and its likely side effect. The sharpest modern refinement is the leading-versus-lagging distinction. A lagging key result (revenue, retention) confirms the result after the fact; a leading one (activation in the first session, weekly active usage) moves earlier and can still be influenced inside the quarter. Strong sets mix the two, so the team has a number to steer by before the verdict arrives.

How it works in practice

The payments startup commits to one objective for Q3: make new merchants feel safe processing real volume in week one. It attaches three key results. Week-one activation rises from 34% to 55%. Median first-week processed volume per new merchant rises from £900 to £2,500. Support tickets🆘Support TicketCustomer SuccessCustomer support request or issueView reference → per new merchant fall from 1.8 to below 0.8.

The set is deliberately balanced. Activation and volume are the growth numbers the team is pushing up; the ticket count is the counter-metric🔢MetricStrategyA unified metric that measures progress, health, or behaviour across the productView reference → that stops them from shipping a confusing flow that technically activates merchants while flooding support. At the mid-quarter check-in, activation is the leading signal that moves first and tells them the onboarding rewrite is working, while volume lags by a few weeks because merchants need time to build trust. Each key result has a baseline, a target, and a unit, so the end-of-quarter score (say 0.7 on activation, 0.5 on volume) is a calculation, not a debate.

Key result vs. its neighbours

• Metric: a metric is a standing measurement the product tracks continuously, like daily active users, with no built-in target. A key result borrows a metric and binds it to a baseline, a target, and a deadline for one objective. The metric is the instrument; the key result is one timed reading the team has committed to move.
• KPI: a key performance indicator is an ongoing health gauge that should stay strong indefinitely. A key result is time-boxed to a single cycle and is meant to be retired once scored. Keeping a KPI flat is success; a key result that never changes has failed.
• Objective: the objective is the qualitative direction; the key result is its numeric evidence🔎EvidenceValidationData supporting or refuting a hypothesisView reference →. One objective typically holds three to five key results, and an objective carrying none is the format's defining anti-pattern.

In the graph

In the Unified Product Graph, key_result📈Key ResultStrategyA measurable result tied to an objective sits in the Strategy & Outcomes🏆OutcomeStrategyA desired business or user outcomeView reference → region as a hub: it receives objective_achieved_through_key_resultObjectiveachieved throughKey Resulthierarchy from above and connects downward through key_result_quantified_by_metricKey Resultquantified byMetrichierarchy and key_result_tracked_by_metricKey Resulttracked byMetrichierarchy to the standing instruments that supply its numbers. Delivery work reaches it through the cross-region edge feature_drives_key_resultFeaturedrivesKey Resultcross-domain, so a shipped feature⭐FeatureProduct SpecificationA product capability or featureView reference → traces forward to the number it was meant to move. That wiring separates the timed commitment (the key result, with its target_value, current_value, and kr_status) from the continuous instrument (the metric), which is exactly the distinction teams blur when they treat every dashboard🎛️DashboardData & AnalyticsAn analytics dashboardView reference → number as a goal.