Using OKRs to focus on customer problems "Product people - Product managers, product designers, UX designers, UX researchers, Business analysts, developers, makers & entrepreneurs April 04 2021 False Customer-Centric, OKRs, Product Management Process, Startup, Mind the Product Mind the Product Ltd 1147 objectives and key results Product Management 4.588

Using OKRs to focus on customer problems

BY ON

objectives and key resultsIt’s that time of the year again. You need to set your team’s OKRs (objectives and key results) for the next quarter. What should go in there? What shouldn’t? What are you going to focus on? Here’s a quick look behind the curtain at what we’ve learned while setting them and making it effective at YPlan.

Objectives and Key Results (OKRs) is a system for setting and communicating goals and results in an organization. OKRs are a simple way to create structure for company, teams and individuals. If you don’t know what OKRs are or don’t use them at your company have a look at this presentation by Rick Klau from Google first and you probably will.

Our initial attempt at implementing the OKR process turned out to be very “action” focused. It’s not surprising, because we’ve arrived there after periods of company effort focused on one or two very high level metrics. Having a single KPI (key performance indicator – e.g. net revenue or total number of transactions) for the whole company didn’t work, because most individuals couldn’t link their direct day-to-day work to that one metric. Being unable to see how your work is impacting the company’s results isn’t exactly motivating. OKRs, on the other hand, gave everyone 4-5 objectives with 4-5 key results in each objective to play with and the immediate reaction was putting “actions” there (build feature X, close N partners, spend Y$ on marketing to get Z new customers, etc.).

We quickly learned that this approach led to a lot of abandoned / half-finished projects and emphasis on activity rather than outcome. Everyone could now say that they achieved a bunch of actions as per their OKRs set at the beginning of the quarter. However, whether these actions led to any desirable outcome wasn’t at all clear. Typically it didn’t, but hey, at least we’ve carried out the actions we planned, so it’s OK? It’s obviously not OK, and as a result we ended up with an overall lack of focus and lots of time wasted on things which didn’t matter.

Clearly, that wasn’t what we wanted to achieve. Even though it was better than a singular company KPI, and people now had a better idea of what they were supposed to be doing it still wasn’t clear why they were doing it. Going for “actions” is also very susceptible to top-down planning forces, where a manager assigns a list of tasks to an employee without an opportunity for them to have a say in what should be done instead.

So the following quarter we tried to focus on outcomes rather than actions or features. It was then the responsibility of each individual to sit down with their manager and figure out what actions should be done to reach a given outcome. Note that the “KR” in OKR stands for “key result” not “key action”. This approach turned out to work much better, because it stressed the importance of achieving a certain objective, rather than spending time carrying out activities. At the same time it gave individual employees space to come up with that action list themselves and ultimately they are in the best position to know what needs doing.

It was a big improvement over our first iteration, but the resulting objectives still ended up being a rather disjointed set of statements. They could have benefited from a more coherent direction and overarching strategy behind them. Quite a few of them still felt very activity centric, in other words, formulated so that only a particular activity would suffice.

Another problem we had with action-driven or outcome driven OKRs was that all these outcomes were company-focused. For example we’d want to improve gross revenue of the business or make sure that we work with a large number of event partners and so on. While not bad outcomes on their own they really do not guide employees and managers around their day to day efforts (what is the marketing team supposed to do in order to grow gross revenue? Does that play well with what sales team is going to do? When they have a discussion and try to coordinate their actions – how do they choose what to do?).

To address all these challenges we decided to step back and go back to basics. Whichever way we looked at it was always our customers who were rewarding us with their business, so our best bet is to solve their problems as well as we can. So we simply focused on solving our customers’ problems.

That completes the whole circle and helps us set our OKRs:

  • We think that our customer has a problem. We name that problem. (example: “Discovering and booking events on mobile is a pain”).
  • We figure out what the outcome needs to be to make us believe that this problem is solved. (example: “Our customer is going out N times a month, they should use our mobile app at least M times a month to help them go out”).
  • We list the actions we think will address that problem. (example: “Have all venues and events in the city on the app, make sure customer doesn’t need to check other sources of information about the events in app, all events in the app are bookable, etc.”).

We then work on these actions in an agile way by raising hypotheses, testing them and iterating quickly. Steve Blank describes this process in more detail here, but in a nutshell it boils down to picking hypotheses (or, plainly speaking, guesses) which help to validate our vision, crafting experiments to figure out if our guesses are valid or not, running those experiments and gaining new insights. For example we looked at validating whether customers of other lifestyle companies would be interested in booking events via YPlan. We wanted to experiment with partners linking back to our events from their websites or emails and see whether anyone would click on them. Instead of building complicated IFRAME / JS affiliate integrations we opted out for a simple image with a link which allowed us to check overall click rates and save tons of development time while validating demand for the feature.

So now “objectives” in our OKRs are focused on customer problems and “key results” are focused on outcomes, measuring how well we’ve solved a given problem. Focusing on customer problems helps us clarify our thinking and helps us focus on what really matters. It also quickly shows us which of the outcomes are important and which aren’t.

Knowing what customer problems we’re solving has helped us focus our teams too. Mentally connecting your day-to-day work to a customer problem you’re solving is very easy (especially in YPlan’s case where every single employee is also a customer) and helps to keep everyone motivated.

Hopefully this approach will help you too in your next OKR planning session!

objectives and key resultsIt's that time of the year again. You need to set your team's OKRs (objectives and key results) for the next quarter. What should go in there? What shouldn't? What are you going to focus on? Here's a quick look behind the curtain at what we've learned while setting them and making it effective at YPlan. Objectives and Key Results (OKRs) is a system for setting and communicating goals and results in an organization. OKRs are a simple way to create structure for company, teams and individuals. If you don't know what OKRs are or don't use them at your company have a look at this presentation by Rick Klau from Google first and you probably will. Our initial attempt at implementing the OKR process turned out to be very "action" focused. It's not surprising, because we've arrived there after periods of company effort focused on one or two very high level metrics. Having a single KPI (key performance indicator - e.g. net revenue or total number of transactions) for the whole company didn't work, because most individuals couldn't link their direct day-to-day work to that one metric. Being unable to see how your work is impacting the company's results isn't exactly motivating. OKRs, on the other hand, gave everyone 4-5 objectives with 4-5 key results in each objective to play with and the immediate reaction was putting "actions" there (build feature X, close N partners, spend Y$ on marketing to get Z new customers, etc.). We quickly learned that this approach led to a lot of abandoned / half-finished projects and emphasis on activity rather than outcome. Everyone could now say that they achieved a bunch of actions as per their OKRs set at the beginning of the quarter. However, whether these actions led to any desirable outcome wasn't at all clear. Typically it didn't, but hey, at least we've carried out the actions we planned, so it's OK? It's obviously not OK, and as a result we ended up with an overall lack of focus and lots of time wasted on things which didn't matter. Clearly, that wasn't what we wanted to achieve. Even though it was better than a singular company KPI, and people now had a better idea of what they were supposed to be doing it still wasn't clear why they were doing it. Going for "actions" is also very susceptible to top-down planning forces, where a manager assigns a list of tasks to an employee without an opportunity for them to have a say in what should be done instead. So the following quarter we tried to focus on outcomes rather than actions or features. It was then the responsibility of each individual to sit down with their manager and figure out what actions should be done to reach a given outcome. Note that the "KR" in OKR stands for "key result" not "key action". This approach turned out to work much better, because it stressed the importance of achieving a certain objective, rather than spending time carrying out activities. At the same time it gave individual employees space to come up with that action list themselves and ultimately they are in the best position to know what needs doing. It was a big improvement over our first iteration, but the resulting objectives still ended up being a rather disjointed set of statements. They could have benefited from a more coherent direction and overarching strategy behind them. Quite a few of them still felt very activity centric, in other words, formulated so that only a particular activity would suffice. Another problem we had with action-driven or outcome driven OKRs was that all these outcomes were company-focused. For example we'd want to improve gross revenue of the business or make sure that we work with a large number of event partners and so on. While not bad outcomes on their own they really do not guide employees and managers around their day to day efforts (what is the marketing team supposed to do in order to grow gross revenue? Does that play well with what sales team is going to do? When they have a discussion and try to coordinate their actions - how do they choose what to do?). To address all these challenges we decided to step back and go back to basics. Whichever way we looked at it was always our customers who were rewarding us with their business, so our best bet is to solve their problems as well as we can. So we simply focused on solving our customers' problems. That completes the whole circle and helps us set our OKRs:
  • We think that our customer has a problem. We name that problem. (example: "Discovering and booking events on mobile is a pain").
  • We figure out what the outcome needs to be to make us believe that this problem is solved. (example: “Our customer is going out N times a month, they should use our mobile app at least M times a month to help them go out").
  • We list the actions we think will address that problem. (example: "Have all venues and events in the city on the app, make sure customer doesn't need to check other sources of information about the events in app, all events in the app are bookable, etc.").
We then work on these actions in an agile way by raising hypotheses, testing them and iterating quickly. Steve Blank describes this process in more detail here, but in a nutshell it boils down to picking hypotheses (or, plainly speaking, guesses) which help to validate our vision, crafting experiments to figure out if our guesses are valid or not, running those experiments and gaining new insights. For example we looked at validating whether customers of other lifestyle companies would be interested in booking events via YPlan. We wanted to experiment with partners linking back to our events from their websites or emails and see whether anyone would click on them. Instead of building complicated IFRAME / JS affiliate integrations we opted out for a simple image with a link which allowed us to check overall click rates and save tons of development time while validating demand for the feature. So now "objectives" in our OKRs are focused on customer problems and "key results" are focused on outcomes, measuring how well we've solved a given problem. Focusing on customer problems helps us clarify our thinking and helps us focus on what really matters. It also quickly shows us which of the outcomes are important and which aren't. Knowing what customer problems we're solving has helped us focus our teams too. Mentally connecting your day-to-day work to a customer problem you're solving is very easy (especially in YPlan's case where every single employee is also a customer) and helps to keep everyone motivated. Hopefully this approach will help you too in your next OKR planning session!