Best practices after 18 months of OKRs
This article was originally posted in the Ontruck Product blog.
There is a lot of content on the Internet about the theory of OKRs. However, few teams share their learnings after using this framework for a long time. This article has the objective of contributing our learnings to the community. There are two sections: Best practices on defining the OKRs, and Best practices when working on the OKRs.
Some context first
At Ontruck, we have been using OKRs for six quarters already. We have grown from 120 to 170 people in the company, and from 35 to 55 people in the Product, Engineering and Data departments.
We started using OKRs with the main objective of aligning business and product objectives. We defined four cross-functional areas; each of them with a product team, external users, business stakeholders and its own set of OKRs aligned by the company goals.
Best practices on defining the OKRs
The first one is to involve business in the process of defining the OKRs. They are an alignment and prioritization tool. If you do it correctly, you will be able to focus on the OKRs instead of investing your time saying ‘no’ continuously during the cycle. I won’t expand more as this isn’t the focus of this article; although it deserves a new one.
The second best practice is to invest time a month before the new cycle to understand and measure clearly the metrics to move. That way you will have the work prepared, data analysts won’t have to rush to get the metrics, and the team and stakeholders will already have the context.
The third one is to follow a bottom-up approach to propose the OKRs after the top-down information has been shared (company goals, country, and functional plans…). The best approach is to collect ideas from business agents — not just stakeholders–, designers, engineers, data analysts, etc in order to get a richer proposal and build the buy-in on their side. Then, Product Manager and Engineer Lead should do the first proposal of OKRs, collect feedback from Product leaders and its key stakeholders, and iterate as much as needed until the final proposal has been agreed by the PM.
To define Key Results, the best practice is to follow the SMART goals framework. SMART is an acronym for Specific, Measurable, Achievable, Relevant and Time-bound (it has several variants, this is the one I most like)
Specific
Good example — Increase the margin in spot orders in France to 20%
Bad example — Reduce 30% the number of client inbound communications
The first Key Result is great because it’s specific on the region and the order type. The team has a clear focus, they don’t need to worry about other countries nor other order types. Once the team has achieved it, they can replicate quickly to other countries.
However, the second one is problematic because it isn’t specific. “Client inbound communications” is too broad, it includes many communication types (calls, emails, chats…). This clearly means the Product Manager should have invested more time researching prior to setting up this KR.
Measurable
Good example — Increase the % of routed orders in Spain
Bad example — Provide clarity about price & cost to Operations team
The first Key Result has a clear way of measuring it. However, the second one fails at that. It had good intentions, but how will you and others know you have achieved it? If you can’t measure the Key Result, you can’t manage it.
A second tip is to avoid boolean KRs as much as possible, which may happen if the team has a solution in mind. The main reason to avoid them is that a boolean KR doesn’t promote agile and iterative product work. Either you do everything or you fail at the KR. Ask yourself “How can I launch iteratively, and how can I measure the value I’m adding?”. The answer can help define the KR.
If you can’t avoid having a boolean KR, at least make sure it’s 100% clear if you have achieved it or not. For example, add the key requirements and out of scopes. This happened to us when we had to change our chat provider.
Achievable
This makes you think about the number you put as the target of the Key Result. Some questions to make you think:
- Do we understand the limitations and constraints?
- Is this possible and practical?
- Is this KR within our control? If not, will this also be the priority of the other team?
- Can we do this with the resources we have?
- Can we get it done in the proposed time frame?
- Is this number ambitious enough, but achievable? Remember that you should aim for 70% of the target in a normal scenario
Relevant
You can define great theoretical Key Results, but they need to be aligned with the overall direction of the company of that quarter and year in order to be great. Relevant is about the strategy. Some questions:
- Is the KR relevant to the overall direction of the team?
- Will it impact this quarter?
- Does it support other KRs from any team?
- Does it create any conflict or tension with other teams?
- Are you going to use this KR for several quarters? If not, it may not be the best metric. Be careful with proxy metrics (good examples of proxy metrics from Netflix VP of Product)
Time-bound
Remind yourself that some Key Results may be needed before the end of the cycle. Ask yourself:
- When will this KR need to be completed?
- Which teams depend on the outcome of it?
- What does it happen if you don’t achieve it by that date? Will it add any value after?
Best practices when working on the OKRs
The following list doesn’t try to cover all the best practices. It’s a summary of the ones which have helped us make more impact:
- Make sure there is a clear owner in business to move ahead since day one. If there is a disagreement between business functions, or within business and product on a business-related topic, who is the decision-maker? When it’s clear, KRs move fast; when it isn’t, they get stuck in alignment meetings.
In our experience, this has evolved depending on how the accountability was set up. In some moments, we have had a business lead per product team which was the decision-maker; and in others, we have appointed a PM or business person as the decision-maker for a specific topic. Be proactive and scale the problem quickly if you detect a lack of decision. - If the success of the KR depends on the execution of internal users, involve them from the very beginning. Most of the time, those users aren’t used to radical changes nor experimentation. If you bring your solution directly, it won’t have the buy-in and the KR will move pretty slowly. Not only you have to build and iterate the feature, but you need your internal users to adopt it.
One of our teams works on improving the tools used by our Customer Service team. During the last two cycles, we have changed the tool, their processes and the way they organized themselves. In order to achieve that with 100% alignment, we organized workshops so they were the ones proposing the solutions we kind of had in mind, we involved them in every step, we talked to them every few days, and we iterated it weekly. - Even if it’s an internal KR, understand how our users perceive it in order to make an impact. Some times operational teams have internal KPIs which can be used as KRs. If you focus the research and solution on internal pains, instead of the value and perception of external users, you will be blind to the best approach. Include always your external users.
One of our examples is related to on-time rates. That’s a KPI for our Customer Service team, and it has been a KR for one of our product teams. When we first worked on it, we failed because we looked inside at removing internal pain points to improve the tool; instead of understanding the perception of our users. - It can be negative that only one person works in a KR. Most people get unmotivated working alone, and they can complicate themselves. If you are several in the design phase, you will have better solutions.
In the last cycle, we had one KR to do a prototype of a new product. One developer took ownership of it, but he didn’t work proactively with the other engineers of his team. We ended up with a complex prototype, in new technology, and not yet released. If there were two engineers, the result would probably be different. - Always have in mind when you need to release something to have an impact. Some times delivering after a certain date doesn’t add so much value. Take this into account when you scope and prioritize the solution.
We have a high volume of orders before Christmas, so anything related to capture more orders or book the capacity in advance needed to be released before December. Teams had several related KRs, which were scoped and prioritized thinking on this. - Invest time in training and follow-ups. This is part of the mentality that product teams must have; it’s not about delivering stuff, it’s about adding value. If your users aren’t using it, you haven’t added value. We are opening the Product Ops department at Ontruck to help PMs and PDs with this challenge.
One of the most impactful KRs was one about reducing the % of missed calls. The initial thoughts of the team were that we needed to develop an algorithm to prioritize important calls. However, when we analyzed the problem what was happening was that operational agents were logging out incorrectly from the phone tool. We trained and followed upon them, and we reduced from 40% to 4% of missed calls in two weeks.
Working great with business teams is complicated. Setting great goals that impact clearly the business is also complicated. Both challenges require a constant re-evaluation of how we work internally and with other teams, especially because startups grow fast so people and relationships change constantly.
Check the following article to learn about the two exercises we did to improve how we define OKRs, and how we work with them.
Let us know if you have any questions or best practices we can acquire!