OKRs: When To and When Not to Use
Not everyone would benefit from OKRs, context matters.
This post is an adapted version of a blog I wrote at LogRocket
I’m getting more and more questions about OKRs (Objective Key Results). Let me try clarifying when to use it and when not to. I’ve already had the bitter taste of injecting OKRs too early and stretching teams too thin, and I truly don’t want that for you.
Let’s clarify things straight here:
No matter the initiative you’re working on, clarity on what success looks like is mandatory.
OKRs can get this job done, yet they’re not the only tool capable of that. The question is, when should you use what?
For a while, I thought OKR would be the solution for everything, but I was wrong. Sometimes, it may stretch the teams too thin and confuse them instead of fostering collaboration. OKR isn’t a silver bullet that will always ensure alignment and clarity on success.
Let me elaborate on when OKR can help teams and when it can not, and how you measure success.
When will OKRs help you?
I’ve worked for different company sizes, from a few dozen to several thousand. The bigger the organization, the more complicated it becomes to align goals. Failing to address this issue will make collaboration complex, and teams will run in different directions.
In one of the organizations I worked for, we were around three hundred people, and we had eight product teams. Prior to OKR, departments would have separate goals, and product teams followed feature roadmaps. Our different goals forced us to compete against each other to pursue our roadmap. Here are some challenges:
Departments didn’t collaborate naturally
Product teams had multiple dependencies but no time to support each other
Results at the end of the quarter were demotivating, and morale would go down
The change came when management implemented OKRs.
Top management would craft the objectives and share with teams why such objectives were important. Then, the teams would collaborate to craft key results for each objective. Initially, that was exhaustive, but it enabled us to align and commit to key results, leading to collaboration over competition.
I learned from this experience that OKRs can set the direction and enable teams to focus on outcomes over outputs. It can also foster collaboration. I had a similar experience with companies the same size.
The following characteristics are favorable to OKRs:
The product is already on the market
Business is sustainable
Enough teams to address different objectives and key results
Brownfield initiative
But in other scenarios, OKRs didn’t work for me.
When OKRs Will Confuse Teams?
In startups, I never managed to get OKRs working well. On the contrary, I’ve seen them causing confusion and limiting the learning. Let me share a brief story with you.
We were before going to market, and I had the idea of establishing OKRs. I played by the book. We crafted the objectives with the other leaders and let the team craft key results. I thought we did it right but noticed some disturbing things over time.
Teams didn’t know which objective was more important, so they divided and started working in silos.
Every team tried to address multiple key results simultaneously, which stretched them too thin and impacted the delivery.
A meeting marathon took place to create alignment, contributing to more meetings and less progress.
Clearly, the OKRs didn’t help us. Before going to market, it’s not about setting and pursuing clear outcomes. That’s abstract. It’s about progressing and getting something available to penetrate the market.
Here are the elements I would opt to go against OKR:
The product isn’t on the market
The product is struggling to get market acceptance
Five or fewer product teams
Greenfield initiative
The solution came by ditching the OKRs. In a startup with a few dozen people trying to go to market, the OKR was too heavy. The leadership installed product goals and set one goal at a time.
How Product Goals Can Simplify Clarity
Continuing the previous story. With OKRs, teams had to ponder between multiple key results and struggled to define which one to act. More discussions took place than focus on progressing.
With product goals, the leadership was forced to define one goal at a time that could be achieved from six to twelve weeks.
The first goal was clear: our target audience could run their operations with our product. By then, the leadership had simplified the target audience to a small group so the team could focus on figuring out what to get into their hands.
The product goal instilled more progress and focus. It worked better than the OKRs because it was precise and provided enough guidance.
Reduced abstract discussions
Teams collaborated more instead of dividing into micro-groups
Everyone worked on the most important goal
Measuring Success
With OKRs, measuring success is simple. You have the key results and can measure your progress on that metric. Here’s an example of a scale-up I worked for:
Key Result: Increase basket size by 15% compared to last year.
We knew what success was, so we continuously measured that and could evaluate how our actions impacted our goal. It’s simple to evaluate when you set the key results related to outcomes, not output.
With Product Goals, it highly depends on how you define them. If you describe something outcome-oriented, you can measure similarly to OKRs, but if you represent a binary goal (achieve or fail), you need some tricks to measure. Let’s explore one product goal I had:
Product Goal: Let customers be sellers! They can sell anything they bought in our shop before.
This goal is binary: customers can sell or cannot sell. How do you know whether you’re progressing or not? I like asking the question, What needs to happen to be successful? For this product goal, we came up with the following:
Customers ready to sell products they bought from us
Customers ready to buy second-hand products
It sounds obvious, but then we came up with metrics and a gradual approach:
Customers subscribed to use the new feature
Number of products advertised
Number of purchase
Recurrency
Looking at this perspective enabled the team to start small, hack a solution, and get it available. The team pivoted three times before realizing it was a bigger audience. Success was evident initially, but we adapted the metrics on the way.
The main difference between OKRs and Product Goals is the when. OKRs, you start with the objectives and key results directly. Product Goals would be similar to objectives, but you lack the key results, and on the way, you define the metrics but don’t get stuck with them. You remain flexible because your ultimate goal is to reach the product goal.
Key Takeaways
OKRs suit the better established and mature environment
OKRs will cause more confusion than guidance when high flexibility is necessary
Product goals can be more helpful for products before going to market and for new initiatives
No matter how you opt to establish alignment and clarity on success, ensure to establish ways of measuring progress as fast as possible
Don’t get stuck with techniques. Ditch the framework if that doesn’t help you, but don’t keep something that is getting in the way of progress.
Let’s rock the product world together!
Here are three ways I can help you even more:
Upgrade your subscription to Premium and get one deeply thought newsletter per month (20+ minutes reading) plus access to 300+ episodes
Join my cohort, Product Discovery Done Right
Join my cohort, How to Thrive as a Product Owner
Have a lovely day,
David
Good read.