More and more organizations are adopting OKRs to set goals for their teams. Failure is one common theme that surfaces in the first-time adoption of OKRs, especially in the adoption of top-down OKRs. And there are some good reasons why this happens.
First off, what are OKRs?
Before we jump into the details, I want to take a step back to explain what OKRs are. OKRs (short for Objectives & Key Results) are a goal setting technique that drive alignment and foster autonomy in product teams.
OKRs are made up of two parts:
- An objective that a company would like to achieve.
- Measurable Key Results that determine how much of the objective was achieved.
OKR Objectives should never be tasks. Instead they should always point towards outcomes. By avoiding tasks we are leaving it up to the teams – the experts of the product – to find and determine which levers need to be pulled to achieve the objectives.
Here are some examples of good and bad OKR Objectives.
❌ – “Implementing a new CMS system” – not a good OKR Objective as this defines an output, not an outcome.
❌ – “Roll out feature x to all users” – again, here we are prescribing what the output will be.
✅ – “15% decrease in dormant accounts” – a good example of a good OKR Objective that defines an outcome, but does not define how to get to that outcome.
✅ – “Increase new account creations by 50%” – another good example of an OKR Objective that focuses on what the end result should look like. There are a number ways of how teams/squads can get such a result.
This leaves us with Key Results. Key Results are the levers that product teams can pull to achieve the defined objectives. Key Results should be measurable and determine whether an Objective was achieved.
Let’s take the “Increase new account creations by 50%” objective above. Examples of good key results for this objective might be:
✅ Double the amount of referrals from the refer-a-friend programme.
✅ Increase sharing of user-generated content with non-customers by 10%.
✅ Increase the website > account created conversion rate by 5%.
✅ Attract 20% more customers through paid marketing channels.
When setting OKRs it is mostly the responsibility of the teams to identify the best Key Results for the Objectives (of course with radically candid feedback and healthy discussions with leadership).
OKR Failure Reason #1 – Autonomy (the lack of)
One of the main reasons why OKRs have been so successful is the autonomy and space they give teams to solve real problems in ways they deem best. Empowered teams are higher performing teams that focus a lot of their efforts on finding the best levers to pull to improve their product in a way that aligns with the set Objectives.
Good leadership teams focus on finding the next best areas of opportunity for the company to invest in and that the right resources are available for teams to achieve objectives.
It is impossible to have a leadership team that has a strong grip on the company direction, and also being experts on the tactical level. When leadership teams start worrying about the solutions that should be delivered to achieve objectives, it becomes much more likely that higher-value solutions are missed in favour of solutions that are prioritised due to bias and other inaccurate prioritisation techniques.
Of course autonomy requires a high level of trust (which is why I feel so strongly about Trust in a product environment). And this is why hiring the best talent is so important for organisations.
OKR Failure Reason #2 – Projects
The term “project” has become a bit of a taboo in the world of product. It’s come to be associated with an inefficient, antiquated way of working. But the reality is that companies will always have projects that need to get done (e.g. implementing a CRM system, implementing a reliable event tracking system, etc.).
A lot of people try to hide projects behind objectives. I strongly believe that this is a mistake. Projects should be referred to as projects, and should be lead by a strong project manager to ensure the right scope is delivered at the right time, and proper communication is maintained throughout. This also helps with team morale, as the team enters the initiative with the right mindset and expectations.
Most importantly – OKRs should not be used for projects.
OKR Failure Reason #3 – Focusing on the letter of the law, not the spirit
As explained earlier, OKRs are used to 1) maintain alignment, and 2) give teams the autonomy they need to solve problems in the best possible way.
If a KR has been set at increasing a metric by 50%, but at the end of the period, the metric was only increased by 10%, then it is clear that something has gone wrong in the process.
On the other hand if the metric was increased by 45%, then even though the KR was not hit, the reality is that the performance was actually still pretty good and probably the focus during the period was on the right thing.
Treating these two examples as equal failures (i.e. focusing on the letter of the law) is detrimental to team morale. And so spending time perfecting OKRs for the period to get perfectly accurate numbers is not the best use of anyone’s time.
OKR Failure Reason #4 – Not using stretch goals
The intended use of OKRs is to have inspirational, stretch objectives and KRs, rather than “targets” (albeit they still need to be somewhat achievable, not impossible). At the end of a period, the measure of success is a more analogue one, which focuses more on how much of the objective the team has managed to achieve, rather than on whether the objective was achieved or not.
This might be a bit of a controversial subject, however the rationale behind stretch goals is that it will allow teams to think of bigger, bolder and more innovative changes that could potentially take the product to another level.
The danger of opting for more conservative targets is that it can easily trap teams into optimising for local maximas, rather than looking at taking the product to a higher maxima.
CXL – How to get over local maximum?
Of course the flipside is that not fully hitting stretch goals might have a negative impact on team morale. Which leads me to failure reason #5.
OKR Failure Reason #5 – Not aligning the teams on how OKRs work
Not everyone might be familiar with how OKRs work. Since OKRs require a shift in mentality it is extremely important that everyone understands what is expected of the role they are in, what they are accountable for and how this will feed into the success of the organisation.
Product teams need to understand that they are empowered to take decisions on which initiatives to opt for. Leadership teams need to stay away from prescribing solutions and focus on finding the right objectives (albeit healthy discussions on potential solutions are still encouraged), etc.
OKR Failure Reason #6 – Trying to get it all right on the first try
Even though the concept of OKRs is a fairly straightforward one, in practice it is not as intuitive as one might think and it might also not align with what people are used to. And so, some form of failure is to be expected, especially in the first round of OKR adoption.
Perfect is the enemy of good though, so the trick to getting OKRs right is to just get started. Make it abundantly clear to your teams that failures are to be expected, but also to make sure that you should be learning in the process and improving.
As long as treating OKRs as being an empowerment technique for your teams, you will iteratively arrive at an implementation of OKRs that work for you and your organization.
For anyone who’s looking to start using OKRs for the first time, I had found this session by Whitney O’Banner, who talks about a very practical approach to first-time OKRs, to be very useful. I strongly recommend watching.
Other very useful resources on setting up companies to be successful in the adoption of OKRs can be found on Marty Cagan’s insights blog, such as this post.