OKRs (Objectives and Key Results) is a management and goaling framework, first developed by former Intel CEO Andy Grove.
The framework features a set of 5-7 major Objectives for a team or organization, with specific and measurable key results that support each objective and are reviewed monthly or quarterly.
In his classic management science tome High Output Management, Grove described using the framework to successfully transition Intel from a memory company to a microprocessor company.
Everyone knows how that turned out.
Subsequently, John Doerr, the Grove protégé and investor famous for backing Google, Amazon, and Intuit, introduced OKRs to Google in 1999.
5 years later, their legendary IPO shattered records. In 2017, Doerr penned Measure What Matters, cited by Bill Gates as a book that every manager should read.
He makes a very convincing case that the future of business should be based on OKRs.
Since then, companies from Adobe to Zynga have been known to use OKRs, either company-wide or in large team capacities.
“With this kind of documentation, backing, and history, implementing OKRs must be a snap,” I said to myself.
As the title of this article suggests, I was misguided in that assumption.
The arrogance of youth
I like to consider myself wiser now. But as a young, freshly-minted product leader, who was ostensibly hired mainly due to my product management skills, I was eager to flex my knowledge of “best practices” when it comes to people management.
I had read Grove and Doerr, and was excited to impress my manager (the CEO of a mid-sized company) with my ability to implement OKRs for the product team.
“After seeing how successful it will be in product,” my pitch went, “you can then transition the entire company to an OKR framework!”
He gave the blessing to go ahead, and I promptly made three critical mistakes. The project was then doomed from day one:
I should have implemented OKRs amongst the leadership team first.
I failed to align the product OKRs with product-adjacent teams.
There was no real reason to do this in the first place.
The mistakes are all linked and there is overlap between them, but each was significant enough to torpedo the effort right out of the gate.
Each of my mistakes link back to three central tenets of product management as a discipline, so it’ s worth examining each as a unique point of failure.
Influence OKRs with authority
My primary tactical mistake when implementing OKRs was not setting company-wide objectives first. While there is debate in OKR world over whether this is actually crucial, it depends on your specific organization.
The company I worked for at the time was top-down. Despite its size, the CEO knew almost everything that was going on (his memory and short-term recall still amaze me to this day).
He also managed to be the primary decision maker for many initiatives, and had veto power over my prioritization within the product strategy domain.
Because of his leadership style, I assumed his blessing meant the entire leadership team was on board as well.
They were not.
In a top-down sort of organization, starting objectives at the highest level is practically a requirement to get cross-functional buy-in. It is also crucial in setting alignment with teams that can influence your KPIs (key performance indicators).
Despite my position on the leadership team, I found that my setting of key results for my own team lacked impact.
They didn’t roll up to a clear company priority. The teams that had high-touch influence over our key results (chiefly engineering) had zero reasons to care about whether we hit our targets.
We immediately started off on shaky ground because the leadership team didn’t have a set of objectives itself.
Objectives need to roll up, meaning that the specific tasks (the key results) to accomplish a team Objective can be directly traced to accomplishing a company objective, which impacts all teams.
Without this ladder, I created a large amount of cognitive dissonance across teams.
A performance review six months down the line is a terrible motivator for a product team - we need a why. I should have recognized that we are a top-down org. Then, I could have influenced the rest of the leadership team for buy-in before bringing my OKR idea to the CEO.
Creating company-wide objectives could have saved me from a lot of pain in getting these items off the ground.
Align THEN Define OKRs
I’ll just tell them my OKRs later
Regardless of whether there are top-down objectives, there still needs to be cross-functional alignment for a product team’s OKRs. Unfortunately, I created my OKRs in a vacuum, and failed to consult any other teams when formulating my plans.
This was the “20/20 hindsight,” forehead-slapping “OF COURSE” moment that I had immediately when my OKR project failed.
Of course I needed to align cross-functionally. Why would my product OKRs require less rigor than a feature?
Of course I needed to align my key results with marketing and customer success and operations. What if we have competing priorities? Worse, what if two teams are attempting to solve the same problem in silos?
As a general rule for product teams, it’s beneficial to know the KPIs of other teams in the company. It’s imperative, however, when trying to formulate OKRs.
Let’s say an objective for the product team at a B2B company is “Improve the User Experience for paying users.” A key result there might be “Reduce the amount of time it takes a user to do Plus Function X by 10%.”
It would make sense then to align with engineering. Maybe one of their objectives is “Improve app performance” with a key result of “Reduce the time it takes for DB queries by 5%.” There is overlap between those two key results, and it’s entirely possible to handle two problems with one solution!
Come back to Why
Spending time crafting OKRs requires the answer to this question.
Are OKRs right for your team? What about for your department? Or for your company?
Those answers need to align. After my failed experiment with OKRs, I spent a good bit of time wondering how I could have gone as far as I did without realizing that the OKR framework simply wasn’t right for my company at the time.
The company was executing well within its existing management framework. In my eagerness to prove myself as a product leader, I fell in love with a solution. Then I attempted to find the problem to fit it.
As product managers, we spend so much time making sure we’re solving the right problem. As product leaders, we need to exercise the same approach to processes and frameworks we implement for our teams.
If not securing leadership team alignment was my primary tactical mistake, then using the OKR framework to solve a problem we didn’t have was undoubtedly my primary strategic mistake.
I still believe that OKRs are a fantastic framework for management, even when they take other forms. My current company uses a form of OKRs, though we call them something else.
Ultimately, it is about doing what’s best for your company. As a product leader, you need to think not only about your user, and what problems to solve for them, but also what problems to solve for your team.
OKRs are a tool in your management toolbox, but they shouldn’t be confused with the toolbox itself. Do what’s best for your team and the rest will follow.
Adam Hecht
Read also
Create effective product strategy
