Product Planning, OKRs, & Harry Potter
My first exposure to OKRs was not love at first sight. Far from it. I thought they were too complex, too rigid, too bureaucratic. What about just getting smart people together and letting magic happen? But over the years, I’ve been converted. Now, I’m a true believer in OKRs.
Done well, OKRs can drive success across all functions, for companies small and large. I’ve found them particularly useful for product teams, where cross-team dependencies are complex and focusing on the wrong metrics can be disastrous. Great planning processes are critical to great product management, and OKRs are the best framework I’ve seen for medium and long-term planning.
If you’re not naturally scintillated by planning frameworks, your eyes may be starting to glaze over (mine were, when I first heard about OKRs). So, to keep things interesting — and show how universally applicable OKRs are — I’ll be relying on Harry Potter and Albus Dumbledore to illustrate the points in the rest of this post.
What are OKRs and why should I care?
O is for objectives, and KR is for key results.
Objectives are the starting point, and everything flows from them. Objectives should be unambiguously important, ambitious, and maybe a bit vague. They’re like a mission statement; the end state may be unattainable, but making progress towards it is still very motivating. Every team should should have at least one objective, and normally no more than three.
KRs are the metrics by which a team measures progress towards an objective. Every objective will have one or more KRs. They provide precision and definition. Without KRs, there is no way of reliably measuring progress towards an objective.
Dumbledore’s objective is big, ambitious, and kinda vague, while his KRs are specific and measurable.
OKRs should cascade down the org chart. One team’s KR can be another team’s O. For example, Harry Potter and Newt Scamander (separate teams, within the same organization) both support Dumbledore’s objective, but align with different KRs:
Principles of KRs
Good KRs have 4 attributes:
- Business relevant: ties directly to an objective
- Low latency: time between action and measurement is small
- Easily understood: all relevant stakeholders understand the definition
- High fidelity: what is measured is what is intended to be measured
In the first draft of his quarterly OKRs, Harry doesn’t do very well:
- KR1: Most assaults in dodgy parts of London aren’t related to Death Eaters. This is not high fidelity.
- KR2: Equipping a wizard to battle Voldemort takes a long time, it can’t be done in 1 quarter. This is too lagged.
- KR3: Gaining parseltongue fluency can help Harry recruit Death Eaters to his side, but it’s also a hallmark of dark magic. Harry’s stakeholders are going to be confused by this metric. This is not easily understood.
- KR4: Harry has a personal interest in dating Cho Chang , but it won’t reduce death eater attacks. This is not business relevant.
His second draft is much better:
Initiatives are not KRs
Everything we’ve talked about so far is either about vision (objectives) or metrics (KRs). But what about the work that needs to get done to move those metrics? This is where initiatives comes in (aka epics, projects, workstreams, etc.)
Initiatives are inputs; they feed KRs. Completing an initiative is not the same as improving a KR.
The link between an initiative and a KR is a hypothesis. Sometimes we have high confidence that if we complete an initiative it will move the KR (e.g. a strong hypothesis). Sometimes we have low confidence, but high upside, so the initiative is still worth pursuing (e.g. we’re not sure this will move the KR, but if it does move it, it could move it a lot). If we have low confidence and a low expected effect size, we shouldn’t pursue the initiative.
Harry scopes three initiatives to advance KR1. Note that none of these are guaranteed to reduce Death Eater attacks, but it seems reasonable that if the initiatives are successfully completed, it should have that effect. (We’ll return to the question of improvement magnitude soon.)
We measure initiative completion with milestones: was the initiative completed by the specified data with the specified acceptance criteria? This is different from KRs, and both are important:
- A team hitting milestones but not improving its KRs is making bad bets.
- A team missing milestones but improving its KRs is getting lucky.
Setting Targets
If you’ve read this far, hopefully you’re sold on setting KRs. So how should you set targets for those KRs? By target, I mean the amount you’re “signing up” to move the KR over a period of time (normally a month, quarter, or year).
I strongly recommend setting KR targets bottom-up, by summing up the expected benefit of each initiative. This requires having an expected benefit (aka an “impact sizing” in product manager speak) when you’re doing planning. That’s more work, but it’s worth the effort, because it avoids the common failure mode where top-down expectations and bottom-up efforts fail to meet.
For Harry, he estimates that his three initiatives mapped to KR1 will decrease Death Eater attacks by 5%, 3%, and 2% respectively. That sums up to only 10%. He needs to revise KR1 down from 20% improvement to 10%.
But what if the business needs more than a 10% reduction in Death Eater attacks by the end of the quarter? Harry needs to scope more initiatives against this KR, which means (i) de-prioritizing other initiatives or (ii) increasing staffing for his team. What he absolutely should NOT do is set a KR target that he doesn’t believe he can hit based on the initiatives and associated expected benefits he’s scoped.
The OKR planning process is mean to highlight the tension between what the business needs (top down) and what scoped initiatives can reasonable deliver (bottom up). It forces staffing and other resource reallocations where there’s a discrepancy. That’s a feature, not a bug.
Final thoughts
Be Flexible
Business needs change outside of planning cycles. Product managers need to change their OKRs to reflect that. Objectives probably don’t change that frequently, but in a well-functioning system, it’s not uncommon to change a few KRs and initiatives mid-cycle. The important thing is to document changes and the reasoning behind them.
Health metrics
What about KRs that matter, but where you’re not investing in any initiatives and it’s ok not to improve them? There’s a name for this: health metrics, aka KRs where the goal is just to monitor and maintain the metric. You only allocate resourcing to them if they start to degrade.
Scalar KRs are generally better than binary KRs
Binary KRs tend to look suspiciously similar to milestones (“We shipped this feature”), rather than focusing on the amount of new customer or business value created (which is rarely binary)
Want to learn more
Check out John Doerr’s Measure What Matters. It’s basically the bible when it comes to OKRs, and most of my thinking is inspired by it.
