Product Planning with OKRs (Objectives & Key Results)

Gannon Hall
Apr 19, 2018 · 12 min read

The Glue that Binds

OKRs are more than just a means of defining goals and measuring results, they are a framework for critical thinking, and most importantly, fostering a culture of cross-functional collaboration that values measurable contributions, accountability, and clarity of purpose.

Aligning user problems with team objectives

OKRs are perfectly suited for product teams, as they help to reinforce the practice of focusing on the problem at hand, rather than the potential solutions one might employ to address the problems.

Objectivity and Non-attachment

Product management is a science of experimentation and discovery. Early in our career, we learn that opinions, and in particular predictions about user behavior, are often wrong. It is a natural human instinct to assume that our rational assessment of a problem, based on our past experiences, will yield sound conclusions and represent the likely sentiment or behavior of others. But this is rarely true.

  1. SOLUTION HYPOTHESIS: A proposed solution to a user need or problem based on information inputs
  2. INFORMATION INPUTS: Includes existing data and observable user behavior, user feedback, intuitive hunches, or the results of related studies or competitive products
  3. DATA INPUTS: Quantifiable measurements and observations subjected to systematized statistical scrutiny
  4. DISPROVEN HYPOTHESIS: A disproven solution hypothesis is often the result of incorrect assumptions about user motivation and behavior
  5. ITERATIONS AND IMPROVEMENT: Technology and user needs are constantly evolving; a solution that serves those needs must also evolve

The Confidence Quotient

There is also a cost to experimentation. Variant testing, user experience research and other methods of product experiments are time-consuming and costly. PMs are not academics and do not have the luxury of spending months or even years proving a hypothesis. Product Managers serve the commercial interests of the company and therefore need to bring products to market quickly while mitigating the risk of failure. PMs must balance these conflicting agendas, ultimately assessing the cost/benefit ratio and degree of acceptable risk.


RICE scoring is one example where the use of a confidence quotient is particularly useful. R.I.C.E. stands for Reach, Impact, Confidence, and Effort and is a lightweight method for quickly prioritizing initiatives.

  • Impact = How will each user be impacted by this feature (on a scale of 1–3)
  • Confidence = Our confidence in the validity of the first 2 numbers (on a scale of 1–5)? If no research has been done and we’re working from pure gut, confidence should be a 1. If we have run multiple studies and have empirical data to indicate a high probability of success, confidence would be a 4 or 5.
  • Effort = How many engineering weeks are required to build the feature
(Reach * Impact * Confidence) / Effort

Objectives = User Problems

OKRs are particularly well suited to Product planning, as Objectives correlate directly to the problem area a team is focused on, while the Key Results represent the progress that can be made against that problem over a given time period.

  • Decrease average 1st page load time to interactive of the home page for United States users from 3.59 seconds in May 2017 to 500ms in September 2017
  • Decrease average 1st page load time to interactive of search result pages for United States users from 3.94 seconds in May 2017 to 500ms in September 2017

Best Practices for OKRs


  • Explicitly address a target user
  • Align with the squad and group’s long term mission, KPIs, product vision, and business goals
  • Evaluated for efficacy during every planning cycle
  • Evaluated by all individual participants of a squad and by all interested or affected stakeholders
  • Not necessarily time-bound, however one should avoid changing them in the middle of a development cycle
  • There should be no more or less than one Objective proposed per squad during every planning cycle

Key Results

  • Include a quantitative evaluation that best represents the true intent of the Objective they are serving
  • When paired with an Objective that is likely to extend beyond the time bounds of a cycle, they can focus on measurement of project completion required to eventually achieve the Objective
  • They are explicitly time-bound, usually to the cycle in which they are active
  • They explicitly define the metric by which they will be monitored
  • They explicitly define a benchmark and a target to be achieved within the time frame explicitly defined
  • When a metric is not yet instrumented, they can explicitly state that setting a benchmark is the Key Result
  • They are accompanied by a monitoring dashboard
  • There must be at least one and no more than five Key Results per Objective

OKR Retrospectives

At the end of a goal period, the tech team’s results should be evaluated against each stated KR. Expectations that a high-performance team should hit 100% of their KRs is unrealistic for several reasons. Software development planning is a process of prediction and iteration. While we do what is reasonable to make accurate predictions, teams must be comfortable with the reality that their predictions will frequently be wrong.

Development Cycles

In summary, OKRs support agile decision making by encouraging teams and individuals to seek the best information available, thereby reducing the risk of decisions founded in false assumptions (e.g. sunk costs) or anecdotal information.


Lesson's from the front lines of product management and leadership

Gannon Hall

Written by

Product Strategy - Former product head of Google Maps & Local Search; former CPO at Shopify and Adjunct Professor at Cornell Tech



Lesson's from the front lines of product management and leadership