North Star Metric and OKRs
Concept
Once a team grows past a single person making every product decision, priorities start diverging silently — two engineers can both be doing "obviously the right thing" for the business and still be pulling in opposite directions. North Star Metric and OKRs (Objectives and Key Results) are two related but distinct tools for keeping decisions pointed at the same outcome without requiring every decision to route through one person.
A North Star Metric is the single metric (or small, tightly-scoped set) that best captures the core value the product delivers to customers, chosen so that moving it up reliably correlates with the business succeeding. The classic property that makes a metric a good North Star candidate: it has to be a leading indicator of revenue/retention, not a lagging one, and not a vanity metric. "Signups" is a poor North Star — it's easy to inflate and doesn't prove anyone got value. "Completed bookings per month" (for a marketplace) or "weekly active teams sending a message" (for Slack, historically) are better — they only go up when the product is actually delivering its core value repeatedly.
OKRs, the framework Google popularized internally and later documented publicly through re:Work, operate at a different altitude: they're a quarterly (usually) goal-setting structure, not a single number. An Objective is a qualitative, ambitious statement of where a team wants to go; Key Results are 2-4 measurable results that would prove the objective was hit, graded numerically (Google grades on a 0.0-1.0 scale). The two concepts compose: a company's North Star Metric is the thing OKRs, at every level of the org, should ultimately be moving — an engineering team's quarterly OKR should trace back to how it moves the North Star, even indirectly (e.g. "reduce checkout latency by 30%" as a Key Result serves a North Star of completed transactions by reducing drop-off).
Tradeoffs
| Tool | What it's good at | What it's bad at |
|---|---|---|
| North Star Metric alone | Fast, intuitive alignment check ("does this move the number?") for day-to-day prioritization calls | Too coarse for planning concrete work — doesn't tell a team what to build this quarter, only whether an idea is roughly pointed the right way |
| OKRs alone | Structured, time-boxed planning with measurable Key Results; forces explicit tradeoffs between competing initiatives | Without a North Star anchoring them, OKRs can drift into measuring local team output (velocity, features shipped) instead of actual customer/business value |
| Both together | North Star gives OKRs a shared target to trace back to; OKRs give the North Star a concrete quarterly plan for moving it | Requires real organizational discipline to keep them connected — easy for OKRs to quietly decouple from the North Star as teams optimize for hitting their own numbers |
Google's own guidance is explicit that OKRs are ambitious by design — a team consistently scoring 1.0 on every Key Result is a signal the OKRs weren't ambitious enough, not that the team is executing perfectly. Scoring 0.6-0.7 on average is treated as the healthy range. This deliberately breaks OKRs' usefulness as a performance-review tool (Google is explicit OKRs are not employee evaluations) — conflating the two pushes teams toward sandbagging targets they know they can hit, which defeats the entire mechanism.
When to use / when not to
- Adopt a North Star Metric as soon as more than one person is making product decisions independently — it's the cheapest alignment tool available and doesn't require a planning ritual to use day-to-day.
- Adopt OKRs once there's enough team structure that quarterly planning has real tradeoffs to make (multiple teams, competing priorities for limited engineering capacity) — a single small team often doesn't need the formal structure yet.
- Don't pick a North Star Metric that's easy to move without delivering real value (signups, page views, raw DAU with no depth-of-use qualifier) — it will get gamed, consciously or not, the moment it's tied to any team's goals.
- Don't use OKR grades as performance-review inputs — doing so is the single most common way OKR programs quietly collapse, because it incentivizes sandbagging ambitious targets.
Common pitfall
Choosing a North Star Metric that's a company-wide vanity number (total revenue, total users) rather than one specific enough to guide day-to-day product decisions. A metric like "revenue" is too downstream and too lagging — by the time it moves, the decisions that caused the move happened months earlier, and it's too coarse to tell an engineering team whether a specific feature helped. A useful North Star is close enough to the product's actual usage loop that a team can look at this week's number and connect it to what shipped recently.
Engineering Lens
The place this pays off directly for an engineering team is scoping work: when a proposed project's connection to the North Star Metric can't be articulated in one sentence ("this reduces onboarding drop-off, which increases completed first-bookings"), that's a signal the project is solving an interesting engineering problem rather than a business one — not necessarily wrong to build, but worth naming explicitly as a bet rather than smuggling it in as obviously-necessary. The same discipline applied to OKR-setting at the team level prevents the common failure mode of OKRs that measure output (tickets closed, services migrated) instead of the outcome those outputs were supposed to produce.