OKR stands for Objectives and Key Results. An objective is what you’re trying to achieve, stated so a team can rally around it. Key results are the measures that say whether you achieved it — quantified, time-bound, and hard enough that hitting every one is not a foregone conclusion.
The framework came out of Intel under Andy Grove and reached most of the industry through John Doerr, who took it to Google and later wrote Measure What Matters about it.
Most teams can write OKRs. The part that fails is what happens next: the objective is agreed in a quarterly meeting, the key results go on a slide, and everyone returns to a backlog with no visible relationship to either. This guide covers writing them, and then the harder half — getting them into the work.
What are OKRs?
Objectives are qualitative and directional. “Make onboarding something a new customer can finish alone.” They’re meant to be motivating and slightly uncomfortable.
Key results are quantitative and falsifiable. “Sixty percent of new workspaces create a board in the first session.” A key result you can’t measure isn’t one, and neither is a task with a checkbox.
The distinction that does the most work: a key result describes changed behavior, not completed work. “Ship the new onboarding flow” is a task — you can do it and change nothing. “New customers reach their first board without contacting support” is a key result, because it can turn out to be false after you ship.
Two consequences follow. “Done” stops meaning delivered and starts meaning the number moved. And you can no longer claim success by pointing at output — which is uncomfortable, and the entire point.
Why teams use them
- Strategy becomes executable. OKRs don’t set direction; they translate it. If the company strategy is expansion into mid-market, the objective says what that means this quarter.
- Ambition gets permission. Set targets where 70–80% is a good result, and teams attempt things they’d never commit to at 100%.
- Impact becomes the measure. The question shifts from what shipped to what changed for a customer.
- Everyone can see the same target. Published OKRs let a team say no to work that doesn’t serve one — in practice, most of their value.
OKRs vs other goal frameworks
| Framework | Origin | Focus | Reach for it when |
|---|---|---|---|
| OKR | Andy Grove at Intel; popularized by John Doerr | Ambitious outcomes, measured | You want stretch goals tied to observable change |
| SMART | George Doran | Specific, measurable, time-bound targets | The goal is concrete and the path is known |
| V2MOM | Marc Benioff at Salesforce | Vision, values, methods, obstacles, measures | You need alignment and obstacles named in one artifact |
| BHAG | Jim Collins and Jerry Porras | One inspiring long-range goal | You’re setting a decade of direction, not a quarter |
| MBO | Peter Drucker | Cascading objectives tied to performance | Individual accountability is the point |
| Balanced Scorecard | Robert Kaplan and David Norton | Financial, customer, process, learning | You’re measuring organizational health broadly |
The practical difference is ambition and honesty. SMART goals are designed to be met; OKRs are designed to be attempted. A team that hits 100% of its key results every quarter is setting them too low, which is a sentence worth repeating in the room where they’re written.
How to write OKRs that survive contact
Start with strategy, not goals. OKRs are execution tools. They translate a strategy that already exists — if nobody can state the strategy, the OKRs will be a wishlist with numbers attached.
Write objectives people would repeat. If nobody can say it from memory two weeks later, it won’t steer a decision.
Make key results about behavior. Ask what a customer would do differently if you succeeded, then measure that. Product metrics are where the candidates come from.
Time-box them. A key result without a date can’t fail, so it never forces a decision.
Align in both directions. Vertically, team OKRs should ladder to the organization’s. Horizontally, check them against the teams next to you — most OKR collisions are two groups quietly depending on the same people.
Keep the set small. Three objectives with three key results each is the outer edge of what a team can hold. Beyond that you have a list, and a list can’t prioritize.
Whose result is it?
Story mapping gave the industry outcomes over output: judge a release by what changes, not by what ships. That was the right correction, and it worked.
But look at how outcomes actually get written a decade later and they nearly all measure the same thing — us. Activation, retention, conversion, revenue. Every one is a statement about how the company is doing, wearing the costume of a user behavior. “Outcome” quietly came to mean “business result we’d like.”
There’s one more move, and we think it’s the one that matters. Kathy Sierra makes the case for it in Badass: Making Users Awesome: don’t ask what changes for you. Ask what the person can now do that they couldn’t do before.
| Instead of | Try |
|---|---|
| Activation rate up 20% | Users produce a publishable result in their first session, without help |
| Feature adoption up 30% | Users reach their first genuinely good outcome three times faster than today |
| Retention up 10 points | Users can do the core task of their domain reliably, not just once |
The objective changes shape too. Not “improve onboarding” but something closer to help more people get good at this, faster.
This isn’t softer language, it’s a different bet. Nobody wants to be good at your product. They want to be good at the thing your product is for — photography, running a team, shipping code without fear. Your product is a supporting character in a story about someone else’s competence, and every durable business number is a side effect of that person getting better at their work.
Two things follow, and both are useful in a room full of proposals:
Aim at what Sierra calls the suck threshold. Somewhere in every journey is a step where people have invested enough to feel committed and are still bad enough to feel stupid. That’s where they stop, and it’s rarely where your funnel says the problem is. Those moments are identifiable on a map, and they’re where a release should go first — getting someone from I can’t do this to their first real success is worth more than anything you could add for people who are already competent.
Ask whether the user ends up smarter or dumber. It’s a blunt question and it kills a surprising number of features. Anything that makes someone feel stupid — even briefly, even while technically working — is costing you the thing you’re actually selling.
The uncomfortable version: it’s possible to move every metric on your dashboard while the people using your product get no better at their work. That’s a business you have to keep buying customers for.
Where OKRs die
Almost never at the writing stage. They die in translation.
The objective is agreed. The key results are written down. Then the work is planned in a different artifact — a backlog, a sprint board, a roadmap — that has no place to record which key result a story serves. Nobody rejects the goal. It simply never becomes work.
Three months later the review asks whether the number moved, and the honest answer is that nobody could have said, at any point in the quarter, which of the things being built were supposed to move it.
The gap is structural rather than cultural. A ranked list can hold one ordering, and it’s already using that ordering for delivery sequence. There’s nowhere in it to say this group of stories exists to change this behavior.
Connecting OKRs to a story map
A story map has the structure a backlog is missing. Activities run left to right as the user’s journey; stories hang beneath them; horizontal release slices cut across the whole map to group the stories that together deliver one thing.
That structure works in both directions. The map is where key results come from, and the slice is where they end up.
Harvest key results from the map
The harder direction is writing key results in the first place. Teams stare at a blank page and produce something abstract, or something that’s secretly a project.
The map solves this, and the reason is almost embarrassing once you see it. Every card on a story map is a short action phrase — “sign into my account,” “put an item in the shopping cart,” “select credit card for payment.” Those aren’t tasks. They’re customer behaviors. And a key result is a statement about changed customer behavior.
So as Jeff Gothelf puts it in OKRs and User Story Mapping, every element of the backbone, and every activity grouping above it, is a potential key result. You don’t write them from nothing. You walk a map you already built and pick.
Picking is the work, and two criteria do it:
- What’s strategically important to the company right now. Not everything on the map matters this quarter.
- Where this team can actually have impact. A behavior you can’t influence isn’t a key result, it’s a wish.
If getting an item into the cart is both a known bottleneck and a company priority, that behavior — made measurable — is your key result. It came off the wall, phrased in the user’s terms, with the whole journey around it for context.
Read the backbone a second time looking for suck thresholds — the steps where people get stuck, feel stupid, and stop. Those are the highest-value key results available to you, because a journey nobody finishes has no downstream metrics to improve. The map makes them visible in a way a funnel report can’t: you can see what the person was trying to do at the moment they gave up.
There’s a second benefit that’s easy to miss. If the map was built collaboratively, the team is setting its own goals rather than receiving them — and doing it inside the system they’re actually building, instead of making what Gothelf calls “disembodied” decisions out of context. That’s the condition under which OKRs tend to work at all.
Jeff Patton and Gothelf have taught this pairing together in a joint workshop, the clearest sign that these two practices were built for each other, not bolted together.
The reverse direction works too. If the key result arrives from above, walk the backbone and ask at each step what would stop someone — each answer is a story in the column where the problem happens. You’ll usually find the work isn’t where you assumed. A key result about first-board creation often depends on stories under invite the team, because people don’t build alone.
Name the slice with the key result
In CardBoard a slice is a divider, and the divider’s name is the outcome’s name. So naming a slice and declaring what it’s for are the same gesture.
Name it “Q3, phase one” and you have a schedule. Name it “new customers reach their first board without contacting support” and the cards above that line are, visibly, the work that moves the number. The key result stops being a parallel artifact and becomes the label on a band of the board your team already looks at every day.
The test is uncomfortable and worth running early: if you can’t name a slice with any of your key results, the map and the goals are about different things. Better to find that out in week one than at the quarterly review.
Track progress on the same board
Once a slice carries a key result’s name, progress against it is legible without a report. The cards in the slice have status; connect them to their tracker items and status arrives on its own. Half the slice done is half the work that was supposed to move that number.
That’s a different signal than a percentage in a spreadsheet. It tells you which remaining stories stand between you and the change you’re trying to cause — and lets you make the call that matters mid-quarter: cut the rest of this slice, or cut something else to finish it.
Common pitfalls
Projects wearing objectives’ clothing. “Launch the mobile app” is a project. It says what you’ll do and not what should become true. Instead: ask what changes for a customer when it lands, and make that the objective.
Output masquerading as a key result. Anything measured in tickets, launches, or features shipped. Instead: measure what someone does differently after they ship.
No deadline, so no decision. A key result that can slip forever spins indefinitely. Instead: time-box it and let it fail. A failed key result you can learn from beats an open one you can’t.
OKRs that never reach the map. The most common failure, and the one this guide exists for. If no slice is named after a key result, the OKRs are a parallel artifact.
Too many. Nine objectives means none of them can be refused work.
Tied to compensation. Pay for hitting stretch targets and you’ll get conservative targets next quarter. Keep them separate from performance reviews if you want ambition to survive.
How often to review them
- Annually — objectives, roughly. The direction shouldn’t move every quarter.
- Quarterly — key results, set and scored. Long enough to move a number, short enough to correct.
- Weekly — a short check-in on where each key result stands. This is the cadence that keeps them alive; the quarterly review is too late to change anything.
- Mid-cycle — one honest look at whether a key result is still the right one.
If you run OKRs alongside sprints, put the check-in inside a ceremony you already hold rather than adding a meeting. The prioritization call in planning is the natural place: when two stories compete, the one inside a slice named for a key result wins.
Tools, and how CardBoard fits
Most OKR software is a scorecard: it stores objectives, key results, owners, and a percentage. That’s useful for reporting and does nothing about the translation problem, because the work lives somewhere else.
The connection has to exist where the work is planned. In CardBoard:
- A slice’s name is its outcome — so a key result names a band of the board rather than sitting in a separate tool.
- Cards carry status, and tracker links mean it arrives without anyone maintaining it.
- A card can belong to more than one outcome, so a story serving two key results can say so instead of being duplicated.
- Guests are free on every plan, including the free one — the people who need to see progress against a goal are rarely the people authoring the map.
If your OKRs currently live in a slide and your work lives in a tracker, the fastest way to close the gap is to build one map for one objective and name one slice after one key result. The user story mapping tool page shows what that looks like on a live board, or open a free workspace and try it against this quarter’s goals — three boards, no credit card, guests included.
Ninety minutes is enough to find out whether your key results survive contact with the journey they depend on.
Frequently asked questions
What is an OKR?
An OKR is a goal-setting framework pairing an Objective — what you want to achieve, stated qualitatively — with a small set of Key Results, the quantified measures that say whether you achieved it. It originated at Intel under Andy Grove and was popularized at Google by John Doerr.
What’s the difference between an objective and a key result?
The objective is directional and qualitative: what you’re trying to achieve. Key results are quantitative and falsifiable: the measures that prove it. A useful key result describes changed behavior rather than completed work, so it can turn out to be false after you ship.
How many OKRs should a team have?
Around three objectives with three key results each is the practical ceiling for one team in one quarter. More than that and the set can no longer be used to refuse work, which is most of what OKRs are for.
How do OKRs connect to a user story map?
Through release slices. A slice is a horizontal band grouping the stories that together deliver one thing, and naming that slice after a key result makes the cards above the line the visible work that moves the number. In CardBoard the slice’s name is the outcome’s name, so the two are the same gesture.
Should OKRs be tied to performance reviews?
Generally no. OKRs are meant to be ambitious, with 70–80% attainment counting as success. Tying them to compensation pushes teams to set targets they know they can hit, which removes the ambition the framework exists to create.
Written by Josh Colter, who owns and builds CardBoard — the story mapping tool featured in Jeff Patton’s User Story Mapping. CardBoard was created at DevJam by David Hussman’s team, whose Dude’s Law — value is why over how — is the same argument this guide makes about key results.
Last updated 16 August 2026.