You may be familiar with the OKR framework, I've written briefly about it in the past. I realise now that I left out some key pieces of information, and two things I regularly get asked are:
- Clarity on is how to move from OKRs to launches to landings.
- An overview of my annual process
Definitions
Let's start by getting on the same page with regards to some of the terminology.
OKRs - short for Objectives and Key Results. Based on the strategy defined for the product, the idea is to set relevant objectives that the team can really focus on. And to measure success of each objective, key results should be relevant, time durable and measurable.
Launches - probably the most straightforward. Launches come in all sizes, and can be as simple as just changing some UI text or as complex as building a whole product. Each launch should contribute to moving one or several key results (KRs).
Landings - when something has launched, it is critical that the measurement is set up to track the impact of the change. This is most effectively done through experiments. A launch has landed when it meets the expectations of the movement it was intended to have on the KRs.
The planning process
By no means is this the best way, and I'm always iterating on aspects of it. But there are some durables that are worth calling out:
- Be flexible - strict planning cycles may be useful to form structure, but being able to easily swap project priorities is critical to growth
- Get the strategy and OKRs right, the rest follows naturally
I work in a rather established team, the product is relatively mature and the ecosystem is pretty stable too. So the timelines here may seem quite long, but it works for us.
Come July: educate and align
This is the time we kick off next year's planning process. Yes, 6 months is a long time, but to get it right unfortunately does take a long time. There's a lot of education, information sharing and alignment to get done, and the more teams and people, the longer it takes.
I won't spend too much time here, will likely follow up with another post on how to do this successfully, but the output needs to be a high level strategy for the product with engineering, UX, sales, marketing, legal, etc all bought in (after ideally having also contributed).
It should be ambiguous enough to allow others to have freedom to flesh it out further, but defined enough to provide the right restrictions for work and priorities. Key components of this include:
- A mission
- 1 or two core metrics
- 3-5 headlines
It can look something like this (for a sock company):
Mission: Funny socks is on a mission to make people's feet look and feel happy.
Core metrics:
- $ ARR (and end of year projection based on last 7 days)
- Daily new customers (cumulative, starting from 0 on January 1st)
Headlines:
- Same-store growth: Increase sales from existing customers
- Acquisitions: expand to new markets and increase sales in existing markets
- Innovation: invest in new creative products
- Customers happiness: don't ever let our customers down
Come September
The high level strategy should have been set by now. This is the time to dig deep to develop a detailed strategy for each headline and the OKRs.
As mentioned before, there's no “right way” of doing any of this but in my team we have cross-functional owners for each headline identified. Depending on your product, the owners will differ but in my case it's a working group consisting of one product manager, engineering lead and UX lead. The key is to keep it relatively small or you don't make progress.
The output here is a document for each headline outlining a clear strategy, 3-5 prioritised objectives and 3-5 prioritised KRs for each objective.
It's important to prioritise the OKRs to help focus the investment should there be an abundance of projects and ideas. I usually follow this prioritization:
- P0 - things are on fire until resolved
- P1 - most impactful for the business
- P2 to P3 - nice to have, but not the end of the world if not delivered
Come November
Brainstorm time! I usually set up 1hr sessions with the engineering teams, include any other relevant team and focus the brainstorm on the KRs. The KRs go up on the wall and everyone adds project ideas on post-its for each KR.
Now if you've defined 5 objectives and 5 KRs for each objective, you'll never stop brainstorming. Here's where the priorities come handy. Just take the P0s and P1s, which should hopefully mean you have at most 5 KRs to brainstorm for. Set up an hour per objective and only talk about the KRs relevant to that objective. This helps idea generation as it focuses thinking and reduces the need for people to context switch.
Collect all the ideas and take them away with the smaller working group to prioritise according to your business objectives.
By the end of November / early December, the output should be a prioritised list of projects for either Q1, or the first half of the year. We go with half-year planning but with the understanding that projects are flexible and new ideas (specifically for the lower priority OKRs) spring up all the time. If a better idea comes along, we re-prioritise accordingly but if you've been through and included the right people, this shouldn't happen too often.
Come January
You and the rest of the team should be in full on execution mode. I'll likely write another post about this in the future.
Come June
Similar to the brainstorming sessions in November, this time is used for planning out projects for the second half of the year. Output is the same, list of prioritised projects.
Going from launches to landings
Launching stuff shouldn't be considered success. In fact it may even be the case that some of your launches harm your business goals. So here's my checklist of things before launching anything, even to beta:
- Well defined success metrics, should actually mostly reflect the OKRs but should also be exhaustive enough to cover other aspects that you'd like to maintain.
- A launch document, outlining all the steps needed to roll out a change, and the criteria for when to further expand away from alpha / beta.
- A launch dashboard set up to track all the defined success metrics. I look at mine every morning.
This process is unique for every launch so does require some thinking and setting up. You should have defined success metrics for each launch, along with what the expected impact will be on those metrics. You hit the expectations, you've landed. And if you don't, spend time investigating why, and decide if it's worth going ahead with the launch anyway.
I hope this was useful. And like I mentioned before, there is no perfect formula to any of this. Trial and error, and continued refinement of your process are your friends. Everything is always evolving and undergoing change. You just have to make sure it's not decay.