How to Write OKRs That Actually Work (With Examples That Pass the Test)

Most OKRs fail the moment they get written down.

Not because the intentions are wrong. Because the writing itself introduces ambiguity that the team then spends the whole quarter arguing about. Vague Objectives that could mean anything. Key Results that track activity instead of outcomes. Targets so conservative that hitting them tells you nothing about whether the strategy is working.

This guide walks through the exact steps to write OKRs that create clarity rather than confusion — with before/after examples for the most common mistakes.

Why Does OKR Writing Go Wrong So Consistently?

Writing good OKRs requires two things that feel unnatural under deadline pressure: honesty about what you don’t know, and willingness to commit to numbers that might make you look bad.

Most people write around both of those discomforts. They write Objectives that are broad enough to be claimed as achieved regardless of what happens. They write Key Results that describe activities they control rather than outcomes they’re trying to produce. And they set targets they know they can hit.

The result is a goal-setting system that creates overhead without creating alignment. The calendar says you did OKRs. The team’s actual decision-making is still driven by whatever felt urgent this week.

Step 1: Write the Objective First — Without Numbers

The Objective is a direction, not a destination. It should be qualitative, inspirational, and short enough to remember.

The standard test: can someone on your team recite it without looking at the doc? If not, it’s probably too long or too abstract.

Common mistakes:

Too vague: “Improve our product.”

This tells the team nothing about what kind of improvement matters or why. Every team with a product could claim this as their Objective.

Too narrow and task-like: “Complete the Q4 roadmap items.”

This describes a workload, not a direction. Completing your roadmap is table stakes, not an inspiring pull.

Number contamination: “Grow revenue by 30%.”

The moment a number appears in the Objective, you’ve collapsed the direction and the measurement into one statement. The Objective should describe where you’re going. The Key Result is where the 30% lives.

Rewritten well: “Make our product the obvious choice for mid-market teams switching from spreadsheets.”

This is specific enough to mean something, broad enough to invite creativity, and number-free. It creates a clear image the team can test decisions against: “Does this feature help us become the obvious choice for that audience?”

Step 2: Write Key Results as Outcomes, Not Activities

This is the most reliably broken part of every OKR rollout. The distinction matters because activities are entirely within your control, while outcomes require something real to happen in the world.

The test John Doerr recommends: Does the Key Result describe something that requires a number to verify? If you need to ask “did we do it?” instead of “where did we land?”, it’s an activity.

Before (activity-based):

• KR1: Launch redesigned onboarding flow
• KR2: Send three case study emails to mid-market prospects
• KR3: Update the website messaging

After (outcome-based):

• KR1: Increase 30-day activation rate from 34% to 52%
• KR2: Grow mid-market pipeline from $180K to $320K
• KR3: Improve homepage-to-trial conversion rate from 2.1% to 3.5%

The activity-based version tells you the team was busy. The outcome-based version tells you whether the team made any real progress. Both versions might require identical work — but only the outcome version gives you meaningful signal at grading time.

Step 3: Set a Baseline Before You Set a Target

“Increase conversion rate to 4%” is a weaker Key Result than “Increase conversion rate from 2.1% to 4%.”

The baseline matters for two reasons.

First, it creates accountability. Without a known starting point, teams can claim progress by cherry-picking favorable measurement periods. With a baseline, there’s no ambiguity.

Second, it calibrates ambition. An increase from 2.1% to 4% is a 90% relative improvement — genuinely ambitious. An increase from 3.8% to 4% is minimal. You can’t evaluate whether a target is appropriately ambitious without knowing where you’re starting.

If you don’t have the baseline data yet, make establishing it your first Key Result of the cycle.

Step 4: Decide Whether the OKR Is Committed or Aspirational

Andy Grove’s original framework, and John Doerr’s refinement of it in Measure What Matters, both distinguish between two types of OKRs. This distinction changes how you grade and how you should feel about a partial result.

Committed OKRs are expected to be fully achieved. These apply to operational outcomes: uptime targets, revenue commitments, compliance deadlines. A score of 0.7 on a Committed OKR is not “in the success zone” — it means something went wrong.

Aspirational OKRs are designed to stretch the team. A score of 0.7 is the target. Consistently scoring 1.0 is a signal you’re not setting ambitious enough goals.

When you write each Key Result, label it explicitly. Most OKR tools include a field for this. If yours doesn’t, add a note in the description. Every grading conversation will go better if the team is aligned upfront about which standard applies.

Step 5: Keep the Set Small

Grove was emphatic: three to five Objectives, maximum. Two to four Key Results per Objective, maximum.

Teams that violate this end up with goal documents nobody reads and reviews that take 90 minutes because there are 23 things to check in on.

The discipline of choosing what goes on the list is where most of the strategic value is generated. Every item on your OKR list implicitly says: “We believe this matters more than everything that isn’t on the list.” If you can’t make that argument for an item, it shouldn’t be there.

A useful forcing question: if you could only achieve three of your current OKR items, which three would you choose? Start with those.

Before/After: A Full OKR Set Rewrite

Here is a complete example of a poorly written team OKR set, followed by a rewrite.

Before — Product team, Q4:

Objective 1: Ship features customers want

• KR1: Complete user research interviews
• KR2: Launch three new features
• KR3: Update the product roadmap

Objective 2: Improve engineering quality

• KR1: Reduce bugs
• KR2: Improve deployment process
• KR3: Hold weekly engineering reviews

After — same team, same quarter:

Objective 1: Make our product the default tool for daily task management in mid-market teams

• KR1: Increase daily active usage from 41% of licensed seats to 60%
• KR2: Raise NPS from 28 to 42
• KR3: Achieve top-3 placement in two G2 Crowd mid-market category lists

Objective 2: Build a codebase our team is proud to work in

• KR1: Reduce average bug-to-fix cycle time from 9 days to 4 days
• KR2: Increase deployment frequency from 2x/week to 5x/week
• KR3: Achieve 85% test coverage across core modules (currently 61%)

The rewrite takes roughly the same strategic intent and converts it from activity-tracking into outcome-tracking. The team knows exactly where they’re starting, what they’re aiming for, and how to tell at the end of the quarter whether they succeeded.

The Weekly Check-In Is Not Optional

Writing good OKRs is necessary but not sufficient. The operating cadence is what converts a well-written OKR into actual behavior change.

Grove recommended weekly OKR reviews — brief sessions where the team answers three questions for each Key Result:

1. Where does it stand right now?
2. Are we confident we’ll hit the target?
3. What is the biggest blocker?

The third question is the most important. Most OKR check-ins get stuck on status updates. Grove’s insight was that the check-in’s real job is to surface blockers early enough to do something about them.

A 30-minute weekly check-in, run consistently, will do more for your OKR outcomes than any amount of goal-writing sophistication.

Write One Good OKR This Week

The most common response to reading about OKRs is to plan a comprehensive rollout next quarter. That plan reliably never starts.

A more useful response: take your single most important current priority and write one Objective and two Key Results, following the principles above. Share them with your team tomorrow.

You’ll learn more from one real cycle — even an imperfect one — than from any amount of pre-planning.

Tags: how to write OKRs, OKR examples, OKR Key Results, goal setting, objectives and key results, productivity frameworks