Topic 16 — OKRs and goal-setting

Goal: Set measurable goals that connect strategy to the team's daily work.

Lesson 16.1 — The "are we winning?" question

It's the first Monday of the quarter, and Maya's CEO drops a strategy slide in the team channel: win small teams by being the simplest budgeting tool they've ever used. Everyone nods. It's a good line.

Then Maya stares at her own to-do list and realizes she has no idea what to do with it on a Tuesday afternoon. "Be the simplest" doesn't tell her which screen to fix first, or how she'd know in three months whether it worked.

That gap is what goals are for. A goal takes the strategy and turns it into a definition of success you can actually check this quarter. The strategy says "win small teams by being simplest." The goal makes it real: raise new-team activation from 40% to 60% by the end of Q2.

Now the team is pointed at the same thing, everyone can see whether they're getting closer, and Maya is on the hook for a number instead of a vibe.

Without a goal, a team can be busy for three months and never know if it's winning.

Goals are the bridge. Vision and strategy live up high; the roadmap and the daily work live down low; goals connect the two so the work actually ladders up to the direction.

Lesson 16.2 — What an OKR actually is

Maya doesn't have to invent a format. The most common one in tech is already sitting in half the docs at Lumi: OKRs — Objectives and Key Results.

An OKR is two parts stuck together.

The Objective is the inspiring, plain-language part. It says what you want to achieve, no numbers required. "Make new teams successful in their first week." It's meant to make someone want to do the work.

The Key Results are the honest part. They're 2–4 measurable outcomes that prove you actually hit the objective. "New-team activation rises from 40% to 60%." "Time-to-first-value drops from 3 days to 1."

Read together, an OKR is a small promise: we'll achieve this (objective), and we'll know we did because these numbers move (key results). The objective gets people out of bed; the key results keep everyone honest about whether it happened.

OKRs are usually set per quarter, and they cascade. The company sets its OKRs first, and team OKRs ladder up from those, so Maya's goals aren't free-floating — they trace straight back to the company strategy you saw in Topic 15.

Lesson 16.3 — The rule that matters most

Maya's first draft of key results reads: "Launch the new onboarding flow. Ship a welcome email. Redesign the setup screen." Three real pieces of work. She could finish all three by Friday.

And activation could stay at exactly 40%.

That gap is the difference between an output and an outcome. An output is something you do or ship: launch a flow, ship five features. An outcome is the change that work creates, like activation going up or churn going down. The single most important rule of goal-setting comes straight out of that distinction:

Measure outcomes, not outputs. Track the change you create, not the stuff you ship.

Output-based goals are sneaky because you can complete every one of them and have moved nothing for users or the business. (That's the delivery-vs-outcome trap from Topic 2, showing up again in goal form.) When you write key results as outcomes, you free the team to find the best way to hit them, instead of forcing them to build a specific feature whether or not it works.

The whole shift fits in two questions. Stop asking "did we ship it?" Start asking "did it work?"

Lesson 16.4 — What a good key result looks like

So what separates Maya's bad draft from a key result Sam would actually respect?

Start with the test he'd apply: could two people honestly disagree about whether you hit it? If yes, it isn't measurable enough. "Improve onboarding" fails on the spot — Maya and Sam could argue about it for an hour. "Raise day-1 activation from 40% to 55%" passes, because there's nothing to argue about.

A strong key result clears a few bars:

• Measurable. A real number, so hitting it isn't a matter of opinion.
• Outcome-based. A result, not a task (Lesson 16.3).
• Baseline and target. Written as "from X to Y," so you can see the progress along the way, not only the finish line.
• Ambitious but not impossible. OKRs are often stretch goals. In many OKR cultures, landing around 70% counts as success, and scoring a clean 100% every quarter is a warning sign that you set the bar too low. Know your own company's norm before you assume either.
• Few. Two to four per objective. A long list of key results is a wish list wearing a goal's clothes.

That stretch idea trips people up, so sit with it. If you always hit 100%, you probably aimed at goals you knew you'd hit. The point of a stretch goal is to pull more out of the team than a safe target would, even if you fall a little short.

Lesson 16.5 — Five ways OKRs go wrong

OKRs are easy to write and easy to ruin. These are the five Maya learns to watch for.

Output disguised as an outcome. "Ship feature X" wearing a key-result costume. It measures activity, not impact. This is the same mistake from Lesson 16.3, and it's the most common one.

Too many OKRs. Twelve "priorities" means zero priorities. If everything matters, the team has no way to choose when Tuesday gets crowded.

Sandbagging or impossible targets. Setting goals so easy a win is guaranteed (sandbagging) wastes the quarter. Setting goals so wild no one believes them just makes people stop trying. Both miss the point.

Set-and-forget. OKRs written once and never opened again do nothing. Review them on a rhythm (monthly is common) and adjust when reality shifts.

Gaming the metric. Chasing a number in a way that quietly harms the product. (This is the vanity-metric problem from Topic 9.) The fix is a guardrail: pair the target you're pushing on with a counter-metric you promise not to wreck.

Used well, OKRs hand a team a shared, measurable definition of success that connects the vision all the way down to the work, and tell everyone honestly whether they're winning. Used badly, they turn into paperwork nobody reads. Maya's job is to keep them few, outcome-based, and alive.

Worked example — Fixing a weak OKR

Maya's team brings her a draft, and on paper it looks fine.

Objective: Improve onboarding. Key results: Launch new onboarding flow. Ship a welcome email. Redesign the setup screen.

She reads it twice and spots the rot: every key result is an output. The team could do all three, high-five, and watch activation sit at 40%. The objective is also too vague to argue with — "improve" by how much?

So she rewrites it.

Objective: Make new teams successful in their first week. Key results:

• Raise day-1 activation from 40% to 60%.
• Cut time-to-first-value from 3 days to 1.
• Lift week-1 retention from 55% to 65%.
• Guardrail: support tickets don't rise.

Same ambition, completely different goal. Now the team is measured on the change, not the chores. The new flow, the welcome email, the setup redesign don't disappear — they become tactics the team might use to hit the numbers, instead of being the finish line themselves. And the guardrail means nobody can juice activation by shoving confused users through a flow that floods support.

That's the move: from a task list pretending to be a goal, to an honest, outcome-based one.