When work started using OKRs to plan for our quarters a few months after I started with the team, I had a minor panic moment. I didn’t know how to define OKRs nor use them. 
I knew roadmaps. But roadmaps, as we’ve discussed before, have only caused us problems with the other teams that we work with. Unfortunately though, so do OKRs when they are not done correctly.
Note: The guys over at Google can do a better work at explaining what OKRs are than me.
When we first started using it, our problems with OKRs manifested in several ways:
- Our OKRs seemed too ambitious. By the end of the quarter, we accomplished nothing.
- Our OKRs seemed not ambitious enough. By the end of the quarter, we somehow accomplished everything. And that was suspicious.
- Our OKRs and our sprints were not aligned. We were still doing things that we haven’t prioritized. A lot of them.
You can imagine how the marketplaces we worked with felt when our quarterly outlook did not match their expectations. 
Quarter after quarter of failing, learning, and trying again. I have to admit that at some point I started dreading the end of quarters; because it meant we have to start to define OKRs again.
Of course, eventually, we started to get better with defining our OKRs. And we finally started feeling that we were actually completing and accomplishing things that were really important. So here’s a story of our learnings, the changes we made to define OKRs better and how all these impacted our quarters and sprints. With some practical examples to help follow each step of the OKRs.
*****
Step 1: Defining Objectives
Objectives are the north star. They provide direction and relevant purpose to help make sure that the product is growing quarter after quarter. So that means defined objectives will set the tone for the rest of the things that get prioritized for the incoming quarter.
So to help us make sure we’re setting the right objectives, we’ve written up a couple of criteria:
1. Our “mother team’s” vision and strategy.
Note: Mother team is what I call our umbrella team who can have multiple teams under its wing, including ours.
As soon as we kick off the process to define OKRs, we always ask ourselves if we are capable of directly contributing to the mother team’s vision and strategy in the coming quarter.
If the answer is yes. Then happy days! We have an objective! Contribute to the mother team’s objective. 🎉
But if the answer is no. Then we need to understand why it’s a no. And if it’s alright that it’s a no. Or if we should set out to turning that no to a yes next time.
2. Our team’s own vision for our product and our strategy to get there.
This should just go without saying. Every quarter, our objectives focus on picking away at our strategy – the steps we’ve defined to be the key to getting closer to our product vision.
3. Internal improvements we need to do.
Or as I would like to call it – keeping the house clean. These are pretty much all the things we need to do to keep the machine running. From reducing technical debt to having proper alerting and monitoring without inflating our infrastructure costs. Sometimes it’s even just to continue iterating, improving, or even removing existing features.
While the first 2 inspirations were mostly focused on new development, this one focused on things that were already in production.
Practical Example:
Let’s pretend you are an owner of a shopping site and your company vision is to be the #1 bookseller online that makes a lot of money. So your quarterly objectives should support that vision.
Note: all examples are fictitious. Any resemblance to real-world products is purely coincidental.
*****
Step 2: Knowing what success looks like
So the objectives are defined. But we still need to know how to actually achieve them. That’s where key results (KRs) come in. Key results are a set of quantifiable statements that tell us what metrics we should be moving to know that we are reaching the objective.
When defining these KRs, we have some questions that help guide our thinking:
- What are the problems that are stopping us from achieving the objective?
- And how do we solve those problems?
- What are the changes that we want to see in our users’ behaviors?
- At the end of the quarter, what would we have wanted to learn?
- What do we need to do to achieve our objective?
And the numerical equivalent of those answers become our key results.
Practical Example:
So going back to our #1 bookseller online that makes a lot of money example, what are the possible key results if we apply learnings from above? How can we increase our revenue by 20%?
But Key Results are also hypotheses. We choose the key results that we think are needed to reach our objectives. In the example above, what if you did increase the conversion rate for abandoned by 5% as well as the number of new accounts by 20% – but your revenue only increased by 15% at the end of the quarter?
Were you a complete and utter failure? Yes. ☠️
Just kidding! Not at all. Maybe you fell short of your objectives. That’s alright. It’s perfectly normal. The important thing is you understood why. Maybe you focused on the wrong key results. Maybe the improvements you aimed for were too low. The learnings you get afterward are as valuable as achieving the objective.
*****
Step 3: Assigning possible projects to the Key Results
True story: We used to scramble, once the quarter started, for things to do to get our OKRs ball rolling. As a consequence to this, we were not ready at all to run our sprints. We sometimes ended up not having any OKR-related actions at all until, at best, middle of the quarter.
So we made some improvements. We started identifying projects that we think have the potential to impact our Key Results as soon as we’ve started to define OKRs.
Projects can vary. As long as there is a likely impact on the key result, then they can be a project. Our project list usually looks like this:
- Research to validate a problem
- Tests to solve validated problems
- Delivery of validated solutions
- Iteration of solutions already in production
- Measuring and tracking things
But again, let me repeat – potential projects. As mentioned above, ideas that we thought have the potential to move our key results. We realized that it’s good to have these prepared when the quarter starts out. Prioritized, of course. That meant we got projects rolling almost immediately as soon as the quarter started. And that meant we were able to iterate or completely change the projects. Fail fast, learn fast and all that jazz.
Doing this exercise also allowed us to identify quickly the resources that we will need and the dependencies that we might have, should we end up pushing forward with any of these projects. And have them sorted out early on. On occasions when we couldn’t sort them out, we cut back on our ambitions.
Practical Example:
Ok, so now we know the Key Results that will help increase the revenue of our fictional online bookstore. What are the projects we think can work on to move them? Do we have any dependencies for any of these?
*****
Step x.5s: The Inbetweeners
We do not leave in an isolated world. Although my introvert self sometimes wish that this was the case. Sometimes, other teams need things from us to complete their own OKRs planning too.
The thing is, like everything else – helping other teams meant we need to spend time and effort on a project that’s not entirely ours. So we can’t say yes to everything all at once. We have criteria that help us prioritize the things that we have to support:
- The impact of their project on our product. Does it match our product vision? If yes, great! If not, then it doesn’t make sense for us to do this at all.
- The relevance of the project with any of the OKRs that we have defined. If there’s a match, it’s easier to justify prioritizing the project.
- The complexity of the project. Do we have the time and pairs of hands to work on this without compromising our own priorities?
When we end up prioritizing the projects that the other teams need us to help them with, they are then analyzed, estimated, groomed, and made ready to go into a sprint just as if they were our own project.
*****
And we lived happily ever after
I wish. But we are breathing a lot easier now during the quarters because of the improvemests we’ve made in the way we define OKRs.
- We get buy-ins for the OKRs we’ve defined much faster than before (when we’d still get a lot of arguments against the things we’ve prioritized).
- Having possible projects defined early meant we could share this with other teams to get early feedback. Sometimes even early help.
- This also meant that we were able to identify dependencies early. Dependencies we have on other teams to help us negotiate prioritization. And vice versa.
- Having clearer KRs that we know how to measure also allows us to track things frequently. This means we can change projects as soon as we notice that they the projects are not moving any KRs at all.
- But more importantly, we were finally able to see the impact of the things we’ve accomplished during the quarter on our product.
We’re are not perfect (yet), of course. We still accomplish less than what we (and others too) expected sometimes when our OKRs turn out to be overly ambitious. And people still ask us this question:
So what new feature are you building?
Oh well. Room for improvement means maybe I’ll have a post after this one that pretty much talks about:
How we’ve perfected the way that we define OKRs and the way that we prioritize for the quarter.
Maybe. 🙂
Bottom line, OKRs is a tool. It’s a framework. It should help all of us to improve the way we work, how we align with other teams regarding priorities and how we measure impact. If it’s just adding more headache and unnecessary anxiety, then it’s time to revisit how we define OKRs. But it’s important to make sure that we understand where the friction lies so we acn address them one by one.
*****
TLDR;
- How we define OKRs and priorities for the quarter was not the best
- Which meant having a negative impact on the team
- And unmet expectations for the teams that we work with
- So, of course, we had to make changes.
- The objectives that we’ve set for ourselves were improved. We aligned our objectives with overall company priorities, our product vision, and general product hygiene.
- We made sure the Key Results for every objective are measurable and that they paint a good picture of what success looks like.
- The team also started identifying possible projects that we think can affect our Key Results earlier in the game.
- But we didn’t forget taking into consideration teams that needed help from us to complete their own defined OKRs.
- We became more aware that a lot of these things are hypotheses. And there’s no need to beat yourself up when the hypotheses turn out to be wrong. Knowing why they turned out wrong is key.
- And lastly, we got better. But there’s always room for improvement. 🙂
*****
If you have any feedback, questions, or even violent reactions – please don’t hesitate to leave a comment or send me a message at hello@kaxuson.com
And in the future, if you’d like to receive updates from me, links to interesting articles and conferences about Product Management, and other interesting Technology reads to go with your morning coffee, then please sign up for my newsletter here. Don’t worry, I hate spam too. It’s also GDPR friendly (Mailchimp said so).