Objective Facts
By: Matt Lane
Tags: Startup, Management, Product Management, Business, Strategy

INSIGHTS:

Strategy is so much more than, say, the outcome of a successful strategy, e.g., such as a desired growth metric (increase subscriptions by 70%). Strategy is thinking about the critical issues worth concentrating resources on and rethinking (or reframing) the initial identification of the key problem area with more than one response to the stated problem. It is to reduce the problem scope to make it achievable.

OKRs are the tactics that describe what teams need to do to achieve part of a stated strategy, usually on a rolling quarter basis, in a fast-moving and uncertain environment. You do not get alignment and autonomy for free by simply adopting OKRs. It is only one part of the operating model of doing strategy work.

OKRs should be incorporated into your organization ASAP, as doing so helps to build the muscles and the discipline leaders and teams will need to effectively carry out this formal process once the business has achieved product/market fit, which is when management by objectives begins to make even more sense (you will be able to manage what can be measured after the business realizes, for example, a Monthly Recurring Revenue or can demonstrate retention metrics across cohorts, etc.).

Empowered product teams (exists in organizations where leadership pushes decisions down to well-defined and competent full-stack teams to solve coherent and critical issues and not features/deliverables to build/ship or tasks to accomplish) are required for the OKR methodology to work properly.

OKRs are simply a way to formalize discussions and help orient teams. As Marty Cagan said:

All that’s really required is for a knowledgeable leader to sit down with the relevant product teams, explain the strategic context including the product strategy, and then tell each team which problems you need them to work on, and what business results they should measure.

The objective is the problem to solve. It is qualitative and gives purpose and meaning to the set of key results. The key results tell us how we define success and must be measurable. And, how we define success is not achieved via one single proxy variable but through many (at least two) proxy variables per objective that drive our desired outcomes (what specifically will solve the underlying problem). OKRs are about results/outcomes not tasks/initiatives.

The following passage is from The Principles of Product Development Flow, by Don Reinertsen:

The danger in focusing on proxy variables is that proxy variables interact with one another. For example, raising capacity utilization has the beneficial effect of improving efficiency and the negative effect of increasing cycle time. To understand the net impact, we must combine both effects. To do this, we must express changes in all proxy variables in the same unit of measure. This unit of measure should be life-cycle profit impact, which is the ultimate measure of product development success. It is only when we understand the mapping between proxy variables and life-cycle profits that we can really see the economic consequences of our choices.

Below is a helpful example of how to write an OKR for a team as seen in the Team Objectives article by Marty Cagan:

Generally speaking, we want two key results for each objective. The first key result is the primary measure. The second key result is a measure of quality, sometimes called a “backstop,” to ensure that the first key result is not inadvertently achieved by hurting something else. For example, suppose we consider the objective of: Reduce the frequency of parcels delivered to the wrong address. Now, the primary key result would likely be the actual percentage of incorrect deliveries. But if we were to achieve that by burdening the ordering and fulfillment process, it’s possible to reduce the percentage, but also significantly reduce the absolute number of deliveries, which would not be a helpful solution. So, potential key results could be measured by: Reduce percentage of incorrect deliveries from x% to y% while ensuring that total deliveries continues to grow Notice that while these key results do imply specific KPI’s, we don’t yet have the expected values or timeframes, because those will need to come from the team. The reason for that is that if we were to provide to the team explicit measures of success including time frame, they won’t feel that ownership over the commitment that we want in an empowered team. So the actual quantitative values will come from the teams.

Product teams (full-stack teams, cross-functional experience teams, or also called stream-aligned teams), accountable for carrying out a long-lived mission, must be enabled to work in an autonomous and decoupled way with minimal dependencies and constraints on issues that are outside of a team’s domain and instead function in a working environment where operational IT activities are in place to support business outcomes (in a self-service model), i.e., platform teams should share in the business successes if they are supporting stream-aligned teams, which they should be doing. Thus, OKRs should be deployed by leadership and management to the appropriate stream-aligned team(s) and generally not to platform teams, complicated subsystem teams, or enabling teams (see Team Topologies for more information on designing team structures and how to build areas of accountability), as those teams generally should share in the stream-aligned team’s OKRs. That is, OKRs are distinct from “keeping the lights on” work, e.g., tech debt should always be attended to and never exceed ~20% on all cycles. This deployment can be in the form of a company-wide OKR that teams co-create their OKRs to roll up into the company-wide objectives or quarterly OKRs are created by management but KPI values inside your value-based key results are created by teams. And in that vein, avoid metrics that quantify progress; focus only on metrics that reflect actual impact that’s core to the business.

Leaders assign objectives to product teams to execute on a product strategy (a product strategy is about deciding which problems (and, sometimes, which user goals) to focus on, which teams should be coordinated to achieve the assigned objectives, and how resources should be calibrated to best expend competitive efforts outward).

Leaders can leverage design thinking in a data-driven strategy-setting working session. A helpful framework for applying design thinking to setting OKRs can be seen here.

See how OKRs can be incorporated into your product organization here.

OKRs can either be roof shots (~80% chance of clearing) or moon shots (~20% chance of clearing). You want to avoid sandbagging, and always stretch your goals without punishing teams should they underdeliver. You can empower teams to stretch by enabling them to solve problems and own the solution space (the HOW). This helps to keep experience teams accountable for the solutions they deliver and to continuously find the optimal problem-solution fit.

Separate teams within a product line can and should absolutely share team-level OKRs if that makes sense. Any dogma that states each team within a product group, within a product portfolio (business unit), must each maintain their own separate proximate objectives and target conditions is incorrect. Shared objectives are perfectly normal, since some are more business focused (with lagging indicators) and others more product focused (with leading indicators). This can help to get teams across the organization to collaborate in solving ill-structured problems together. This is totally fine, and sometimes necessary, as long as the organization is covering as much of the overall organizational/company-level objective(s) as possible.

All team-level objectives, and/or objectives at the corresponding product portfolio level, must neatly roll up into the company’s annual objective(s). Not only should teams have clear OKRs that neatly align to company-level objectives (the WHAT), but the purpose (strategic intent), the WHY (the context around the goal/mission), also must be briefed by leadership to management and to teams. It is the responsibility of leaders to decide which problems should be worked on and why and assign objectives to the applicable product groups and/or teams and for managers across the organization to maintain the coherence of the product strategy each quarter (and beyond).

Teams within a business domain product portfolio should meet once per week to share progress on their shared OKRs and back-brief to management and leadership. You can use a template like this.

Source: Jez Humble from Lean Enterprise