21 Dec 21 Product & Agile Delivery
Over the past few years, a growing number of product companies have started adopting OKRs (Objectives and Key Results) to set, measure and align their goals. Frist introduced by Google in the 1990’s, OKR’s help to promote agile goal setting whilst empowering teams to focus their efforts towards the right business metrics. But whilst OKRs can look like a great idea on paper, implementation, and execution of successful & productive OKRs can be more of a challenge.
In our latest Product event, we brought together a wonderful panel made up of talented product leaders who shared their experiences with OKRs across different types of organisations: what makes a great OKR, their pitfalls and some of their secrets to success.
A huge thank you to our brilliant panel:
OKR stands for objectives and key results. They are there to set a common goal and direction for both the company and teams to work towards. They should initially be set at company level so that individual teams can set OKR’s that feed into that company goal. As Holly discussed, the framework should work in three parts; setting the inspiring goal, ensuring that you're always progressing towards that goal, and then reminding yourself regularly of what those goals are. It’s important to hold each other accountable in your team for working towards the OKR’s to ensure that they are constantly prioritised.
OKR’s can be really help teams and businesses to measure their success by outcomes rather than by outputs. They empower people to work for solutions along with making the team feel motivated in their roles, as the OKR’s allow them to understand what they're working on, why they're working on it, and how that contributes to both the company and customer success. OKR’s also help the team to plan the best way to achieve their goals, along with how to use their expertise and skills to get there.
Holly highlighted just how impactful this can really be for teams – she has first-hand experience of senior leadership handing down solutions, resulting in scepticism as to whether what they were building delivered value to the business, leading to a demotivated team. Enter OKRs and it was a vastly different story. It allowed the team to come up with a shared hypotheses of how to achieve the OKR which meant that everybody was engaged. It also meant that they were able to measure value from the start, as they had a good understanding of the metrics and what they needed to change.
Key results are aimed at trying to make a change to a specific area or specific metrics - they are the indicators that show us that this change is actually happening. Whereas the KPIs tend to be more about health and overall ongoing operational metrics. These are the things that no matter what you always need to be keeping an eye on in terms of performance.
One of the most difficult things when you start to structure around OKRs is getting the scale right, as it has to align to the overall business strategy. In true product-thinking fashion, give it a go with a small experiment. You can then start to build from there as you see successes and as you start to get more comfortable with the format.
Morgan highlighted that it’s important to look at where your organisation is as you're entering this journey. Implementing OKR’s in a mature company as opposed to a start-up where things may change more rapidly, can be vastly different.
Callum reminded us that you have to accept that OKRs are not designed for every problem that has ever existed. If you are a product team primarily focused on a strategic direction and you are looking for that kind of outcome-based work, then OKRs are a really good way to structure teams. However, for more support focused teams who are reactive by default with a less strategic focus, OKRs could feel slightly forced. This is where tools like KPIs or service level indicators or service level objectives are a lot healthier to get the desired outcomes as they focus more on the monitoring of performance.
It's about finding what works for you within your context and knowing that it might not be a perfect implementation of it as you would read in a book. OKR’s should be used as a tool to open up those conversations around what it is you’re trying to achieve and how best to achieve it, as Holly explained. “Taking a continuous improvement mentality to anything you do, including OKRs is really important.”
It’s important to not get too focused on perfection. Maggie mentioned a few golden rules, such as having outcome-based thinking around your objectives. With OKR’s, you want to push yourself to the edge of what you think you can comfortably achieve. Be aspirational with confidence, make sure that your OKR is outcome based, and think carefully about what you are measuring.
It’s also important to consider whether your OKR is broad enough – a common pitfall can be when an outcome is too narrow for the organisation. Keeping a broader OKR allows for innovative experimentation.
You also need to make sure that the key results are stretching, but not impossible – it’s about finding that balance. When you first set your key results, you should ideally have about a 50% confidence rate that you’re going to be able to hit them. OKR’s also need to be measurable on a scale, so that you can look back and know you’ve achieved 70% of that, or 60% of that etc.
Additionally, it’s important to ensure that your OKR’s aren’t repeats of themselves. To help avoid this, it’s good to focus on different elements of success; for example a revenue driven one, a retention based one, and a quality based one. When used like this, OKR’s can be a really useful tool for bringing awareness to that success and showing that value comes in different forms (not just revenue).
It’s common to implement OKRs at the start of a quarter. Generally, the preference in a lot of businesses is to plan in quarters and to orientate your OKRs around that. Callum suggested that breaking out of the 3 monthly time cycle could be really beneficial. “Don’t put them in a drawer to open up 90 days later to see if you’ve achieved them”. Depending on the size of your company and your own variables, you should adapt the length of your own OKR cycle accordingly.
It’s really important to understand that whilst OKRs can be very powerful, they can also inhibit progress if we only look at initiatives that we can actually deliver within that usual time box. We need to have the ability to flex out of the time box where necessary to get bigger pieces of work done.
Holly recalls a time where she spent far too long trying to define the OKR’s, as they decided to have the whole team define them rather than just the Product Manager. They spent hours debating what the objective versus what the key result should be. They ended up being halfway through the time trying to define the OKR’s when they should have been executing.
As a product person, don’t be the only one setting OKR’s in isolation, but also don’t just hand them over to the team to define. Work together to set them but make sure that you don’t fall into that trap of needing to run it past every single person in the company. The panellists agreed that allowing flexibility was key – making sure that as an organisation, you’re clear that whilst the OKRs are there but that they’re not gospel, and they can be overwritten. They can be changed and improved, even mid-cycle.
The answer to this is an achievable number. The guidance is often 3-5 OKRs but when it comes to OKR’s, less is really more. It’s far better to set one OKR that you actually focus on and are going to work towards then set 10 which you’re probably realistically not going to achieve. Ideally keep the number small, and keep it focused.
We’d like to say a massive thank you to our brilliant panel for their time and valuable insights. If you have any further questions for them around OKRs, please feel free to reach out to them on LinkedIn! Likewise, if you’d be interested in speaking at our next event or would like to hear more about our current Product & Agile opportunities, please don’t hesitate to get in touch with myself.