OKR summary

OKRs are usually attributed to Google, but while reading this book, I realised that in fact, they originated here. Andy Grove developed Peter Drucker’s Management by objectives into OKRs, and then John Doerr learned them at Intel and took them to Google. Reading them here was the first time that they actually made sense to me rather than feeling cargo-culted.

Objectives are what you need to do; key results are how you know you are on your way. The example that really made it clear to me was: your objective is to reach the airport in an hour. Key results are: pass through town A at 10 mins, B at 20 mins, C at 30 mins. If after 30 mins there is no sign of town A, you know you’ve gone off track. So they need to be clear enough that you know you’ve met them, and that you are on track.

He points out that the system requires judgment and common sense. Objectives are not a legal document. If the manager mechanically relies on the OKRs for the review, or the report ignores an emerging opportunity because it wasn’t one of the objectives, “then both are behaving in a petty and unprofessional fashion”.

And finally, a very important point: you should not have too many! “To focus on everything is to focus on nothing”.

Anna Shipman in her book notes from High Output Management by Andy Grove

Advertisements

OKRs

The acronym OKR stands for Objective and Key Results. The Objec‐ tive is qualitative, and the Key Results (most often three) are quanti‐ tative. They are used to focus a group or individual on a bold goal. The Objective establishes a goal for a set period of time, usually a quarter. The Key Results indicate whether the Objective has been met by the end of the time.

Your Objective is a single sentence that is:

  • Qualitative and inspirational: The Objective is designed to get people jumping out of bed in the morning with excitement. And while CEOs and VCs might jump out of bed in the morning with joy over a three percent‐ gain in conversion, most mere mortals get excited by a sense of meaning and progress. Use the language of your team. If they want to use slang and say “pwn it” or “kill it,” use that wording.
  • Time-bound: For example, something that is achievable in a month or a quar‐ ter. You want it to be a clear sprint toward a goal. If it takes a year, your Objective might be a strategy or maybe even a mission.
  • Actionable by the team independently: This is less a problem for startups, but bigger companies often struggle because of interdependence. Your Objective has to be truly yours, and you can’t have the excuse of “Marketing didn’t market it.”

BUT …

  • Don’t create objectives that rely on the input of other teams unless you’ve agreed with them that you share priorities.
  • Don’t create objectives that will require people we haven’t hired yet!
  • Be realistic about how much time you will have to achieve your goals.

Key Results take all that inspirational language and quantify it. You create them by asking a couple of simple questions:

How would we know if we met our Objective? What numbers would change?

This forces you to define what you mean by “awesome,” “kill it,” or “pwn.” Does “killing it” mean visitor growth? Revenue? Satisfaction? Or is it a combination of these things?

A company should have about three Key Results for an objective. Key Results can be based on anything you can measure.

 

Christine Wodtke: Introduction to OKRs

Product funnel

The actual funnel depends on the type of product, e.g. for You Tube, NYT, Buzzfeed

  1. Awareness
  2. Education
  3. Engagement
  4. Conversion
  5. Revenue
  6. Recurrence

OR (SaaS, enterprises w Freemium plan etc.)

  1. Awareness
  2. Education
  3. Conversion
  4. Engagement
  5. Recurrence
  6. Revenue

From: Laura Klein et.al. Build better Products

 

Jobs to be done

The Jobs-to-Be-Done framework is a representations of user needs born out of qualitative user research, such as field studies, interviews, and discount usability testing. It involves identifying for which goals customers “hire” your product (and, ideally, also finding out if there are competitor products that these users are ready to “fire”). Armed with this understanding, a product team can think about the nature of the users’ core problems and needs from a fresh perspective, and devise product features that solve that main need as best as possible.

For example, if a traditional task analysis unearthed that delivery drivers frequently needed to print out directions that showed how to navigate between each stop on their daily route, it’s likely that the design team would focus on making it as easy as possible for the drivers to format and print the directions; however, a JTBD-focused approach would focus on the delivery driver’s “job” (that is, getting navigation guidance while driving), and would look for solutions to that problem (such as a GPS system providing voice guidance).

Oftentimes, we hear JTBD advocates referring to the famous Theodore Levitt quote, “People don’t want to buy a quarter-inch drill, they want a quarter-inch hole.” Rather than focusing on a list of features for a product, the JTBD framework forces designers to think about outcomes: would users be able to (happily and easily) complete the job they “hired” the product for? Does this solution provide a better outcome than existing ones?

From: Personas vs. Jobs-to-Be-Done by Page Laubheimer