How to Adapt OKRs For a Startup
Dave Bailey
CEO of Founder Coach? | Creator of the Venture Scale System? | 3X VC-backed Founder | DM me if you want to join my CEO community (Series A+)
Why OKRs often fail in startups — and how to use them effectively before product-market fit
Objectives and Key Results (OKRs) were designed in the context of scaling companies, such as Intel and Google. They’ve become the undisputed best practice of managing teams in almost all settings. But they can be challenging to implement, especially if a company hasn’t reached product-market fit.
Leadership teams can often end up with a large number of metrics that dilute focus. Objectives are routinely confused with tasks and initiatives, which fail to clarify what’s important. And long planning cycles make them hard to adapt to fast-changing assumptions.
Should startups just abandon OKRs and stick to regular sprint planning?
If this situation sounds familiar, don’t give up on OKRs just yet.
The Benefits of OKRs
The idea of increasing motivation and engagement by defining the ‘what’ and giving your team the autonomy to decide on the ‘how’ isn’t new. Peter Drucker was saying this in the ?50s with Management By Objectives (MBO). Setting clear objectives also helps leaders from jumping in and trying to do the work themselves.
OKRs build on this idea by separating the qualitative ‘objectives’ from the quantitative ‘key results’. This makes it easier to keep track of how a team is progressing, while a common time-frame facilitates group planning and alignment across functions.
However, the most powerful benefit of OKRs is in forcing you to clarify what you’re trying to achieve — what matters most. We all want to work on something important, and OKRs make this explicit.
How to Adapt OKRs to Startups
For OKRs to work in a startup, they need to fit in with existing best practices, specifically agile processes and customer development.
The key to successfully implementing OKRs is to think of them as an extension to your existing agile process.
While some claim that OKRs are at odds with agile, when they’re implemented well OKRs can make your agile processes more effective, by clarifying how to measure success.
Here’s how you can get value from OKRs at an early-stage startup — and avoid the most common pitfalls.
1) Change the Defaults
At Google and Intel, OKR-planning happens quarterly, and each objective has three or four key results on average. However, startups have fewer people, as well as rapidly changing assumptions, so it’s worth reducing the timeframe and the total number of objectives accordingly.
I recommend adopting a shorter planning cycle of four to six weeks, and limiting yourself to just one — or at most two — key results per objective. This does require you to prioritise, but in a startup, focus is essential.
Some best practices are similar. For example, OKRs work better in areas that are building, changing or improving rather than business-as-usual functions, for which simply monitoring KPIs is sufficient. And objectives should be owned by a directly responsible individual, not a group.
2) Identify Your One Metric That Matters
There’s no point in growing a product that doesn’t activate or retain customers. In Lean Analytics, Croll and Yoskovitz explain that some metrics must be addressed before others, and suggest focussing on one metric, depending on the stage of your startup. They identify five such stages and explain the objective of each:
- Stage 1: Empathy — ‘I can solve a problem that a reachable market will pay for.’
- Stage 2: Stickiness — ‘I’ve built the right features that keep users around.’
- Stage 3: Virality — ‘Users and features fuel growth organically and artificially.’
- Stage 4: Revenue — ‘I’ve found a sustainable, scalable business with margins.’
- Stage 5: Scale — ‘It’s time to scale up.’
If you can figure out which stage you’re at, you can identify the One Metric That Matters. This should form your startup’s company-wide OKR.
Since your planning cycles will be short, you might not impact your One Metric That Matters and go to the next stage. In this case, you may carry over the same objective from one cycle to the next, until you get the results you need.
3) Craft OKRs as Customer (and Team) End-states, Not Tasks
In a startup, there are only two things that matter: your customers and your team. Therefore, every OKR across the business — at the company level, functional level, and individual level — should serve either your customer or your team. Period.
If this jars with you, it’s probably because your objectives or key results are actually tasks and not end-states. If you take just one thing from this essay, let it be this:
Great managers think in terms of end-states, not tasks.
Defining end states is hard. We all start as ‘doers’ and we instinctively want to solve problems. Luckily, I’ve found a useful hack: start with the task and work backwards to the objective. Here’s the basic idea.
- Identify the intuitive next initiative, e.g., launch a new website.
- Work out how you could measure whether the initiative was successful, e.g., increased conversion rate of visitors to leads.
- Translate this key result into a customer- (or team-) focused objective, e.g., make it easier for interested prospects to sign up.
This is where magic can happen. There are usually more efficient ways to achieve the new OKR than your first idea and these subsequent ideas may lead to further iterations of the OKR as you tease out what’s really important.
The same principle applies to team-related objectives. For example:
- Intuitive next initiative: move the office.
- Measurable key result: increase average employee satisfaction score.
- Team-focused objective: create an environment where the team can do their best work.
Notice how the reverse-engineered objective is more inspiring. This is because it clarifies what’s important — the team — and it remains flexible if conditions change (an unexpected hiring freeze, say).
4) Ensure Key Results are numeric
Identifying quantitative metrics, such as conversion rates and volumes, allows you to define the success metric ahead of time. When you’re improving an existing product that’s already in the market, many OKRs boil down to simply improving the numbers.
But what if the product isn’t built yet?
In the absence of customer metrics, many teams are tempted to substitute quantitative metrics with lists of tasks. I recommend keeping your plans and OKRs separate, but how do you choose a quantitative key result when the product isn’t ready and you can’t measure it? In that case, I suggest you choose the key result and don’t measure it.
Clarifying the eventual measure of success can help you launch a more minimal product faster. When building your MVP, ask yourself whether you can measure the key result without building the feature. If you can, consider launching first, taking an initial measurement of the key result, and building that feature later. Not only will you release faster, but you can measure how the feature performs.
Remember though that not all key results are objective. For example, the subjective opinion of your customers matters too and you may decide to quantify this using satisfaction surveys and polls. In these cases, write out the specific questions that you’ll ask at the beginning of the period, so it’s clear how satisfaction will be measured.
5) Iterate and Report as Often as Possible
If you define your objectives and key results in terms of customer (or team) end-states rather than tasks, teams maintain the flexibility and autonomy to plan sprints focused on OKRs (which essentially become Sprint Goals), adjusting quickly as they learn.
While sprints facilitate uninterrupted work by reducing task-switching, OKRs facilitate uninterrupted iteration by reducing goal-switching.
Without clear OKRs to clarify what matters, eager product teams may give in to their tendency for building more features, rather than iterating the ones they have.
Present the status of key results in your weekly update meetings to maintain team focus. This is another reason for not using tasks as key results — your status updates will quickly turn into micro-managing sessions and become irrelevant to most people in the room.
6) Time Spent Planning is Time Well Spent
At the end of each cycle, take time to review the previous OKRs and capture your learnings with a retrospective. Then you can clarify what’s important next.
It’s perfectly normal for your team to complain about taking a few days out to plan. One reason for this is executing usually decreases anxiety, while thinking deeply and strategising tend to induce anxiety.
Taking time to reflect and plan is like eating your vegetables — you may not like it, but it’s good for you.
So, whether you take two days or five days to replan every four to six weeks, you’ll likely reap the productivity rewards from clarifying what not to focus on.
Are You Focused on What’s Important?
By integrating agile principles with OKRs you can create the ideal conditions for focused iteration that help you get results. OKRs can ensure you take time to align as a team, to clarify what matters and what doesn’t.
If you’re struggling with OKRs, I hope this guide helps you to implement them more effectively, and use them to increase your focus on the people that really matter: your customers and your team. After all, without these people, there’s no company.
This article was originally published in The Founder Coach. Sign up here to receive my latest practical articles and how-to guides for founders, investors, and startups.
About the author:
Hi, I’m Dave and I coach tech CEOs from Series A to pre-IPO. You can join me on Clubhouse ??, listen The Founder Coach podcast ??, join my mailing list of 20K founders ??, or learn about my Clarity program ??. For more info, visit Dave-Bailey.com.
Founder Coach | Public Company CEO/Co-Founder | Empowering founders to balance the demands of fast-paced growth
3 年Looking forward to reading this!
I work with leaders who believe there are better ways to grow | Executive & Leadership Coach
3 年Thanks for writing this. I’ve scrapped OKRs almost completely for all startups I’m working with (usually <50 people) and gone with a much simpler model incorporating a lot of the things you mentioned - Focus areas with end states, responsible teams, accountable person, and 4-6 week cycles. It’s much closer to Intercom’s and Amplitude’s product planning models. The startups love it so far because it’s a lot faster than OKRs without all the aligning up/down/across. However it doesn’t fit so well for BAU stuff like CS. Do you have any suggestion here?