Establishing an OKR Learning Engine
Product managers must ensure that their products drive business progress; that is, they cannot solely build products that make users happy. Furthermore, product managers are responsible not just for product metrics, but also for improving the processes and skill sets of their teams.
To help guide products towards business needs, many product organizations use a framework called objectives and key results (OKRs). In our coaching practice, we’ve seen that OKRs have enabled PMs to ship significantly more value with significantly less effort. And, we’ve found that establishing a learning engine built around the OKR framework enables teams to consistently level up over the quarters.
We wrote this essay to help you establish a OKR learning engine within your product org. Within, we discuss the fundamentals of OKRs, and we share how to set good ones for you and your teammates. By doing so, you’ll create certainty and visibility for stakeholders and managers, you’ll have the ability to quickly react to changing market conditions, and you’ll empower your teams to strengthen its processes and capabilities over time.
The OKR framework for PMs
OKRs have three main components: 1) objectives, 2) key results, and 3) reflections. The goal of OKRs is to empower teams to learn more effectively from the iterations that they ship, and not to set hard quotas or drive performance reviews.
Objectives are qualitative aspirations that represent the direction that the business seeks to move towards, rather than a tangible end state. An objective should not be focused on the features that a product has, nor should it contain metric targets to hit.
Key results (KRs) are quantitative goals that represent the progress that teams have made towards the objective. Good KRs are measurable, and they shouldn’t contain specifics about which features to ship or deadlines to meet. Note that key results and key performance indicators (KPIs) are interchangeable, so use whichever word you feel more comfortable with.
Reflections are regular check-ins where the team reviews its own progress against the targets they initially set. These reflections are essentially retrospectives:
What did we do well?
What could we have done better?
What will we do differently next time?
As a PM, you should set a single objective for the quarter. If you set too many objectives, then your team will lose focus, and you’ll wind up confusing stakeholders and executive leaders. This objective should ladder up into the mission and the vision for the business.
Once you have an objective in place, you should then work with cross-functional counterparts (engineering, design, marketing, sales, support, etc.) to select a handful of key results that support your chosen objective.
Here’s a table to help differentiate between objectives, key results, and reflections:
Let’s say that you’re the PM responsible for a short-form video platform, similar to TikTok or YouTube Shorts. Your objective might be “become the best way for creators to be discovered”, or it might be “change the way that people around the world spend their free time”, or it might be “help all kinds of people share their unique voices through video.”
Different objectives require different key results. So, let’s focus on the objective to “become the best way for creators to be discovered.” If that’s the case, then your team (engineers, designers, marketers, support, analytics, etc.) might jointly choose the following three key results:
Increase “creator subscribe rates” from 1% per video to 3% per video
Improve average shorts viewed per session from 5 shorts to 8 shorts
Strengthen average hashtags visited per session from 1.6 hashtags to 2.4 hashtags
Note how none of these key results are focused on delivery outcomes. That is, each key result is focused on the value that end users receive, rather than on the process through which teams deliver value, such as “reduce average epic completion time from 2.8 months to 2.3 months” or “ship 12 features by the end of the quarter.”
Then, as the team ships various experiments and iterations, they should expect to meet back up every 4-6 weeks to identify whether they’re tracking towards the goals that they had set.
In these team reflections, they might identify that “creator subscribe rates” have successfully jumped up to 5% per video, but that shorts viewed per session dropped down to 3.6 shorts per session. These learnings should trigger candid discussions about whether subscription rates are higher-priority than shorts per session, and clear guidance on the next set of iterations that the team should invest in.
Why PMs derive value from OKRs
As a product manager, you’ll find that the OKR learning engine provides two core benefits for you, your teammates, your stakeholders, and your managers:
You stop focusing so much on delivering specific features, and you focus much more on actually moving the metrics that matter
You tie together customer needs and business success, without overoptimizing for either
When your organization has successfully adopted the OKR approach, you’ll have fewer conversations about shipping particular features by particular dates. This result stems from the fact that no feature will singlehandedly improve the KR targets. Instead, the full set of experiments and iterations that we ship are the driving force behind KR progress.
And, by leveraging OKRs, you’ll ensure that the customer pains you’ve prioritized actually matter for business success. This outcome is crucial, as customers have infinitely many problems for you to solve; you have to select the pains that actually matter to the business, and not just the pains that you hear most frequently from customers.
Using OKRs for the right purpose
As product managers, we need to keep in mind that frameworks are not silver bullets; that is, OKRs can’t address every component of the product development process.
I frequently see teams attempt to replace vision with OKRs. This approach doesn’t make sense, because the objectives within OKRs need to ladder up into a cohesive “future direction” for the company as a whole. OKRs should feed into the vision, and should never fully replace it.
Similarly, many teams use OKRs as a way to skip past the hard work of business strategy. This approach is also misguided, as we cannot set compelling objectives for our OKRs without understanding the broader tradeoffs that we’re willing to make as an organization.
OKRs do not drive tradeoff decisions; only strategies can do so. A good strategy requires a diagnosis of the business problem to overcome, as well as clear guidelines to make meaningful, painful tradeoffs across the team.
If you’d like to establish a more compelling vision or spin up a more thoughtful product strategy, Product Teacher provides corporate workshops. We’re also actively creating an on-demand video course for individuals to hone their vision and strategy skills; sign up for our newsletter to be informed when it’s ready to be released.
Crafting defensible OKRs
I’ve found that the most difficult part of successful OKR implementation boils down to the details. A significant percentage of proposed OKRs fail to be effective because the selected objectives and key results aren’t appropriate.
Let’s identify the anti-patterns that we should avoid for establishing objectives, setting key result targets, and running reflections.
Avoiding unproductive objectives
As product managers, we need to make sure that our selected objectives can actually be addressed at a quarterly level. That is, our objectives should not sound like a 3-year vision or a 5-year vision.
Many ambitious PMs have set quarterly objectives such as “become the market leader in XYZ category”, even though their companies don’t have any products in that category yet. Too much ambition will create confusion and frustration for teammates.
We can break down “become the market leader in XYZ category” into quarter-by-quarter objectives instead.
For example, maybe our first objective is “deeply understand the needs of customers in XYZ category”, and we can track key results such as the number of customer interviews we’ve conducted and the number of wireframes that we’ve shared in user testing.
And, maybe a future quarterly objective might be to “understand customer willingness-to-pay”, where we run pricing tests and bundling exercises.
Over time, as we build our presence in XYZ category, we can then eventually say “overtake the current market leader in XYZ category”, and then afterwards “maintain market leadership in XYZ category.”
We should also avoid setting any objectives that can only be achieved by predetermined feature delivery initiatives. For example, we probably shouldn’t have any objective that sounds like “be as similar as possible in our feature set with our top competitor.”
Any time we run after our competitors, we lose focus on solving the pains of our own customers - and that creates the risk that someone else will take our current customers away from us.
And, any time we ship features for the sake of shipping features, we fail to empathize with the actual pains that our customers have. So, we shouldn’t have objectives like “enhance our products with AI/ML features”, because we focus too much on the features and not enough on the underlying pain that we want to solve through our features.
Preventing unactionable key results
Key results need to drive action. For our teams to take real action against our goals, we’ll use the SMART acronym:
Specific: the goal is focused on improving a specific metric, and not just “general improvement” across the board
Measurable: we can measure both the starting point of the metric as well as the progress we’ve made over time
Achievable: we have a good shot at actually reaching the goal this quarter
Relevant: the goal creates value for our customers and captures value for the business
Time-bound: the goal has a deadline of one quarter
As I mentioned earlier, the team needs to be the one to pick its own goals. We want them to commit to pursuing these goals, and we want them to be active decision makers in this process. As PMs, we can suggest key result targets to our teams, but they should ultimately feel like they set the goals themselves, rather than having you dictate the goals to them.
Furthermore, we want to make sure that the targets that our teams have set are reasonable. If they’ve picked a high target that is extraordinarily difficult to achieve, then they’ll likely burn out. On the flip side, if they’ve picked a target that is way too low, then that target isn’t going to motivate them to take action.
We should generally aim for KR targets that are mostly achievable, i.e. the team can achieve 60-80% without too much effort but will need to invest a bit of elbow grease to aim for 100% of the target.
Reflections
As a reminder, the point of OKRs is to learn and reflect on progress, not to meet hard quotes. As your team pushes forward on the 3-5 key result goals that they set, each goal will be in one of three states:
Met: The metric is at 60-80% of the goal
Exceeded: The metric is more than 80% of the goal
Not yet reached: The metric is less than 60% of the goal
None of these three states are inherently good or bad. Instead, each state yields valuable knowledge that can only be surfaced through team reflections.
When the metric is in a met state (i.e. your team has reached 60-80% of the goal), then the team should consider these questions:
Which of our processes and approaches were effective?
Which of our bets played out, and which ones didn’t?
What could we have done better to achieve more?
Did anything surprise us so far this quarter? Why or why not?
If the metric is more than 80% of the goal in the exceeded state, we should consider these questions instead:
Why did we set our goals so low, and how do we avoid doing that in the future?
Was the market kinder to us than expected? If so, what caused this to happen?
What are ways for us to take better advantage of favorable market conditions next time?
And if the goal is not yet reached (i.e. our progress is not more than 60% of the goal thus far), then we’ll want to cover these questions:
Which processes or approaches didn’t work out the way we wanted them to? Why?
Was our lack of progress due to competitive action? If so, how could we have been more resilient to these kinds of competitor actions, and what will we do differently next time?
Was our lack of progress due to unfavorable markets? If so, what changed in the market, and why? How will we mitigate these issues next time around?
As with any retrospective, your highest priority is to ensure that your teammates feel psychologically safe with one another. Only when we feel safe with our teammates will we be able to provide and listen to constructive criticism.
If our team environment does not provide psychological safety, then these reflections will not yield helpful improvements, and our products will continue to lag behind the products of our competitors.
Refreshing your OKRs
As we kick off each new quarter, we should work together with our teams, our stakeholders, and our executive team to consider whether we’ve “maxed out” the previously selected objective. Does it make sense for us to keep the objective that we picked last time, or would a different objective provide our customers and our investors with higher ROI instead?
Once we’ve settled on a chosen objective, we want to put our team back in the driver’s seat to select a new set of 3-5 key results for the upcoming quarter.
Keep in mind that many metrics demonstrate “diminishing marginal returns.” That is, if you keep the same metric from last quarter, you’re probably not going to make as much progress this quarter as you did last time, because most metrics have natural ceilings.
For example, tripling a particular conversion rate from 1% to 3% is probably achievable. Tripling this same conversion rate from 3% to 9% is probably quite difficult. And of course, tripling this same conversion rate from 33% to 100% is probably impossible.
Closing thoughts
As product managers, we can drive significant customer value and business value by framing our product development efforts in the form of objectives and key results; this framework is commonly abbreviated as OKRs. Our goal is not to pursue set quotas, but rather to encourage our teams to actively learn from customers as they iterate.
When your organization has OKRs in place, you’ll have an easier time aligning stakeholders and executives towards creating customer value. But, keep in mind that OKRs can be poorly implemented; many “traditional” companies might embrace the ability to measure progress, but might actively punish teams for missing their targets rather than creating a safe space for teams to learn and iterate.
By focusing on being a learning-first organization rather than a delivery-first organization, we can create customer value much faster than competitors can, leading to an insurmountable advantage over time.
Thank you to Pauli Bielewicz, Mary Paschentis, Goutham Budati, Markus Seebauer, Juliet Chuang, and Kendra Ritterhern for making this guide possible.
