---
title: "How to Write Good OKRs: Fix a Weak Draft"
description: "How to write good OKRs: set a baseline and do-nothing trend, rewrite objectives as outcomes, add owners and deadlines, then stress-test every key result."
canonical_url: "https://builderscamp.com/guides/other/how-to-write-good-okrs"
date_published: "2026-09-27"
date_modified: "2026-09-27"
author: "Andre Albuquerque"
publisher: "Builders Camp"
guide_class: "other"
---

# How to Write Good OKRs: Fixing a Weak Draft Step by Step

**TL;DR:** To write good OKRs, start from the metric's baseline and its do-nothing trend, rewrite each objective as an outcome, turn every key result into a number with a date, rank them, and give each one owner. Then stress-test every key result by asking how someone could hit it while making the product worse, and fix the ones that fail.

Most weak OKR sets fail in the same few places: objectives that describe a wish, key results that describe work, and targets picked without knowing where the number was heading anyway. Google's [re:Work guide to OKRs](https://rework.withgoogle.com/intl/en/guides/set-goals-with-okrs) recommends three to five objectives with about three key results for each, and puts the core rule plainly: "Key results should describe outcomes, not activities." Almost every fix below is a way of applying that rule.

Ryan Panchadsaram notes in What Matters' [OKR guide](https://www.whatmatters.com/faqs/okr-meaning-definition-example) that "Every set of OKRs should incorporate feedback from within the organization and undergo multiple checks and drafts." So this guide does exactly that: it takes one weak set from a fictional company and redrafts it until it holds up.

## What does a weak OKR set look like?

Ledgerly is a fictional invoicing app for small accounting firms. Its product team wrote this draft for next quarter:

| Draft objective | Draft key results |
|---|---|
| O1: Be the best invoicing tool for accountants | Launch recurring invoices; redesign the dashboard; improve NPS |
| O2: Improve onboarding | Ship a new setup checklist; run 20 customer interviews; grow revenue |

Nothing here is wrong in intent. The problem is that at the end of the quarter nobody could say whether it worked. "Best" has no measure. Four of the six key results are things the team will do, not things that will change. "Improve NPS" and "grow revenue" have no baseline, no target and no date. And "grow revenue" is a company outcome no single product team controls.

Each step below fixes one of those gaps. Every number in the Ledgerly example is illustrative.

## Why start with a baseline and a do-nothing trend?

A target only means something relative to where the number would have gone without you. Before writing a key result, pull three values for the metric: where it is today, where it was two or three periods ago, and where it will land by the deadline if the team changes nothing.

Ledgerly's onboarding metric is the share of new firms that send their first invoice within 7 days of signing up.

| Value | Share of new firms invoicing within 7 days |
|---|---|
| Two quarters ago | 44 percent |
| Today | 39 percent |
| Do-nothing projection, end of next quarter | 36 percent |
| Target | 50 percent |

Against today's value, 50 percent looks like an 11-point gain. Against the do-nothing line it is a 14-point swing, because the metric is falling on its own. The reverse also happens: a metric already rising at 2 points a quarter makes a 2-point target a key result the team hits by standing still.

The projection is a straight-line estimate, not a forecast. It ignores seasonality and anything the market does next quarter. What it still gives you is an honest reference line, and it forces the question every target should answer: how much of this change will be ours?

## How do you rewrite an objective as an outcome?

A good objective is significant (it would matter if it happened), concrete (an outsider could tell whether it happened), action-oriented (it points the team at something to change) and motivating to the people doing the work. "Be the best invoicing tool for accountants" fails the concrete test. "Improve onboarding" passes action-oriented but is too vague to be significant.

The rewrite asks what "best" or "improved" would look like for a customer:

- O1 becomes: **New firms get paid through Ledgerly in their first week.**
- O2 becomes: **Firms that start invoicing keep invoicing every month.**

Both are outcomes a customer would notice. Neither names a feature, so the team is still free to find the route. For more on keeping the route out of the objective, see [objectives, not tasks](https://builderscamp.com/guides/other/objectives-not-tasks).

## How do you turn key results into numbers?

A key result needs to be specific, time-bound, measurable, verifiable by someone outside the team, and ambitious without being fantasy. The re:Work guide gives a quick test for the activity trap: "If the KRs include words like “consult,” “help,” “analyze,” “participate,” they’re describing activities." "Ship," "launch" and "run" belong on the same list.

For O1, the setup checklist and the recurring-invoices launch were ideas about how to move the number. The key results become the number itself:

| Before | After |
|---|---|
| Ship a new setup checklist | Share of new firms sending a first invoice within 7 days rises from 39 to 50 percent by 30 June |
| Launch recurring invoices | Median time from signup to first paid invoice falls from 11 days to 6 by 30 June |
| Improve NPS | Setup-related support tickets per 100 new firms fall from 18 to 10 by 30 June |

"Run 20 customer interviews" moves off the OKR entirely. It is a good plan for learning why firms stall, which makes it an initiative that serves a key result, not a key result.

## Why stack-rank objectives and key results?

Ranking decides what happens when the quarter goes badly, which it usually does. If O1 and O2 both slip and there is capacity to rescue one, the team should not have to hold a meeting to decide which.

Ledgerly ranks O1 above O2: a firm that never sends a first invoice cannot become a firm that keeps invoicing. Within O1, the 7-day invoicing rate is ranked first because it is the key result the other two feed. The ranking also shows what to drop. "Redesign the dashboard" appears nowhere in the ranked list, which is a decision, and a better one to make now than in week 9.

## Who owns each key result, and by when?

Give every key result one named owner and one date. The owner reports the number at each check-in and raises the alarm when it stalls; they do not have to do all the work. A key result owned by "Product" or "the growth squad" is owned by nobody.

Dates matter even inside a quarter. If median time to first paid invoice depends on a payments integration that lands in week 8, a 30 June date for that key result is fiction. Moving it to a date after the integration, or splitting it into a leading measure due earlier, keeps the set honest.

## How do you stress-test a key result before committing to it?

Every key result is a rule, and people follow rules to the letter when the letter is easier than the spirit. The last draft pass is a gaming check: for each key result, write down the cheapest way to hit the number that makes the product worse. Ledgerly's three looked like this:

- **Share of firms invoicing within 7 days:** the team could auto-send a zero-value test invoice during setup. Fix: count only invoices with a real client and an amount above zero.
- **Median time to first paid invoice:** the team could push trial firms to invoice themselves. Fix: exclude invoices where sender and recipient share an email domain.
- **Setup tickets per 100 new firms:** the team could make the help link harder to find. Fix: pair it with a guardrail key result that setup completion does not fall below its current value.

Four more questions catch what the gaming check misses. Would 1 firm sending 50 invoices count the same as 50 firms sending one? If the planned feature turns out to be bad, would this number still tell you? What benchmark says the target is ambitious rather than easy? And if the key result is hit, where does the freed effort go next? A key result that survives all five is one you can defend at the end-of-quarter review.

## What does the finished OKR set look like?

| Rank | Objective | Key result | Owner | Date |
|---|---|---|---|---|
| 1 | New firms get paid through Ledgerly in their first week | Share of new firms sending a first real invoice within 7 days: 39 to 50 percent | Onboarding PM | 30 June |
| 1 | | Median signup to first paid invoice: 11 days to 6 | Payments engineering lead | 30 June |
| 1 | | Setup tickets per 100 new firms: 18 to 10, with setup completion at or above today's rate | Support operations lead | 30 June |
| 2 | Firms that start invoicing keep invoicing every month | Share of firms invoicing in each of their first 3 months: 58 to 68 percent | Retention PM | 30 September |

Compare it with the draft. Every row can be scored by someone outside the team, nothing in it describes a feature, and the ranking tells the team where to spend a bad week. For how OKRs sit next to the health metrics you track all year, see [OKR vs KPI](https://builderscamp.com/guides/glossary/okr-vs-kpi); for how a set like this should connect to the company's own OKRs, see [cascading vs aligning OKRs](https://builderscamp.com/guides/other/cascading-vs-aligning-okrs).

## When is this much refinement too much?

The strongest objection is time. A six-person team drafting two objectives does not need a formal gaming review for every key result, and a quarter spent perfecting OKRs is a quarter not spent moving them. For a small team, the baseline check and the outcome rewrite catch most of the damage; owners and ranking can be a five-minute conversation.

The refinement earns its cost in two situations: when OKRs are shared across several teams, where a vague key result turns into weeks of argument, and when a number will be reported upward, where a gamed metric does real harm. The re:Work guide also warns against reading every miss as failure: for stretch OKRs it puts the sweet spot at 60 to 70 percent attainment, and treats low grades as data for the next cycle.

## Where can you practise writing OKRs?

If you want a first draft to refine rather than a blank page, [AI for OKRs](https://builderscamp.com/guides/tools/ai-for-okrs) shows how to get an AI assistant to produce one and where it tends to go wrong. For the basic definition, see [what is an OKR](https://builderscamp.com/guides/glossary/okrs-objectives-key-results).

[How to Design OKRs](https://builderscamp.com/bootcamps/how-to-design-okrs) is a one-week bootcamp with 6 microlessons, directed by Andre Albuquerque and part of the Product Leadership Track. Its published topics include objective crafting, key results that measure progress, initiatives versus outcomes, alignment across teams, cadence and scoring, and common failure modes such as vanity OKRs, unowned key results and metric overload. Its practical challenge hands you a company's rushed quarterly OKRs, with vague objectives and output key results posing as outcomes, and asks you to fix them before an all-hands; the [write-up of that challenge](https://builderscamp.com/guides/challenges/how-to-design-okrs-fixing-broken-okrs) walks through it.

Builders Camp runs live and self-paced bootcamps in product management and AI product building. See the How to Design OKRs bootcamp for dates and the full syllabus.

## Frequently asked questions

### What makes an OKR good?

An objective that names an outcome someone would notice, and two to four key results that each have a current value, a target, a date and an owner. Anyone reading the set should be able to tell, at the end of the quarter, whether it was hit without asking the team.

### How many objectives and key results should a team have?

Google's re:Work guide recommends three to five objectives with about three key results each. For a single product team in one quarter, fewer is usually better: two objectives you actually rank beat five you treat as equal.

### What is a do-nothing trend in OKRs?

It is where a metric would end up by the deadline if the team changed nothing, projected from its recent direction. Setting the target against that line, not against today's value, stops a team claiming credit for a number that was already rising, or hiding a decline it slowed.

### Should key results include launching features?

Rarely. A launch is an activity, and a key result should describe the change the launch was meant to cause. Keep genuine delivery commitments on a separate list so nobody mistakes shipping for success.

### How do you stop a key result being gamed?

Before you commit to it, ask how someone could hit the number while making the product worse, then add a guardrail key result or reword the metric so that route no longer counts. A per-account measure, for example, stops one heavy user inflating a total.

### Who should own a key result?

One named person, not a team or a function. The owner does not do all the work; they are the person who reports the number at every check-in and raises the flag when it stalls.

### How ambitious should a key result be?

It depends on whether the OKR is a stretch or a commitment. Google's re:Work guide puts the sweet spot for stretch OKRs at 60 to 70 percent attainment; a committed key result, such as a contractual date, should be met in full.

## Sources

- [Google re:Work: Set goals with OKRs](https://rework.withgoogle.com/intl/en/guides/set-goals-with-okrs)
- [Ryan Panchadsaram, What Matters: What is an OKR? Definition and Examples](https://www.whatmatters.com/faqs/okr-meaning-definition-example)

## How this guide was made

Researched from Builders Camp's bootcamp, track and masterclass material and the sources listed on this page, drafted with AI, and fact-checked against every source cited.