I have reviewed hundreds of OKRs. Most are bullshit, and not because teams do not care. When you sit down to write OKRs, the default gravitational pull is toward output. You start thinking about what you are going to build, not what will change as a result. OKRs should describe the future state of your business or your customer. They should not describe the project plan.
The behavior change test
Here is the litmus test for a real OKR: if your key result were achieved, how would the behavior of your customers, users, or business actually change? If the answer is we will have shipped the thing we planned to ship, it is a task. If the answer is we cannot describe what changes, it is too vague.
Watch the difference. Bad: objective improve mobile experience, key result redesign mobile navigation. What changes? The navigation looks different. That is it. Good: objective increase time-to-value on mobile, key result reduce onboarding time for mobile users from 8 minutes to under 4, key result increase session frequency from 1.2x weekly to 2x weekly. Now new users see value faster and come back twice as often. That is a behavioral change you can measure and know whether you hit or missed.
Cascade through outcomes, not work
The common cascading mistake is subdividing work. Company OKR: increase 30-day retention from 50 percent to 60 percent. Wrong product OKR: build churn-prevention features, ship three anti-churn features. That makes product responsible for a task, not an outcome. Right product OKR: reduce friction in power-user workflows, key result increase session frequency for power users from 3x to 5x per week. Product is still responsible for retention, but through its own outcome, and the specific solution is up to the team. The rule: if your function owns a metric, you own the OKR. If you are just helping another function hit theirs, you contribute, you do not create a cascading OKR.
Calibrate and use them to decide
Keep it to 3 to 5 objectives per function, max 3 to 4 key results each. OKRs should be ambitious but achievable. Hit 70 to 80 percent and you are calibrated. Hit 100 percent and you are sandbagging. Hit under 50 percent and either the targets were theater or execution broke down. Run weekly 15-minute check-ins that are decision meetings, not status meetings: on track, at risk because X, learned Y, should we adjust.
The whole point is that OKRs are a decision-making tool, not a planning artifact. When someone pitches a new project or asks for headcount, you say: does this help us hit our current OKRs? If yes, fund it. If no, decline. Write good OKRs and most prioritization conversations get shorter, because the answer is visible in the key results. This week, take one OKR you already have and run the behavior change test on it. If you cannot name the behavior that shifts, rewrite it.