Why OKRs Work (to Drive Product Innovation & Growth)

I share your skepticism.

‘A management principle? What can be so powerful about the latest in-vogue version of Taylorism from Silicon Valley? Everyone sets goals.’

On the surface, OKRs (Objectives and Key Results) are just another goal-setting management tool that works for some companies better than others. But, after working in product in a range of industries, I have found OKRs are not 'just another tool' for management. Instead, I think they are a powerful way to organize businesses for innovation; specifically, product innovation.

Why? OKRs are a powerful supplement to the product vision, help emphasize outcomes over output, and bring the benefits of qualitative and quantitative measurement.

Powerful supplement to the product vision

One of the fundamental problems of the product vision, in addition to the difficulty in creating a compelling one, is communicating the vision is hard. Those directly involved and responsible for the vision tend to have a nuanced understanding. They understand the areas that are unsaid, they can fill in volumes of detail around tradeoffs, focus, and alignment with business strategy. Unfortunately, this is often only the direct product manager on the team, or the PM and the product designer!

The rest of the product team who did not have weeks and months, as well as the explicit responsibility to create the vision, often tend to have the details of what has been explicitly said about the vision. They cannot speak to all of the work behind it – after all, that is not their job. They often tend to have the rough outline and understand the user stories for it.

When it comes to executives, other teams, and even senior product leadership, the vision becomes much hazier. They only understand bits and pieces of it. Often, those pieces are specifically related to large issues or wins from the past. Their understanding is a piece of the whole.

So, the challenge with communicating and evangelizing vision is providing a reliable set of items to give texture to the vision. OKRs are an ideal companion to the vision. They give the rest of the product team clear goals to work towards. They give executives and other teams a clear idea of the metrics you are trying to move and the objectives you are trying to achieve.

Outcomes over output

Nearly every software team has run onto the feature treadmill without moving metrics, at some point in time. Sprint after sprint, releases fail to move the metrics. OKRs help flip the narrative. Output, the shipping of features, ceases to be rewarded. Instead, teams & initiatives are considered to be successful when they meet and exceed business outcomes.

OKRs, properly constructed, are business outcomes – not output. OKRs allow the whole team to apply their ingenuity to move the metrics and reach business objectives. If the rest of the team understands the OKRs, then they all can contribute creative solutions to helping achieve these outcomes. This is how product managers can get the most out of their team.

Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity.

George Patton

This also provides fertile ground to get the most out of stakeholders. Instead of debating features on the terms of the number of times sales has been asked an item, or the feeling of the HiPPo (highest paid person), the context is moving the OKRs. Everyone knows the terms of the debate – what will help us achieve our OKRs?

Qualitative and quantitative measurement

Consistent product innovation is typically not the result of launching 50 MVP features. That often results in a disjointed product just barely solving a few customer problems. Instead, product innovation is often the result of 1) quality discovery and 2) moving steadily on certain objectives and metrics.

First, product teams need time to do product discovery. Often, the team can actually move metrics faster if they focus on lightweight prototypes and other activities before they ship a feature. But focus on output pushes teams towards the feature treadmill, where they ship features they could have done faster discovery work on. OKRs are the antidote to this; because the team is measured in moving outcomes, they have the latitude to make the time for discovery when it is faster.

Second, conversion rate rarely doubles overnight. It doubles when the team can 10% increase conversion rate 8 quarters in a row. Having a quantitative yardstick to work towards on individual time periods helps the team work towards specific, achievable goals that are not as scary as moving a top-line metric 2x. Certainly, achieving 10% growth each period becomes more difficult, but the product team also gains a better understanding of the levers moving metrics, and experience moving the metrics.

Consistent focus on quantitative growth helps the product team achieve the exponential outcomes that are the hallmark of great product companies. The integration of key qualitative metrics in the objectives portion also helps the team conceptualize what is involved at each stage.

Pitfalls with OKRs

Framed as output

The easiest way to separate strong and weak OKRs is any mention of output. It does not matter how often or how much the team ships. What matters is the actual business outcomes that the team moves. OKRs must be framed in terms of business outcomes, instead of systems developed. Even a backend system can have an OKR of a better uptime, or scalability, or some other such outcome.

Refreshed at a cadence that doesn’t fit the business

OKRs can be refreshed too quickly or too slowly. It is up to the management to find a cycle that makes sense given the business they are in and the capabilities of the team. Fast moving live operations games with large engineering teams might refresh their OKRs every six weeks. Other hardware teams in semiconductors might refresh them every year.

Neither approach is wrong. But shoehorning any single approach simply because that is what one saw on TED, is. The leaders pushing OKRs should be open to adjusting the OKR frequency with the team’s input regularly. Most often, I have found OKRs set to the performance review cycle, as then OKRs can be used as a measuring stick during those periods. But different things work for different companies. Annual and quarterly are the most common.

Rolled out top down

One common mistake with OKRs happens when the high-level stakeholders are aligned, and understand the OKRs, but the low-level teams, who do the work, were not involved in their creation, and do not fully understand them. It is critically important for the OKRs to be established in a bottoms-up effort as well (as the top-down evaluation), with each product team developing their own OKRs.

An alternative top-down mistake is just dictating to teams who do not have experience in OKRs to establish them. In this case, it is critical for the leadership to build the OKRs hand in hand with the teams. Since those resources are typically in high demand, one method, in this case, that helps creating this organizational change, is the use of pilot teams.

Not evaluated holistically

Another trap teams can fall into when implementing OKRs is that the sum of the OKRs does not achieve the ultimate business goals. This happens when teams are too conservative in their own OKRs, or the teams are not staffed in such a way that all the business outcomes are achieved. It is critically important that the OKRs help be a function to have the discussions to make sure teams have ambitious enough goals, and teams are staffed so all goals can be achieved. OKRs often can help the business see the specific goals that ladder to the outcome where they have been able to make the least progress.

Teams lack the necessary skills

OKRs are generally hard to roll out if the team does not have the product managers who can own the OKRs and the analysts/data scientists who can help the product managers choose the right key results and measure ongoing progress against them. If either of these links is missing, it becomes hard to create and enforce the OKRs. In the product manager gap situation, if the team is just helmed by a project manager, that individual often does not have the specific charter to form and help guide the team towards OKRs. On the other hand, in the data analytics gap situation, if the team does not have the right data understanding, then they can be left with key results they cannot achieve.

Lack of organizational value

If the organization does not take action based on achievement of OKRs, OKRs can be doomed from the start. For OKRs to be effective, the company must react. Some OKRs are moonshots, and it is okay not to achieve them; but, the team should ask how they change next time around. Perhaps, it means reorganizing the team. On the other hand, if a team knocks out their OKRs; perhaps, it means recognizing the achievement to the rest of the company.

Do beware, this area is hotly debated: whether OKRs should be used in the evaluation of employees. Some people strongly believe they should not. I think that OKRs can be a useful input. For PMs, for instance, I think it is helpful to evaluate them based on the quality of the OKRs they set. I found this often separates good PMs from great.

For the rest of the product team, teams that consistently hit their OKRs, I think, benefit from being rewarded. Without the reward, OKRs can become hollow – commitments, but not north stars, for employees. At the same time, it is important to hear the criticism of using OKRs in employee evaluation: it can cause them to have fewer moonshot or stretch goals. To address this, evaluate teams from the perspective that it is okay to fail if the team went after big goals. Google often mentions the 60-70% sweet spot, and teams can be evaluated on whether they were in it.

Summary

OKRs have the potential to help product teams innovate and achieve exponential growth. Structured correctly, they help empower team members to use their ingenuity to achieve business outcomes. They also help align the team and stakeholders. But it is easy to do OKRs wrong - by framing them as output, refreshing them too often or too infrequently, rolling them out top down, not evaluating them holistically, applying them to teams without the skills, and lack of enforcement. So, consider carefully, was it OKRs that failed or your implementation? Some of the companies with the most consistent track records of product innovation use them.

Good luck! And let me know your thoughts. How has your experience been with OKRs?