Examples

Six OKRs, scored and rewritten.

Each pair shows the same goal written badly and well. The gap between them is almost always one thing: the weak version describes work, the strong version describes what changes after the work is done.

01 · Engineering velocity

From shipping a platform to shipping daily.

Rewrite9 / 100 · Rewrite

Launch the new CI/CD platform by Q3.

  • Migrate all teams to the new platform.
  • Reduce build times.
  • Improve developer experience.
Why it fails
  • "Migrate all teams" is a task. What changes after?
  • KR2 has no baseline and no target.
  • KR3 is unmeasurable as written.
  • The Objective embeds the solution.
Ship86 / 100 · Ship

Cut median PR cycle time so teams can ship to production daily by end of Q3.

  • Median PR-to-merge time drops from 38h to under 8h across all backend services.
  • Share of services deploying at least once per working day moves from 22% to 70%.
  • Developer NPS for the deploy pipeline moves from 14 to 35.
Why it works
  • The Objective names the outcome, not the tool.
  • Each KR has a baseline and a target.
  • The three KRs cover system speed, team behaviour, and perception.
Load in Diagnose →
Coach note
The word "platform" in the weak Objective is the first tell. Any Objective that names a deliverable before naming a problem has already committed to a solution.
02 · User activation

From driving signups to driving behaviour change.

Rewrite8 / 100 · Rewrite

Drive strong activation for new users in Q3.

  • Reach 10,000 new signups in Q3.
  • Send 200,000 onboarding emails.
  • Launch redesigned onboarding flow by August 1.
Why it fails
  • Signups measure acquisition, not activation.
  • "Send 200,000 onboarding emails" measures an action your team takes.
  • "Launch redesigned onboarding flow" is pass/fail.
  • "Strong activation" is never defined.
Ship88 / 100 · Ship

Get new users to their first meaningful action before the end of their first week.

  • Share of new users who complete a core action within 7 days moves from 19% to 42%.
  • Median time from signup to first completed core action drops from 4.1 days to under 18 hours.
  • 7-day-to-30-day retention for users who completed a core action in week one moves from 34% to 52%.
Why it works
  • The Objective defines "activation" implicitly through the KRs.
  • KR3 connects activation to downstream retention.
  • All three KRs are observable from product event data.
Load in Diagnose →
Coach note
Counting emails sent is measuring effort, not impact. Start with the behaviour change, then build the activation funnel backwards.
03 · Customer support

From placeholder quality goals to specific service commitments.

Rewrite4 / 100 · Rewrite

Improve customer support quality and efficiency.

  • Improve customer satisfaction scores.
  • Reduce average resolution time.
  • Increase first-contact resolution rate.
Why it fails
  • All three KRs are field names without numbers.
  • The Objective is a slogan.
  • These KRs could have been written without looking at a single ticket.
Ship90 / 100 · Ship

Resolve the majority of customer issues before they escalate or repeat, by end of Q3.

  • Median first-response time for Tier-1 tickets drops from 9h to under 2h across all channels.
  • First-contact resolution rate for billing and account-access tickets moves from 54% to 72%.
  • Post-resolution CSAT moves from 3.6 to 4.2 on a 5-point scale for tickets handled by the new triage workflow.
Why it works
  • The Objective names a specific failure mode.
  • Each KR scopes itself precisely.
  • The three KRs measure speed, effectiveness, and perception together.
Load in Diagnose →
Coach note
The weak version scored 4/100. That score comes from three KRs entirely empty of numbers. "Improve satisfaction scores" is not a KR. It is a column header waiting for data.
04 · Revenue

From owning all revenue to owning one lever.

Rewrite6 / 100 · Rewrite

Grow the business and increase revenue this year.

  • Increase annual recurring revenue by 30%.
  • Expand into two new market segments.
  • Hire a new VP of Sales by Q2.
Why it fails
  • "Increase ARR by 30%" is a company-level outcome no single team controls.
  • "Hire a VP" is a task.
  • The Objective is a tautology.
  • No baseline on any KR.
Ship84 / 100 · Ship

Turn more trials into paying customers by making the pricing decision easier.

  • Trial-to-paid conversion moves from 8.4% to 14% for trials that reach the aha moment.
  • Median time from trial start to first payment drops from 21 days to 12 days.
  • Expansion MRR moves from 11% to 18% of total MRR.
Why it works
  • The Objective identifies a specific lever.
  • KR1 scopes to users who already reached the aha moment.
  • KR3 tracks expansion MRR as a share, not an absolute.
Load in Diagnose →
Coach note
Revenue OKRs almost always fail the "does the team control this?" test. If no single team controls ARR, no single team should commit to it as a KR.
05 · Retention

From generic churn reduction to a specific problem window.

Rewrite7 / 100 · Rewrite

Reduce churn and improve retention across our customer base.

  • Reduce churn.
  • Improve weekly active users.
  • Implement a customer health score dashboard by Q2.
Why it fails
  • KR1 has no baseline, no target.
  • "Improve weekly active users" does not define active.
  • "Implement dashboard" is a project task.
  • The Objective restates the same idea twice.
Ship87 / 100 · Ship

Stop losing customers in the 30-90 day window where disengagement becomes cancellation.

  • Monthly churn rate for customers in first 90 days drops from 6.2% to under 3%.
  • Share of monthly active accounts in the 30-90 day cohort moves from 41% to 62%.
  • Median days between last login and cancellation in the 30-90 day cohort increases from 8 to at least 22.
Why it works
  • The Objective pinpoints the problem window.
  • KR3 measures the early-warning signal, not the lagging outcome.
  • All three KRs scope to the same cohort.
Load in Diagnose →
Coach note
Churn has a shape. Early churn is an activation problem. Mid-cycle is an engagement problem. Late churn is a value problem. Scope the window first.
06 · Product quality

From fixing bugs to making quality invisible.

Rewrite8 / 100 · Rewrite

Improve the quality and reliability of the product.

  • Fix all critical bugs.
  • Achieve 99% uptime.
  • Improve app performance.
Why it fails
  • "Fix all critical bugs" is a task list.
  • "99% uptime" has no baseline.
  • "Improve app performance" has no baseline, target, or scope.
Ship85 / 100 · Ship

Make product quality invisible to users: no crashes, no slowdowns, no missing features for a full quarter.

  • P0/P1 bug reports drop from 14 per week to under 3, sustained for 8 consecutive weeks.
  • Median page load for the three highest-traffic flows drops from 3.8s to under 1.4s on 4G.
  • User-reported errors via in-app feedback drop from 47 per week to under 10.
Why it works
  • Each KR specifies a window of sustained performance.
  • KR2 names the measurement instrument.
  • KR3 uses user-reported errors as a leading signal.
Load in Diagnose →
Coach note
"Fix all critical bugs" is the quintessential binary milestone. On day one of Q4 you either have zero or you do not. Write what changes for users.
Run your own OKR through the diagnostic.
Or load any of the strong examples above to see the result page.
Diagnose →