The basic attributes of OKRs go like this:
- Your objectives should be inspiring – they’re setting the direction
- Your key results should be measurable – they’ll help you understand traction
This pairing is what makes the OKR framework effective by giving teams the ability to reflect on their execution with supporting data and evidence. You no longer have to fly blind for 3 months. The right set of key results will help you observe the impact of the bets that you made when setting your roadmap.
For instance, if a team’s objective is to “build an amazing onboarding flow”, then they use activation rate or week-2 retention in their key results to see if they’re improving during the quarter. This gives freedom to the team to try a lot of different things to move these metrics in the right direction. The OKR will focus on the outcomes, while the team can get creative with the outputs:
- They can try showing an onboarding video
- They can add tooltip
- They can try adding dummy data
- Etc
Each week passing they’ll be able to ship things, and study the new cohort to see if it had an impact on the metrics. This is great.
But what happens if your key result is an output?
I know, this is OKR blasphemy, but having strategic projects listed as part of your OKRs is just part of the reality of companies, and OKR-absolutism can be frustrating
That OKR “purism” that everything should be an outcome only is a waste of time."
Didier Elzinga - CEO @ Culture Amp (interviewed by Michael Batko)
Big projects can be KRs too
At its core, an OKR should capture what matters the most for you. And sometimes, what matters the most is to ship something on time. Delivering value to your customers isn’t just about moving NPS, CSAT, or retention metrics around. Teams often need to have 1 or 2 big bets going on that they’re committing to no matter what – and these bets can take months (or years) to come to fruition. And this is not just about building features! Strategic initiatives can also be about changing core infrastructure or adopting a new pricing model.
- It took 2 years for Adobe to go from launching Creative Cloud to making their new releases Cloud only.
- It took 2.5 years for Dropbox to move away from AWS for file storage.
These projects are huge commitments, and it would be strange to not include them in the company goals. So, it perfectly makes sense to see objectives like “complete our Cloud migration”, “launch our mobile app”, “become a platform by introducing a marketplace”
The challenge? There’s not much that can be measured before something is in the hands of customers. And if our KRs aren’t measurable, then we’re back to introducing significant risk in our execution because it will be difficult to understand if you’re making meaning progress.
Saying “we’re good” is not a compelling answer to “are we on track to deliver <secret project which is already a $Xm investment>?”
So, this post is here to help by offering a few options to set OKRs for long-term projects.
Case study 1: OKR for shipping a project - no internal testing possible
Let’s start with our first example. The general objective is to “Be on track for beta testing in Q2” as we’re just getting started in Q1, and we don’t have any features to test yet.
What should be our main key result?
I've asked that question to OKR expert Lawrence Walsh from There Be Giants, and he had a great suggestion: set your project as the key result, and define key milestones to measure progress (listen to the explanation here)
So, when there aren’t any good metrics to use, then the next best thing is to define your own success step. In our scenario, the OKR would be:
⛳️ Objective: Be on track for beta testing in Q2
- KR1: Deliver 100% of the mobile development milestones
And then, under KR1 we would define the milestones as follow:
- 0%: we haven’t done anything yet
- 10%: the CI/CD pipeline to build, test, and deploy the mobile app is ready
- 20%: we can authenticate users
- 30%: users can pull their personal data
- 40%: users can access their dashboard
- 50%: users can use core feature #1
- 60%: users can use core feature #2
- 70%: users can use core feature #3
- …
If you want to implement something similar at work, you can follow these steps with Tability 👇
- Go to the plan edit mode
- Add “Become a mobile-first business” as your objective, then add “Be on track for beta testing in Q2” as the key result underneath
- Click on the target field of your key result, and change the metric type to be “From x to y” and set the target to 100% and initial value at 0%
- Then add all the milestones using the initiatives – this will allow you to keep track of the status of the work
- That’s it! You can now go back to your plan dashboard.
Once you’re back in tracking mode, you will be able to see both the progress value of your KR, as well as the list of milestones in progress.
Case study 2: OKR for shipping a project - when internal testing is possible
Now let’s say that we managed to build an alpha version of our app. We have some of the core features, but there’s still a lot to do and polish before we can have the first set of customers on the app. If you have enough internal users in your company, then I would encourage you to use internal usage metrics for your key results.
If our mobile application is a note taking app, then our OKR would be something like:
⛳️ Objective: Have a successful mobile beta program
- KR1: 100 notes have been created by internal users
- KR2: We have 50 weekly active users on the alpha version of the app
- KR3: Notes have been shared 50 times
Of course, you can still use milestones if there are critical features to build, but the goal here is to start switching to measurable outcomes that are as close as possible from the benefits that your users would be getting.
One of the risks when you’re not tracking usage is that you’ll stop the definition of done at “we’ve shipped it”. But, we all know that there can be many little hiccups that get in the way of a good user experience. So, one way to make sure that your newly built app is usable is to track usage metrics.
Bonus points if you can attach some sort of quality metric to it (CSAT, NPS, etc) to raise confidence that you have something that people will enjoy using.
Case study 3: OKR performing a migration
The 3rd case study is what happens when you have projects that can take a long time to complete. For instance, you’re migrating customers from Google Cloud to AWS (or vice versa). It might be something that takes you a year to complete all together because there are 5,000 customers to move from one infrastructure to the other.
This scenario is actually easier to handle. You only need to understand how many customers you can migrate in each quarter. For instance your plan could be to:
- Migrate 500 customers in Q1
- Migrate 1000 customers in Q2
- Migrate 1,500 customers in Q3
- Migrate 2,000 customers in Q4
So, assuming that we’re in Q1. Our OKR will be:
⛳️ Objective: Complete the customer migration by end of the year
- KR1: Migrate 500 customers to the new Cloud
You don’t need to write the KRs for the upcoming quarter. We’ll focus first on achieving our goal of migrating 500 customers. Then, under that KR, you can list the strategic projects that need to happen:
- Provision the new Cloud
- Build migration scripts
- Complete test migrations
- Etc
Here we do our best to avoid listing too many projects in the KRs, because this is what initiatives under KRs are for. The more you focus your KRs on the end results (500 customers are migrated), the easier it is for people to understand what’s truly important.
Don’t be an OKR-absolutist
All frameworks are aspirational. It’s great when things can be measured, but there are plenty of situations where it’ll be hard to find relevant KPIs that you can use for your OKRs. The reality of companies is complex and you’ll often have to bend the rules to make things work.
What really matters is to make sure that your teams know what the focus is, and to have some ways to check on progress and confidence. There’s no need to create unnecessary pain by being too strict with your team.
.png)
.jpg)
