Exploration OKRs - feat. The Law of Shitty Planning

A quick overview of what we've covered on "Notes on Product Management" so far -?

• Overall:?The IC PM Role,?The 4 key skills,?Remote + Pandemic PM,?5 Decision Making frameworks/heuristics,?Problem finding/solving with executives,?Managing psychology
• Skill #1 - Problem finding:?Most important skill,?Problem statement and hypothesis,?Building Strategy,?Validating problem statements and hypotheses
• Skill #2 - Selling:?Sales and Marketing,?Writing for executive audiences,?Product executive relationships,?Learning to sell
• Skill #3?-?Problem Solving:?Roadmap,?Product specs,?Solving for Usability,?Solving for Feasibility,?PM<>Eng collaboration,?Ramps and launch checklist
• Skill #4 - Building effective teams:?Knowing thyself,?Your manager,?Product team culture,?5 habits - high velocity product teams,?Effective 1:1s,
• Managing your career:?Getting in - I,?Getting in - II

---------------------------------------------------------------------------------------------------------------

In many product teams, there are very noticeable repeating periods of stress.

That period of stress is driven by "planning."

Most organizations beyond a certain scale have planning cycles that are either quarterly or half-yearly. Planning exists to ensure everyone is making the best use of the most valuable time in a software company - IC/individual contributor engineering time. The output of the planning process is typically some metric target for the team that is a by-product of the team shipping good products. In many organizations, this is done in the form of "OKRs" or "Objective" and "Key Results."?

The stress is driven by everyone waking up from execution mode to realize that we need specs and designs to make accurate estimates of the scope of work. While some organizations/teams do a great job fostering a culture of thinking ahead, most others find themselves in a stressful quarterly scramble.?

The good news is that there is an alternative. Regardless of the culture of your team, a simple habit that can save you from this - and they are Exploration OKRs.

What are exploration OKRs? How are they different from "normal" OKRs?

When product teams set their OKRs, their OKRs are created based on how they'll use IC/individual contributor engineering time. As an example, an OKR might be -

Objective: Create a frictionless checkout experience for our logged-in customers (pillar 3 of our 2022 strategy)

Key Results for Q4

• Improve checkout completion rate by 10% (from 50% to 55%) by shipping Ux improvements xx and yy
• Reduce checkout abandonment rate by 10% (from 50% to 45%) by launching checkout reminder emails

These are examples of "Execution OKRs." Each Execution OKR involves us shipping one or many products and it comes with the expectation that we'll stay close to progress via stand-ups with our engineering team, go-to-market team, etc.?

Exploration OKRs - on the other hand - are OKRs that do not involve IC engineering time (exceptions involve partnering with experienced tech leads). Exploration OKRs are created in collaboration with the rest of the cross-functional team to validate problem statements and hypotheses.?

There are 4 kinds of Exploration OKRs:

(1) User/customer/partner research: This could be a mix of qualitative research (interviews) or quantitative research (surveys) that help us better under our user/customer/partner needs. This is typically done in partnership with user research, product marketing, business development/partnerships, or sales teams

(2) Data analysis: This typically involves correlational or causal analyses of existing user date and/or available 3rd party/macro data. This is typically done in partnership with our data science or strategy/operations teams.

(3) Strategy: This involves writing up a strategy document. This is typically in partnership with the entire team. If done well, this typically only needs to happen once every ~4 quarters.

(4) Design: This involves getting to high fidelity mocks/prototypes. This is done in partnership with our design teams

Done well, exploration OKRs create a pipeline pre-planning that look something like a research pipeline for a pharmaceutical company. We start by building conviction around a problem/opportunity space, begin validating it by talking to users/customers or studying their behavior via data. Then, we spend time sharing our path forward in words - by creating or updating our strategy doc - and then in visuals.

This isn't necessarily an illustration of the amount of time required. If we're talking about a small feature, this process can be done in a matter of a couple of weeks. But it can take significantly longer for larger features.?

All investments here are governed by the Law of Shitty Planning - Any sacrifice in rigor before the planning process will result in 10x the heartburn after the planning process.?

This makes sense. Why is it hard to do?

It is hard to do because there is the classic urgency vs. importance trade-off. Execution is always urgent and takes priority in our calendars. But, exploration OKRs help us get ahead and smoothen the planning stress. And the good news is that there are 3 things we can do to make this work:

(1) Align on and share exploration OKRs as part of our planning document. This means explicitly aligning with our cross-functional partners on our commitments as team across the buckets - Research, Analysis, Strategy, and Design.

(2) Schedule time for exploration OKRs just as we do for execution OKRs. For every engineering stand-up on your calendar, we should have a stand-up with our design partners for that design vision or with our team for iterating on our strategy doc. ?

(3) If we're new, resist the temptation to "just ship something." It is tempting to fall prey to the temptation to just put a spec hastily together to keep the IC engineers busy.

The unsaid problem with executing on poorly scoped ideas is that they will inevitably either not ship or will need to be rolled back. Every idea we decide to build brings tremendous cost with it - for us, the team, and the organization. Morale wins in the short-term will result in morale-loss in the long term.

The better approach is to buy time.

Three superior alternatives that we have at hand are:

(a) Invest in product craftsmanship: Read user support tickets, audit the existing experience, prioritize and fix all those "fast follows" that never got built. These often deliver more long-term business impact than we realize.

(b) Invest in data and technical foundations: Work through the tech leads' wish list and set the team up for faster iterations moving forward.

(c) Help other teams who are hustling to meet a deadline. Pay it forward.

These will always be better decisions for the organization instead of engaging in low conviction busywork.?

Again, it is challenging. Very challenging. When we're new, it is the opposite of "hitting the ground running." And it always hurts in the short run.

But, taking the time to build conviction that we're working on the right thing is what separates the amateurs from the pros. It is the difference between velocity and speed.

And, optimizations for speed are typically a result of prioritizing business and political considerations over user needs. When we optimize for velocity over speed, we recognize there are times when we need to slow down all activity to ensure we're getting the direction right and investing in the highest leverage problems and solutions.

?That, then, gets to the power of exploration OKRs. By helping us build conviction in the direction we're headed, they help us create execution OKRs that create meaningful impact for our users that stand the test of time.?

And, most importantly, they help us stay on the right side of the "Law of Shitty Planning" - Any sacrifice in rigor before the planning process will result in 10x the heartburn after the planning process.?