7-common mistakes YOU WILL DO when writing OKRs
Write a good OKR is a process like training your muscles: the more you practice better your OKRs will be.
On my journey writing OKRs, I made a lot of mistakes, some of them more than once (what a shame!), so at some point that I don’t remember when I decided to start collecting the most common and write about them helping others to avoid the same mistakes.
This article is basically a collection of these mistakes, or as I like to say, collection of learnings.
#1 Not all work deserves an OKR
This common mistake is on the very top of my list for a simple reason: when people start writing OKRs they get excited with the positive results an OKR brings to an organization, and as a result of that they start writing OKRs for every piece of work to be done. 😊
I like to say this is a “good mistake” because it is created by people seeing OKRs results, so it’s not bad at all, just a waste of time.
OKRs meant to be used for high priority work directly connected to the company strategy, helping to keep team focus on what matters and drive business results.
Use OKRs on Innovation and new features projects, but not to track BAU — Business as Usual.
#2 Avoid objectives not connected to the strategy
Although this is on the second place, this mistake is the most critical one on this list. As I wrote on another article talking about OKRs, “OKRs help you to describe what matters the most”, so if the work you are planning to progress doesn’t connect to any of the company strategic pillars, it means that it is not a priority for real.
So, progressing with this work you will be investing resources to get done something that doesn’t matter in light of your company strategy. It might be something important to one specific stakeholder or market, but if it is not aligned to the strategy, I suggest you to open a discussion about priorities, resources utilization and set clear expectations.
Go back to your backlog and stakeholders and find another project with higher impact to your organization.
#3 Creating key results that are tasks
The 3rd mistake is also a common one when starting with OKRs, but also easy to capture and fix.
Key Results must be meaningful to the organization. Think and repeat the word meaningful, and always ask the magic question — Why. Keep asking until you get an answer that matters to your business, and it will be the Key Result you want to achieve. Not simple, I know but let’s try to clarify with an example.
I will use again the example of an organization that sells products and has a Sales Force team visiting their customers. For this company, give free samples to the customers is an important part of the strategy as the customers can get to know better the products through these samples.
The plan to improve the samples distribution process is to launch a new website making samples available to visited and non-visited customers, what will grow the customers’ database.
At this point you have completed the objective, “Increase our customers database allowing them to order valuable samples through an online and personalized platform, by August/2021”
With this objective it’s very clear what the company wants to achieve: Increase the customers database.
How about the Key Results? I know, the temptation to create a Key Result as “launch the samples website by…” or “achieve 1000 page views in the first week after launching…”, is huge. But let’s resist to it.
This is exactly when I will ask you to repeat the magic question: WHY? Does the website launch is the most important thing? Why? Why page views are so important?
Think on the objective — “Increase our customers database… “, with that I hope you end up at the conclusion that only launch the website will not help much. Page views is a vague metric, as if the traffic is coming from unknown users, it will not help you to achieve your goal to increase the customer database.
But you can define Key Results like “Launch the website/functionality achieving 100 people registered, by August/2021”, or connect directly with the samples orders “Launch the website/functionality achieving 1000 samples ordered, by August/2021”.
You can see that in both cases, we are now measuring points connected to the objective of growing the customer database, where launching the website is only a milestone. Important one, but a project milestone.
#4 Selecting poor metrics
Key Results must be measurable using metrics that matters to the business, and not by easy to measure metrics. It must be meaningful to the business, so always ask how this metric helps to achieve the business goals. Go for the bigger picture.
On my article named “Content is King” I wrote something that can be used here:
“Remember that your organization has a strategy, and your work is to help to achieve the bigger goals, and not measure number of page views on a website.”
This is the spirit. It is OK to take easy to measure metrics when they somehow are related to your strategy. A good team discussion will help you to measure what matters
On the example I wrote to illustrate the mistake #3 above, you can see how easy to use metrics like #page views are not connected to the objective. So, keep asking Why and Why until you land on something that is important to your business.
#5 Very easy to achieve
OKRs are a good opportunity to challenge your teams defining aggressive Key Results. Aggressive but realistic. Believe me this is not easy to calibrate but it’s important to make clear that the challenge must be accepted by the team energizing them.
I like challenging Key Results as they are a good opportunity to exceed expectations. I see OKRs as a contract that must be done with your organization, where must be clear what is the minimum to be achieved when you complete the objective.
If you constantly achieve 100% of your objectives, you are not stretching enough. You can go further and be more aggressive in your next Key Result.
It is OK not to achieve 100%.
#6 Set OKR and forget
You as Product Owner/Manager does not own the OKRs just by yourself. OKRs must be owned by you, your team, and your organization. But it is part of your job to constantly review it updating achieved results and capturing team feedback.
I like to setup 90 days OKRs, updating progress every 2 weeks and reviewing them with others monthly. It will give the organization a sense of how close the team is to achieve the objective, but also an opportunity to correct the course if things are not going as expected.
#7 Too many objectives or objectives with too many key results
Key Results are not project milestones as we saw few lines above on the mistake #3. So, you don’t have to capture each step on a website launch, but what really matters when launching a website.
For example, when launching our new website you have a phase where the UX/UI team will (1)interview people to understand what they have to create, (2)design and (3)prototype phases, (4)customer interview to evaluate their work and (5)final adjustments.
On a very simple list above, I was able to list 5 different activities, but they are not Key Results. Again, OKRs are not a project plan, and you can write your Key Result as “Prototype the new samples website achieving 4 out of 5 after customers evaluation”. What do you think?
Keep your KR’s between 2 and 5 per objective.
At the end of the day, write good OKRs is a learning process. So, keep writing, keep sharing, keep capturing feedback and keep learning.
