Here is a quarter that happens somewhere every three months. The team writes three objectives and eleven key results. Nine of the key results are things they were already going to build. They build them. At the review, the scores are excellent and the mood is flat, because everybody can see that activation is exactly where it was in January.
Nothing about the OKR format caused that. The format was applied to a list of planned work, which is the one thing it is specifically designed to replace.
Product OKRs are worth the effort when they force a team to state the change they intend to cause, separately from the things they intend to build. This guide covers how to write them that way: objective versus key result, tasks in disguise, output versus outcome, five writing rules, worked examples across four kinds of product team, the quarterly cadence, and the failure modes that quietly kill OKR programmes in year two.
Key Takeaways
- A key result is a metric, a baseline and a target. If it cannot be wrong, it is a task.
- One objective per team per quarter, with two to four key results. More than that is a to-do list.
- Prefer outcomes. Use an output measure only when the outcome genuinely cannot move inside the period — and record the assumption.
- Never tie OKRs to compensation. It converts ambitious targets into safe ones, permanently.
- 0.6–0.7 is a healthy score. A team scoring 1.0 every quarter is setting targets it already knew it would hit.
- The review is for learning, not grading. The two questions that matter are what you learned and what you would set differently.
What Are Product OKRs?
Product OKRs: definition
A product OKR pairs one qualitative objective — what the team is trying to achieve and why it matters — with two to four key results, numeric measures that will move if the objective is genuinely achieved. The objective supplies direction; the key results supply evidence. Crucially, neither names a feature: an OKR describes the change you want in behaviour and leaves the team free to find out what actually produces it.
Notice what is absent: any mention of a checklist, a tour, an email sequence or a redesign. Those are the candidate solutions, and the team will probably try several. The OKR is the bar those attempts have to clear.
Where OKRs sit relative to your other frameworks: a north star metric is the enduring measure of value your product delivers and does not change quarterly. The HEART framework helps you choose which metrics represent quality of experience. OKRs are the quarterly machinery for moving any of them. They are complements, not alternatives — and if nobody can explain how a key result feeds the north star, resolve that before the quarter starts, not at the review.
The Task Disguised as a Key Result
This is the whole game. A task in disguise is a key result whose achievement is entirely within the team's control and says nothing about whether users behaved differently. It is comfortable to write, easy to score and completely uninformative.
The test takes ten seconds: could the team hit this by working hard, with no user behaving any differently? If yes, it is a task. Tasks are fine — they belong on the plan, underneath the OKR, as the bets the team is making. They just should not be the measure.
The tell at the review: a quarter where every key result scored high and no product metric moved. If that happens twice, the problem is not execution — it is that the OKRs were a restatement of the roadmap, and the format is now costing you time while providing no information.
Output, Outcome and Input Measures
| Type | Measures | Example | Use in an OKR? |
|---|---|---|---|
| Output | What the team produced | Flow shipped, API endpoints delivered | Only under a genuine external constraint |
| Input | A behaviour the team can influence directly | Share of new users who see the checklist | Useful as a leading indicator alongside an outcome |
| Outcome | Changed user or business behaviour | Activation rate, week-4 retention, adoption | The default — aim here |
There are honest reasons to use an output key result: a compliance deadline, a platform migration whose benefit only materialises next year, a dependency you are unblocking for another team. When you use one, write the outcome you believe it will produce next to it. That way the assumption is on the record and can be checked later, rather than quietly disappearing into "we did the thing".
Input measures are underrated. A key result like "share of new users who reach the setup checklist rises from 40% to 80%" is not the outcome you care about, but it is fast to move, and pairing one input with one outcome gives the team something to steer by weekly while the outcome takes time to respond. The relationship between them is exactly what an onboarding funnel makes visible.
Five Rules for Writing Key Results
1. Always include the baseline
"Increase activation to 55%" is unreviewable without knowing where it started. Baselines also force a useful conversation before the quarter: surprisingly often, nobody can produce the current number, and discovering that is worth more than the OKR.
2. Name the exact population
Activation of whom? All signups, or self-serve signups excluding invited team members and internal accounts? Ambiguity here is where quarter-end arguments come from, and the definition should be written down where the number is reported, not in someone's memory.
3. Make it measurable on the day you write it
If instrumenting the metric is itself a project, you have two quarters of work: one to be able to see the number, one to move it. Say that out loud rather than pretending. The event tracking guide covers getting the measurement in place first.
4. Pick targets you are genuinely unsure about
The right feeling when setting a target is discomfort. If the team is confident of hitting it, the target is a forecast, not a goal — and a forecast dressed as a goal teaches the organisation that OKRs are theatre.
5. Add a counter-metric when the goal can be gamed
Almost every activation metric can be improved by making the definition easier, and almost every engagement metric can be improved by nagging people. Pair the goal with a guardrail — unsubscribe rate, support volume, week-4 retention — so that a hollow win is visible rather than celebrated.
Product OKR Examples
Four worked examples, one per common product-team shape. Adapt the metrics, keep the structure.
The platform example is worth a second look, because platform and infrastructure teams are the ones most often told that OKRs "don't apply to us". They do — the outcomes are just internal. Their users are other teams, and every measure above is about those users' behaviour rather than about work completed.
The Quarterly Cadence
Four moments, and the middle two are where programmes live or die.
1. Setting (two weeks before the quarter)
Draft, challenge, cut. The most useful part of the session is the list of things the team is deliberately not doing this quarter — write it down and keep it visible, because that list is what makes the OKR a priority rather than an aspiration.
2. Weekly check-in (fifteen minutes)
Current value of each key result, confidence out of ten, and one blocker. Fifteen minutes, standing up, no slides. Skipping this is the most common cause of the quarter where nobody looked at the numbers until week eleven.
3. Mid-quarter reset (week six)
Explicit permission to change a key result if the world changed — a competitor moved, a dependency slipped, the metric turned out to measure the wrong thing. Not permission to lower a target because it looks hard. Record what changed and why.
4. Scoring and retrospective (week thirteen)
Score quickly, then spend most of the hour on the two questions that matter: what did we learn about our users, and what would we set differently? A review that spends fifty minutes on arithmetic and ten on learning has the ratio backwards.
Where OKR Programmes Break
- Tying them to compensation The single most destructive thing you can do. The moment a score affects pay, every target becomes one the team is sure of hitting, and the format's entire value evaporates.
- Mechanical cascading Company objective becomes department objective becomes team objective becomes individual objective. What arrives at the bottom is unrecognisable and nobody owns anything. Align on direction; let teams write their own key results.
- Too many of them Seven objectives is a backlog. One objective, two to four key results, per team, per quarter. If everything is a priority, the team will simply do whatever was already scheduled.
- Metrics nobody can produce A key result whose number requires a data request and four days is a key result nobody will check weekly. Instrument first — see onboarding metrics for the ones worth having permanently available.
- Copying last quarter The same objective three quarters running usually means it was never really the priority, or the team has no lever on it. Either escalate it or drop it; do not renew it silently.
- Writing them for an audience OKRs written to look good to leadership optimise for defensibility, which is the opposite of ambition. If a team cannot say "we tried and it did not work" safely, they will never set a target worth having.
Product OKRs: Do vs. Don't
✅ Do
- Write one objective per team per quarter
- State a metric, a baseline and a target for every key result
- Define the exact population the metric covers
- Prefer outcomes; justify any output measure in writing
- Add a guardrail metric where the goal can be gamed
- Check in weekly, in fifteen minutes
- Write down what you are deliberately not doing
- Spend the review on learning, not arithmetic
❌ Don't
- Use "ship X" as a key result
- Tie OKRs to bonuses or performance reviews
- Cascade objectives mechanically down the org chart
- Set targets you are confident of hitting
- Choose metrics you cannot see weekly
- Carry the same objective silently into a third quarter
- Score generously to protect morale
- Confuse an OKR set with a roadmap
Moving Product Key Results Without a Release Cycle
A quarter is short. If every bet on your OKR requires an engineering release, you will get two attempts, and the second one lands in week eleven. The teams that move activation, adoption and retention numbers reliably are usually the ones that can run several attempts on the same screens without waiting for a build.
That is what a no-code guidance layer like Kompassify is for — and it maps directly onto the key results above:
- Activation key results A first-session onboarding checklist and a guided walkthrough, changed weekly against the number instead of once per quarter.
- Adoption key results In-app announcements and contextual hints targeted at the accounts that have not yet used the workflow — the fastest available lever on feature adoption.
- Retention key results Re-engagement flows aimed at defined dormancy segments, with the opt-out guardrail watched at the same time.
- The weekly number itself Step-level analytics on every flow, so the check-in has a current value rather than an opinion.
Kompassify is no-code, GDPR compliant and EU-hosted, free for under 100 monthly active users, with paid plans from $129/month.
Give Your Key Results More Than Two Shots a Quarter
Build and change onboarding flows, announcements and checklists in days instead of release cycles — and watch the number move while there is still time to act.
Start FreeFrequently Asked Questions
What are product OKRs?
Product OKRs are a goal-setting structure in which a product team states one qualitative objective — what they are trying to achieve and why it matters — and two to four key results, which are numeric measures that will move if the objective is genuinely achieved. The objective supplies direction and the key results supply evidence. What makes them different from a roadmap is that neither part names a feature: an OKR describes the change you want in user or business behaviour, leaving the team free to discover which build actually produces it.
What is the difference between an objective and a key result?
An objective is qualitative, memorable and directional — "new teams reach real value in their first session" — and it should be understandable by someone outside the team. A key result is numeric and falsifiable: a metric, a starting value and a target, such as "share of new workspaces completing a first project in week one, from 34% to 55%". If a key result cannot be wrong, it is not a key result. The usual test is whether you could tell, from data alone and without discussion, whether it was hit.
Why do most product OKRs fail?
Because the key results are tasks in disguise. "Ship the new onboarding flow" looks like a key result, is easy to write, and is guaranteed to be achieved by a team that ships the flow regardless of whether anything improved. A quarter of shipped tasks scored at 100% while the product metrics stayed flat is the single most common OKR pathology. The second most common is having too many: a team with seven objectives has a to-do list with a fashionable name, and no priority at all.
How many OKRs should a product team have?
One objective per team per quarter, with two to four key results. Teams that can genuinely justify two objectives should still expect one of them to be neglected, because a quarter is roughly nine working weeks after holidays and interruptions. The discipline is in what you leave out: an OKR set that does not force you to say no to something is not doing its job, and the most useful sentence in any OKR review is a list of what the team deliberately chose not to pursue.
Should key results be output or outcome measures?
Outcome wherever the team can genuinely influence one within the quarter. Outcome key results measure changed behaviour — activation rate, retention, adoption of a workflow. Output key results measure what the team produced, and they belong in an OKR only when a genuine external constraint makes the outcome unmeasurable in the period, such as a compliance deadline or a platform migration whose benefit only appears later. When you are forced to use an output key result, write down the outcome you believe it will produce, so that the assumption is on the record and reviewable.
Should OKRs be tied to performance reviews or bonuses?
No. The moment an OKR affects someone's compensation, they will set targets they are confident of hitting, which destroys the ambition the format exists to create. Teams then negotiate downwards during the target-setting conversation, and the organisation loses its most useful signal — the honest gap between where a team wanted to get and where it got. Keep OKRs as a planning and learning instrument, and assess people through a separate process.
How do you score OKRs at the end of a quarter?
Score each key result from 0 to 1 based on progress from its baseline to its target, average them for the objective, and treat 0.6 to 0.7 as the healthy range for ambitious goals. Consistent scores near 1.0 mean the targets were too safe; scores near 0 mean they were fantasy or the team was blocked. The score itself matters far less than the conversation it prompts, so budget most of the review for two questions: what did we learn about the users, and what would we set differently next quarter?
How do product OKRs relate to a north star metric?
A north star metric is a single enduring measure of the value your product delivers, and it does not change each quarter. OKRs are the quarterly mechanism for moving it. In practice the north star sits above the OKR set as context, and each team's key results should be inputs that plausibly feed it — if nobody can explain how a key result connects to the north star, that is worth resolving before the quarter starts rather than at the review.