OKRs — the discipline of saying no.

OKRs are the most photographed and least understood framework in modern product management. Every team uses them. Most teams use them badly. The pattern is familiar. Someone reads Measure What Matters, the leadership team holds a workshop, a Notion page is filled in, the OKRs are reviewed once at the end of the quarter, and the same teams continue doing what they were going to do anyway. The framework gets blamed. The framework wasn't the problem. The framework, when used as intended, is a discipline of saying no — and most organisations are bad at saying no.

Used well, OKRs are a forcing function. They make it impossible for everyone to be working on everything. They make it visible when a team is busy without being impactful. They translate where we want to go into what would convince us we got there. The discipline is unglamorous and short. Three or four key results per objective. Three or four objectives per team. Quarterly cadence. That's it. The trouble is what happens between the words.

The lineage — Grove, Doerr, Google.

The framework's origin is worth knowing, because the original context still tells you how it's meant to work. Andy Grove, then at Intel, developed it in the 1970s as a successor to Peter Drucker's MBOs (Management by Objectives). Grove's contribution was the discipline of pairing the objective with measurable results: not "improve quality" but "reduce defects by 40%, achieve quality cert in three production lines, complete 90% of customer-reported issues within 24 hours". The objective is qualitative and inspirational. The Key Results are quantitative and unambiguous.

John Doerr learned the framework as an Intel employee under Grove, then took it to Google as an investor in 1999. The story he tells in Measure What Matters (2018) is how Larry Page and Sergey Brin adopted it, and how it underwrote Google's scaling discipline. From Google it spread through Silicon Valley and eventually mainstream: through Doerr's site What Matters, through the book, through every product management course since.

The anatomy.

An OKR has two parts.

• The Objective. Qualitative, ambitious, memorable. The destination, stated in plain English. Be the most-recommended commuter cycling app in London. The objective is supposed to be inspirational. If it doesn't feel slightly hard to commit to, it isn't ambitious enough.
• The Key Results. Three to five. Quantitative, outcome-focused, measurable. Each one, on its own, would constitute strong evidence the objective is being achieved. NPS above 60 from active users. 50% of new sign-ups come from referral. 75% of users complete at least three rides per week.

The hardest test of a well-written Key Result: could the team achieve it by doing the wrong thing? If the answer is yes, it's an output, not an outcome. Ship the redesign by Q3 is a task. Reduce time-to-first-action from 90 seconds to 30 seconds is a result. Same project, two completely different framings.

Cascading, parallel, and the sandwich.

The single most common implementation question: how do OKRs flow through the organisation? Three patterns exist.

• Strict cascading. Company OKR set first. Each department picks OKRs that contribute to the company's. Each team picks OKRs that contribute to the department's. Clean hierarchy, low ambiguity, easy to communicate. Risk: bottom-up insight gets lost, and the organisation becomes top-heavy and slow.
• Parallel. Each level sets OKRs independently, but in a shared session. Company OKRs and team OKRs are negotiated in the same room. More adaptive, fewer translation losses. Risk: teams set OKRs that drift from company priorities.
• Sandwich. Leadership sets the strategic direction; teams propose OKRs bottom-up that respond to it; leadership and teams meet in the middle to negotiate. Most organisations end up here, even if they started somewhere else. It's the realistic compromise.

The "key result is a task" anti-pattern.

The most common failure mode by an order of magnitude. The objective says improve activation; the Key Result says ship the new onboarding flow by 30 September. That isn't a Key Result. That's a deliverable. The team can ship the new flow on 29 September and discover activation got worse, and they'll have hit the KR.

The fix is mechanical. Every Key Result must be a measurable change in user, customer or business behaviour. If you can swap the verb from ship, launch, build, deliver, roll out to increase, reduce, achieve, maintain, you've moved from output to outcome. Reduce time-to-activation from 7 days to 2 days is a Key Result. The new onboarding flow is one possible bet to achieve it, and if the bet doesn't work, the team should pivot.

The "every team has its own OKRs and they don't ladder" anti-pattern.

The second most common failure. Each team writes OKRs that are sensible in isolation. Marketing's OKR is to drive demos. Sales's is to close ARR. Product's is to ship features. None of them connect, and the leadership team has no way to see whether collective effort is moving the company. This is OKRs as a status-report tool, not as a prioritisation tool.

The test: look at every team OKR for the quarter, side by side. Pick the company OKR. For each team OKR, ask: if this team hits this OKR, does the company OKR move? If the answer is "no" or "marginally", the team is busy with the wrong thing, however virtuous their work feels. The ladder is the entire point of the framework. Without it, OKRs are decorative.

Setting — 60-70% is the goal.

Doerr's specific guidance, learned from Grove: a properly ambitious OKR should be hit at roughly 60 to 70%. Hit 100% and the objective wasn't ambitious enough; hit 30% and either the team got the bet wrong or the objective was unrealistic. The number itself isn't sacred, but the principle that OKRs are stretch, not sandbag is.

This is the bit organisations new to OKRs find hardest. If performance is tied to hitting OKRs, every team will sandbag: set OKRs they're sure to hit, deliver 100% scores, congratulate themselves. The framework dies in that moment. The fix is to de-couple OKR achievement from performance reviews. OKRs are about ambition and learning; performance reviews are about value delivered. Mix them and you destroy both.

The OKR theatre problem.

The end-state failure mode is OKR theatre. The org spends a week per quarter writing them, a week per quarter scoring them, and zero weeks per quarter using them to make decisions. The OKRs exist in a Notion page; the actual work is decided in standup, in roadmap meetings, in whatever-the-CEO-asked-for-last-Tuesday. The OKRs and the work have drifted so far apart that one is a fiction.

The fix is small and habitual. Open every monthly review with the OKRs. Ask: where are we, and what should change? When new work appears mid-quarter, ask: which OKR does this serve? If none, either the new work is wrong or the OKR is wrong. Pick one. Both being wrong simultaneously is fine; OKR theatre is what happens when you pretend they're both right.

Where this lands at Product Pieces.

When we run the Strategy Set Piece, OKRs come out of the room, not as a Notion template but as a conversation that ended with three or four sharp Key Results per team, ladders up to a company objective, and a written rule for what we'll do when something else important arrives mid-quarter. The output you keep is the ladder, not the language. The conversation that built it is what makes the framework stick.

If your organisation has the symptom (OKRs reviewed once a quarter, ignored for the other thirteen weeks, treated as homework rather than as a steering mechanism), the missing piece is the cadence, not the template.

Next issue: N°19 — Lean Startup. Build, measure, learn, and what the framework actually claims.