Implementing OKRs at your organization

Problem

Our company did not have a clearly articulated and aligned strategy. As a result, OKRs were a set of goals that did not foster focus. Teams had siloed plans that overlapped and conflicted each-other. They were not executing on a cohesive set of objectives (O in OKR) supporting a clear product strategy. In parallel with re-setting the product strategy, I worked with the team to re-set the OKR processes to improve the organization's capacity to execute against a strategy in an aligned way.

Actions taken

I began by implementing and walking the product managers through a six-part plan. The product strategy is an input into the plan, and the key results are the output of the plan. Think of the plan as a "contract" or a commitment to accomplishing a particular thing (KR) with resources. Effectively the plan makes the statement: "Given product strategy N, if you, [CEO] give us X resources, we will accomplish Y KRs, making progress towards Z objective in support of that strategy." The teams then present the plans to the leaders of the company for buy-in. The thought behind a plan like this (PM's responsibility), along with a clear product strategy (leadership's responsibility), are a foundational step towards setting good OKRs. As a leader, it's useful to create a template document (ppt, doc, txt, etc.) that serves as a reusable starting point for plans like these. Most importantly it has the following six elements so that a team can clearly and convincingly make the statement referenced above:

• Strategic alignment - align what you are doing with the overall strategy of the company. Once you do this, you can communicate a clear objective (O, in the OKR). An objective is a goal that is phrased in a way that ties it to the broader strategy. Usually, this objective will change much more slowly (e.g., every few quarters) than the KR (e.g., every quarter).
• Opportunity - what need are you solving with the product? What is the business opportunity? Research goes here - e.g., document customers' needs, industry trends, etc.
• Solution - what might a solution be to the opportunity above? Rough wireframes are fine here. Debate on specifics of the solution should be limited - this is just intended to illustrate a direction. The team will present specific solutions at a different time and interval (e.g., weekly) and often with different stakeholders (e.g., head of design & head of PM vs. presenting to CEO).
• Risks/Challenges - be transparent about the problems you may face and how you would address them.
• Goals (KRs) - How would you describe success? Illustrate how the potential solution might address the problem and make progress towards the opportunity. A KR is one quarter's worth of measurable work towards the objective. A simple example might be: "Objective: Support our drive to profitability by doubling LTV. KR: increase retention by 20%" The objectives themselves may not change every quarter, while KRs will. The KR does not need to be perfectly aligned to support the objective, but it does need to be measurable.
• Asks - what do you need to ship your product successfully? Request the necessary resources and time while also being sure to match them with the current state of your company. In a steady-state, the ask might be to continue resourcing the team at current levels.

Using this plan you can craft good KRs that are measurable and a good proxy for progress towards the objective in alignment with a product strategy. The plan is reviewed whenever a new team is formed, pivots, and on a regular cadence after that (e.g., every quarter). A process like this is also helpful for the leadership team so that they have a consistent way to understand and evaluate initiatives across teams.

Lessons learned

• The strategy is essential: The above process is worthless without a clear product strategy to tie objectives to. Therefore, developing a product strategy is an integral part of creating objectives. The objectives should be clear and, consequently, should align with the high-level objectives of the product strategy. There should not be a lot of debate in the strategic alignment phase of the plan, and any debate that occurs should center around whether the objective well supports the strategy. Debate on the strategy itself is a sign that as a leader you are not doing an adequate job setting & communicating the strategy ahead of time.
• Don't drown in process: It's worth adopting this process into something more lightweight (but with the same elements) for a smaller company (especially one that does not have as clear a strategy or a strategy that is frequently changing).
• Get decision-making buy-in: There is a lot of work that goes into creating these plans - get buy-in from the leadership team before beginning the exercise with your PMs. If the company's leaders are not going to use this information to make decisions, there's little value in presenting it. Know and understand the disagree & commit framework.
• Know the decision maker: It is vital for everyone in the organization to understand who the decision-makers are. Ambiguity will lead to debate without action. Know who is making the final call before presenting a plan like this. My last piece of advice: Many junior teams make the mistake of limiting their plan to a KR they can directly control. They'll ignore essential parts of the user experience because they can not presently control them. That thinking artificially constrains the team's impact. This exercise intends to help you, and your team (a) determine what's important, (b) define how to measure it, and then (c) ask for what you need to move it. Don't a first-time PM forget the last step.