How OKRs work (and don’t work) for Product Teams
How OKRs work (and don’t work) for Product Teams
In a recent discussion with Patrick Collins from Zip Money, he revealed they replaced roadmapping with OKRs. At Pointzi we’ve had several false starts with OKRs – so this deep-dive video is with OKR expert Sten Pittet of Tability.
Sten asserts that one of the main things people get wrong is making objectives to quantitative and making results a proxy for projects.
He said that Patrick nailed it by saying its OK to abandon a project during the 90-day period if it seems it will fail the Key Results you are seeking.
The diagram below explains the hygiene that Sten recommends. By adding the “Projects” ring, it reduces the usual confusion about key results. (He acknowledges he stole this and enhanced from Simon Sinek’s Begin with Why).
Specifically here the fixed-ness of Objectives and friction in changing Key Results. These are the stable business-centric goals that should NOT be schizophrenically changing after the last customer meeting or if the CEO has some genius new strategic lightbulb moment.
Sten does a great job framing these 3 levels, starting with these statements:
Related to impact you have on your customers.
and
Teams can double-down on projects that work
Objectives
The way you phrase the top-level objective has the potential to kill or inspire teams to launch projects to meet that objective – afterall people/teams naturally obsess over such a concise directive.
Bad example: “integrate with Stripe” – only related to dev team – can’t help Sales/Marketing get on with their work. The Key Result is also very binary: “Ship or Not Ship”.
Better Objective: Get Paid Customers. This empowers each team to flush out their own Projects:
Product: find a way to charge them (that might still be Stripe but it is in concert with other possibilities and team Projects)
Sales: what markets can I tackle?
Marketing: what initiatives will drive growth?
Support: how can we reduce churn or convert trial to paid?
Moving down to Key Results – these “really focuses the attention of people on what is important”. A sensible selection is not the binary Stripe result but Revenue. Suddenly things are quantitative and not binary – its more trackable.
In the bad example: The Product team say “we really need to ship that integration”.
In the good example: Marketing can get great progress by surveying customers on purchase intent. The big contrast here is that waiting 2 months for the Stripe integration won’t move the needle if there is NO purchase intent.
So the Stripe integration is downgraded to a Project. If that project looks like it will fail or run over the 90 period – the better OKR helps teams ask: “how can we charge people today?”, “can we do it manually” etc.
Bad OKRs can derail a company. Good OKRs align teams in achieving one big thing for the business.
The evolution of teams getting used to using OKRs and becoming more “outcome driven” looks like the picture below.
Projects then should change a lot, they are just “bets” on getting a better Key Result. He was impressed with Patrick’s comments:
Teams are autonomous and they can double-down on what’s working – if a specific project doesn’t lead us to a better Key Result, then we just kill it.
Sten thought this was a sign of a top team.
