OKRs applied to a services-based company
Recently me and my team have been applying Objectives and Key Results (OKRs) at Whitesmith, this time not only at an organisational level but also across all clients’ Projects and Products. This made me research further about this topic.
The truth is that OKRs are easier in theory than in practice, and there are common questions and mistakes that we all do as soon as we start applying OKRs.
There are tons of books and resources on the web about this topic, there are two or three references that actually had the biggest impact in my re-understanding of OKRs:
- Outcomes over Output, by Joshua Seiden. A book recommendation from Daniel Zacarias, whose blog about Product Management you should definitely check.
- This 2 part blog post by João Craveiro (Senior Product Manager at Onfido), which I also truly recommend.
What you’ll read bellow is very much a recycling of these resources written from my perspective and experience, plus ideas when it comes to applying OKRs to a services-based company as Whitesmith.
This is an ongoing experiment for us and about which I’m happy to hear your thoughts.
Projects vs Products
Before we go into details, we first need to acknowledge that at Whitesmith, depending on the type of work at hand, we can approach our client’s work either as a Project or as a Product. This context influences how we set OKRs.
For us, Projects have a defined scope over which we don’t have much control — the features are defined, what we can change are its implementation details and part of its prioritisation. Products are Projects which we have more control of its scope, and speak with its customers, analyse analytics, and so on. In other words, in the later we have more responsibility to ensure we are building the right Product.
OKRs is a framework that suits very well in the context of Products, but not so much under Projects. Some people even say they shouldn’t be used at all for the latter.
Nonetheless, the point I want to make is that, before defining OKRs, we need first to ask ourselves:
Are we setting this specific OKR as a Project or as a Product?
You will better understand why later in this article.
Key Results must be Outcomes, not Outputs
The most important factor when setting Key Results is to define them as Outcomes and not Outputs. If you do this, you are half-way to setting good Key Results. This is easier said than done though, since our brain will often push us toward Outputs.
But, what are Outcomes?
Outcomes are human behaviours that drive business results.
For example, if the current goal for your Product is to increase its revenue, then you need to understand what users’ behaviours may lead to that revenue increase.
If what drives revenue is to increase the selling of t-shirts, then your KR could be: “Increase T-shirts bought by 10%”.
And notice how I’m setting this KR from the user’s perspective: I’m defining it as “Increase t-shirts bought”, instead of “Increase selling of T-shirts”. This is a subtle but important difference, that enforces the fact that we want to influence the users’ behaviour.
Key Results as “Deliver X features by end of the month”, “Decrease the number of bugs by 10%”, “Deliver feature Y”, “Introduce Z process improvements ” are not, in the Product context, outcomes. These are outputs.
Key Results should promote learning
To achieve the Key Result named “Increase T-shirts bought by 10%”, you may have several outputs in mind that may or may not bring the results you want.
For example, to increase the selling of t-shirts you may want to try things as “Change the button’s color”, “Increase the number of newsletters sent per month”, and “Deliver X features until the end of the month”.
These outputs are nothing more than experiments; thing’s you’ll do without having certainty of their impact in the users’ behaviour.
Outputs are the experiments you’ll do to achieve your Key Results
Not only that, but as a consequence of this mindset when setting KRs, we can also learn how adequate our target value was for those KRs, and adjust accordingly.
For example, we can learn that the target value we first set for the KR named “Increase T-shirts bought by 10%” was either too ambitious or too low. And that’s fine — we learn and adjust for the next quarter.
Objectives should endure through time
Objectives that endure through time indicate that we have a well defined and stable strategy for the Product.
It’s difficult to say how much time that should be, specially in the context of a services company as Whitesmith, which can either work on 5 year full.-fledged Products, or 2 months MVPs. There’s not a right answer I’m sure.
And this doesn’t mean KRs shouldn’t change at all: you may notice that, even though your effort to make them enduring at first, they no longer make sense. Or better, you achieved your goals and can now focus on a different objective.
Nonetheless, our goal should be to define OKRs that have potential to be re-used quarter after quarter. Because, even if in practice we don’t achieve this, approaching them this way ensures we are enforcing the right thinking.
How do OKRs apply to projects then?
If you research the OKRs documentation existent across the internet, you’ll read many mixed opinions about the combination of OKRs with Projects: Some mention that using OKRs in Projects is forcing something that wasn’t built for that purpose. Others say that’s possible, but only after changing some rules.
We’ve been thinking and discussing this at Whitesmith, and the current proposal is to, in the context of Projects, change our definition of Outcomes to:
In Projects, Outcomes are changes in Key Performance Indicators
This means that these Outcomes don’t necessarily imply the change of users’ behaviour. But they improve the performance of a certain aspect of the Project, which should also be enablers of business results.
For example, for the Objective “Accelerate development in January”, the Outcomes can be: “Increase the number of User Stories delivered by 10%” and, “Decrease the time User Stories are waiting in Quality Assurance by 30%”
I also like to see Outcomes in Projects through the lenses of Second-order thinking. Or in other words, Outcomes should be the consequence of your actions, not the actions themselves: Changing the process for when and how Quality Assurance is done is your action, the decrease of the time spent in QA is the consequence. Applying CI/CD is your action, the increase of the number of User Stories delivered is the consequence.
Should Products only have Product OKRs, and Projects only Project OKRs?
This is an ongoing conversation, and our current opinion is that no: Products can have both Project’s and Product’s OKRs.
What’s important though is to ensure that, as mentioned in the beginning of this article, an OKR is clearly set as either one or other. Don’t mix the two in the same OKR.
OKRs are back as one of the main topics at Whitesmith. We will learn much in the following months about this, and probably even change the opinions we have today — I’m curious to see how things evolve.
I’m Daniel, Product Manager at Whitesmith. Paper Planes is a place where I reflect my experiences and learnings on the craft of Product Management, and where I share them with my team and community.
If you enjoy these, please show your love by tapping the clap button!
You’re also welcome to follow me on Medium or Twitter!
