Pragmatic OKRs - How to Focus on Context, Not Correctness.key

Hi everyone.

I'm excited to talk about pragmatic OKRs today.

Now, what I mean when I say pragmatic okrs in detail.

I'm excited to talk about the idea how you and I and the rest of the world can shift the way they approach okrs from a focus on correctness to context and to value in that context.

And to do that, we're going to take a closer look at some of the common beliefs and common practices in OKRs and how a little sprinkle of pragmatism might be very helpful for making the okrs more useful in your context and the people you're working with now to set the stage.

I would like you to think if you can resonate with that sentiment.

I certainly know I can.

Back from my days when I was an in house product manager or head of product before I transitioned to working as a product management coach, I certainly had this feeling that I wasn't really sure if I was excited about the OKRs and getting to work or if I just really was just really, really happy that the whole planning charade was over.

I was able to get out of these meetings.

And I think that's a shame.

I think it's a shame that teams might be more repelled or feel more repelled about OKRs based on the process heaviness and the sense of correctness and that it sometimes can feel like homework compared to the very, I think very, very helpful tool that it can be.

And what I think is oftentimes missing for people is this simple but not always easy to answer question of why do we even use okrs?

And a helpful practice that I found over the years that I've adopted myself and that I've also recommend to the companies that I work with, whether it's a small, medium business company or large scale enterprise, is to really think about if your okr practice were a product, what kind of problem would it solve?

And I find that very often this reveals what the company actually wants to do.

And making this explicit has so many downstream consequences on, the way okrs should actually be used.

And it changes everything on how the practice and the reasons behind OKRs get communicated to the people who do the work.

And so your company might find their own definition of, of what problem okrs should solve for them.

But for the sake of this talk, we're gonna stick with this definition that I find very appealing, which is that okrs in essence really have to help product teams to measure their progress towards strategic priorities and ideally by responding to everyday decisions so we use the okrs as our product, just like, we would do for our product.

We define a target audience for this product, which is in this case, product teams or any other team in your company who you want okrs to use.

The problem we're trying to solve for this audience through our product is to help them measure their progress.

I think if you strip away all the fluff, all the framework or the baggage around okrs, I think that's what very often it should come down to.

And everything you do about okrs should be in service of solving that problem.

Now, just like when we build a product, we should also be able to reflect on, well, does our product actually solve this problem?

How would we know?

And I think an interesting idea to utilize to think about, well, does my product solve this problem?

Could be in the terms of measuring success through the degree to which the teams who do the work can link their backlog items or their discovery activities to those strategic measures of success.

So our success metric is actually the degree to which the metric, the okrs we set helps teams prioritize their work and select what to work on and whatnot.

Now, this is a seemingly simple practice, but believe me, depending on the number of stakeholders and the years of potentially failed OKR attempts, it might not be an easy exercise.

But I can tell you that it's very revealing.

And again, there's so many downstream consequences in there, because when you now talk about the way you want to use okrs, and I don't believe there's one right way to use okrs, you have something to refer back to.

You have this definition, this reason why, that you defined why you want to use okrs and can design your OKR system, your practices accordingly.

And if we take this definition as a starting point, the way you use okrs might differ a bit and it might look like this and it might, have these operational consequences.

So when we say okrs have to help product teams, I think it definitely means that teams should write their own okrs.

Again, sounds so obvious, but for many companies that's not the case.

Because if we want to solve a problem for a target audience, it means they should be involved.

I think it also means that for those teams who want to write their OKRs, it is their responsibility to have the inputs ready, to have the product strategy in place, the product vision, the product roadmap, to have all these things in place to make sure that they can focus on the actual drafting and don't have to spend enough time on discussing all the narrative and Everything around it.

If we look at the core problem we're trying to solve, that we want to measure the progress towards our strategic priorities.

It also has some tactical implications on the way we use okrs.

For example, it means that the team should really avoid generic evergreen metrics.

We're going to talk about this a little bit more later on in the talk because you can't really know if you're making progress towards strategic priorities if all you're tracking is the degree of completion of the latest ARR goal in your company.

You don't want a metric that you could plug into every other quarter or cycle and no one would notice the difference.

You want something specific, something that expresses what you will do differently in the next cycle.

Measuring progress towards strategic priorities also means that you shouldn't set moonshot okrs just to never reach 100%.

It's one of those very common beliefs out there that OKRs are only ambitious enough if the teams can never really reach 100%.

And I can tell you that many smart people in companies who get sort of like put into this trap, they just game the system.

They just lowball their okrs to make sure that they actually can achieve them.

They don't want to feel overstretched, they don't want to feel tricked by metrics they cannot achieve at all.

Of course your okr should be ambitious, and that's kind of the point.

But don't make them too unrealistic and let people chase something they cannot reach at all.

What's the point of that?

What kind of people do we want to work with?

So we want specific metrics.

We want people to actually achieve them while keeping them ambitious.

And that also means that some cases require that you might prioritize leading output metrics over lagging outcomes.

I know we all love the idea of outcomes over output, and there's so much value in that.

So much value that, empowers team to think beyond solutions and to actually focus on the work they should be doing and what they should be achieving.

But let me ask you this.

How beneficial is it for a team to have an outcome OKR that doesn't really change fast enough and that they can't really influence, but it is still an outcome.

So they keep looking at this metric, but they never track any kind of progress.

How helpful is that for measuring their progress towards priorities?

I don't think it is very, very helpful here.

In some cases, maybe everything this team can only think this team can measure right now are outputs.

And maybe that is okay to help them measure their progress.

That's the sprinkle of pragmatism I talked about.

We don't want to say outcomes over outputs at all cost.

We still want to be context aware of what type of goal makes sense to people.

And if we look at this last portion of when we define okrs as a product, then when we want to achieve that teams can link backlog items and discovery activities to their measures of success, it has practical implications like okrs actually being visible in decision making moments.

Maybe you don't need a whole list of new okr, specific meetings.

Maybe you rather need to think about what kind of existing decision making moments and meetings and routines do I already have and rather think about how you can bring okrs into those compared to creating a parallel universe of OKR priorities and non okr priorities.

It might also mean that you have to figure out how you can get rid of non related okr tasks as much as possible.

That doesn't mean that okrs have to cover everything you do.

I think that's another anti pattern of useful OKR usage.

You don't want to make sure that you try to anticipate every edge case in your okrs, but you also want to make sure that for those strategic measures of success that you want to measure and work towards, that you have enough capacity and that you set your okrs accordingly.

You can dedicate enough time to that.

And it also means that your okr, progress should be revisited more than once a quarter.

You shouldn't just set the okrs at the beginning of the quarter, do a bunch of stuff and then at the end of the quarter check in on it and realize, I guess I missed my okrs happens.

You want to be able to measure things along the way.

Now all of these might sound very, very obvious and honestly they are.

They are pretty obvious.

But what is missing for many people is to link these seemingly obvious measures to why they want to use okrs, what kind of problem they're trying to solve, and to also continuously reflect on that system and their practice and adjust it accordingly.

Because when we talk about pragmatism, it is important to acknowledge that not every type of goal is equally important at every stage of your company.

I love this differentiation from Ravi Mehta to say whatever type of risk your team faces right now, that has to be represented in your goals.

If you have a big understanding risk, well then your goals should be around discovery practices.

If the biggest risk is so much more of a strategic nature in terms of whether companies or customers might actually adopt the solution then?

Well, yeah, an outcome goal is probably a pretty good reflection of tackling that risk and reducing it and inputs and outputs in between.

So don't fall for the trap to only think that only outcome goals are the right way to go here.

Make sure to figure out what is the biggest risk your team is facing and if that is your biggest strategic priority.

Whatever type of risk you're facing, design the goals accordingly and how you use those goals and how you set up your OKR systems.

Because the thing that people have to remember is that, well, an outcome OKR itself is a pretty solid thing to work with, right?

But you are not a better product manager just because you've write an outcome okr.

We just talked about it.

You have to be able to actually work with it.

just writing it once doesn't make sense.

You are a better product manager though, if you manage to prioritize the work of yourself and your team, maybe your department in a way, so that it moves business and user success metrics, which is what our OKRs should express.

Whatever type of nature these goals are, it doesn't really matter because OKRs are not a means, not an end in itself.

They're the means to a larger end.

And this end is to actually focus and prioritize your work.

Because the problem is if you focus a bit too much on just getting the right OKR in place and writing an outcome goal, you can easily fall for something that I like to call alibi progress.

And as I explained in the beginning of the talk, it's not.

So that's really a pattern of putting the correctness of the practice over the actual value it's supposed to provide.

And the bridge I want to help you build and which is something that is pretty close to my heart, and I want to encourage, more people to think about is how you can shift from alibi progress to something that I like to call real progress, where you prioritize the value of your work over the technical correctness.

Because after all, no one really cares if you've done something by the book.

Neither the authors who wrote the book nor your customers, they care about the value you provide.

And I think the practices and ways of working should be held to the same standard.

Now, one of the most powerful ways that I think that helps people to take this leap from alibi progress to real progress is not necessarily to look at more frameworks, more methodologies.

What I really love instead is this thinking from James Clear, who says that advice is context dependent, but Questions are adaptable.

So when I thought about more, how to build this bridge for people, how to help more people move from element progress to real progress, which is what I did in my book called Real Progress as well, is what kind of questions do I need to give to people?

And one of the ways I landed on that to raise these questions is to connect adjacent practices and the most common struggles within these practices.

And something that I like to call the progress wheel.

And these three domains, OKR strategy, discovery, are really like, they're my wheelhouse.

That's what I'm talking about.

That's what I work on with most of my clients.

And these are the product topics I care the most these days.

And you can see that in each of these domains there are some of the most common questions people might be facing.

And I believe that very, very often the answers to these questions don't lie in trying to write okrs harder or to strategize more.

I think very often, it might make sense to focus on connecting the dots and using reflective diagnostic questions to figure out where the actual struggle is.

You might struggle with executing your strategy because you have not articulated it into proper success metrics.

You might feel that the okrs you're writing are very generic and evergreenish.

That doesn't mean you suck at writing okrs.

It might simply mean that you lack the strategic specificity.

If you feel that you're writing outcome okrs, but you really have no idea if these outcomes exist, if they represent real customer problems.

Well, that is more of a discovery issue because that might mean that you simply lack a depth of customer problem understanding.

So everyone I've shown this reel to is like, yeah, it's interesting.

I could start to, you know, stop focusing a bit too much, too hard on this one domain and really use those reflective questions.

And this idea of, the reflective questions, the diagnostic question, resonated so much with people that also made it one of the cornerstones of my book.

And I'm going to share a few of those questions with you later in the talk.

That might help you to spot some of the gaps in your practices and how to move on from them.

Because beyond specific frameworks, I also believe in trying to improve OKRs as one example, not necessarily, as I said, through more rules, through more, through more rigid guidance.

Instead, I think that people, when they say okrs don't work for us, they should focus on diagnosing the actual problem.

What does that mean?

Why aren't, the okrs useful to people, which I have no Doubt is the case in some companies.

And through my work and over the years of using okrs, I landed on these four attributes that I think really represent the core root causes.

Why OKRs might not be useful in different contexts.

One is OKRs are simply not influenceable for the team that works on them.

Another one is that the okrs might simply not be evidence informed.

talking about those guesstimated outcomes I just mentioned.

It also means that the OKRs might not be strategic, might be more evergreenish than just repurposed KPIs.

And it might also mean that the OKRs are simply not leading enough.

This idea I just shared, that you can only review your okrs at the end of the quarter or the cycle.

And so for the second half of this talk, I want to dive a bit deeper into two of those attributes in detail to shine a light on what I mean the struggle is here.

And to also share some of those diagnostic questions I mentioned earlier, which hopefully also help you to figure out which of these attributes might not be fully aligned.

Because let's be clear, this is not about a checklist.

Just because you tick the boxes of these four attributes doesn't mean your chiaras will be automatically perfect.

And I will, I will send you a personal thank you letter, even though I want to send you a thank you letter.

it's more about recognizing what might not be aligned, as I said, and then taking the actions and implementing the practices that helps you fix this attribute.

Maybe it's just one attribute, maybe it's more of them, maybe it's all of them.

I don't know.

that's what I think the beauty of contextual diagnostic questions is.

So the first attribute I want to take a closer look at is the idea of influenceable okrs.

And for that I love to, in general, I love to turn to approaches and ways of thinking that have been around for quite a while, which I just neglected.

And one of them is the idea of the sphere of influence, which has been around for, I think for decades even.

And I think the first, appearance in that, in that state is from William H.

Detmer and his book the Art of Logical Thinking.

And when you connect the sphere of influence idea to the different types of metrics and goals, like suddenly for many teams I get to meet and work with, like they have a light bulb moment.

Because as we talked about, I think the degree of usefulness of your chaos depends on how much you can influence them.

But in order to improve that, to recognize that you first need to understand what is your sphere of influence as a product team and what are the things you only contribute to your area of contribution and what are the things you can really control.

And of course it is never a black and white categorization here, it never is, it is lots of gray area.

It's a bit of a scale.

So it's more about what can you more or less influence.

But the core idea is that you really can only control your outputs and maybe your inputs, like the stuff you produce, the work, the amount, the resources you put into something, that's one you can't control.

You can influence customer behaviors, but you can only influence the customer behaviors.

And typically the things you're contributing to as an individual team are overarching business goals.

So if we look at that in the example of an average E commerce company from the team that might work on the checkout, for example, the overarching impact they contribute to is the overall conversion rate from homepage to purchase completion.

They shouldn't just break down the overall conversion rate of let's say plus 5% to just them contributing plus 2%.

They should think about what can I influence that is part of this overall conversion rate?

And they might land on how much time people spend on completing the fields in the checkout.

If they can reduce that, they might be able to improve the overall conversion rate.

And what they then can control in this context is for example the number of available payment methods they want to implement.

So with this understanding in mind, and this is always a fascinating translation exercise when I do it with companies and clients, is to map these different understandings of what management thinks a team can influence and on the other hand what the team thinks they can influence.

So if we take this further and I'm a big coffee nerd, I'm a big filter coffee nerd.

So I love to use examples from fictional coffee companies.

So let's take this e commerce company, but let's put it in the context of being a coffee roasting marketplace.

And so if you really align these different things of what the company wants to achieve, the company OKR might be improving the conversion rate.

But what the team has to do to get to an influenceable OKR is has to understand the intention the company has and reinterpret that intention and map it to its sphere of influence to find a goal, a metric they can use for their okrs that is influenceable and therefore more useful.

So you might start on both ends of the scale.

You have the company okrs which is the conversion rate.

And then you want to figure out, okay, what does the company actually want?

Basically, it's about figuring out what customers need so they can comfortably complete the purchase.

And the checkout team certainly plays a role in that.

And so when they think about what can they control and influence, well, they can be much more vocal or transparent about, the timing for roasting coffee that influences when it gets shipped.

They can also influence how they calculate and display and integrate the idea of how the shipping costs are affected by ordering from multiple roasters.

And by finding this overlap and doing this interpretation exercise, they might land on a metric like reducing the time spent to complete the address and payment details.

And they have some data at hand that they can use to make that easier and to make that faster for people by addressing some of the concerns of row state timing and calculating shipping costs.

So it's this core act of understanding the overarching company direction, intention, interpreting it and mapping it to your sphere of influence to find metrics that are much more useful for your work, which can actually help you measure the strategic progress I mentioned in the beginning, which should be at the core of the value OKR should provide for you.

So I mentioned this idea of diagnostic questions and quality checks.

And these are two quality checks that I like to use for helping teams reflect on their influence over OKRs.

One is, can the team really directly influence the metrics in the key results for the daily work?

If they can't, make sure to narrow the metrics further by understanding the sphere of influence and don't let the team get too much pulled into the area of contribution, this might also reveal the uncomfortable truth that the team's sphere of influence is extremely narrow, which might be more of an org chart issue than it is a team OKR issue.

And also making clear that when you find yourself in the situation of having to explain OKRs to stakeholders and you feel like you always have to justify things, it might be on you to point out the explicit connection of your influence with the metrics to the company goals you're contributing to.

Or if you find yourself having metrics, you don't have a narrative around how you influence it.

Maybe you chose an OKR that sits outside of your control, outside of your sphere of influence.

So hopefully these two quality questions, exemplary, give you a bit of an idea of how you can diagnose whether the degree of influence abilities might be one of the root causes OKR might not work for you.

The other attribute I want to take a closer look at is the Evidence informed okrs how evidence informed okrs are.

And the issue is that when you look at something like an outcome okr and I think Josh Seiden together with Jeff gotthelf through the work of the last years, whether it's in the book Outcomes over output or their recent okr book who does what by how much, they made a great point that an outcome really is about describing the change in human behavior.

Now you can perfectly write an outcome okr without having ever talked to a customer.

But how much higher could your chances of generating business success?

B if your QR would be rooted in a real customer problem or human problem and humans could be all sides of humans, this does.

This applies to B2C B2B B2B 2C internal teams.

Right.

So you have to be the degree to which you can be more clear on the human problem influences the quality of the outcome and thereby the outcome OKR you can define.

So when you're clear that people really hate juggling browser tabs just to compare, two phones side by side, well, maybe make it easier for them to compare products on mobile so they don't have to leave the catalog, which could be a specific outcome.

Or you don't really know how your shipping costs will be affected by putting more things through the basket while browsing.

Well, then the outcome you have to drive is to let people know the total shipping costs before entering the checkout page.

And again, you could write those outcomes on the right without knowing the customer problems, but they're probably a bit misguided.

Your KRS will be so much more meaningful if you can connect them to actual evidence generated for something like product discovery work, that the problem is real.

Returning to our coffee marketplace, here's how this will play out.

The company has the overarching okr we just talked about, like improving the purchase, the conversion rate.

And maybe you assume that, well, in order to improve the conversion rate, I think people need more variety, but you have no idea.

But this could lead to a key result like, okay, let's increase the checkout coffee recommendations.

People need more stuff, so we're just gonna throw more stuff at them in the checkout.

Or you could really try to understand the user problem, which might tell you, I don't really know how the fresh coffee beans would be, how fresh they would be, and they deliver things.

And so you could rather focus on, okay, I'm going to make sure the, roasting data is really visible and it's viewed and it's shown to people to address that problem which you know is real compared to that assumed user problem.

And here's why it's so important to connect the dots which what I showed you earlier with the progress wheel how discovery supports this evidence informed OKRs, because Discovery Insights reveal which behaviors really matter to people.

So instead of just assuming users want to add more items to the basket, you might want to figure out why they struggle with shopping more on mobile.

So for every proposed key result that you have, make sure you can name the specific discovery evidence that validates it so it addresses a user problem that is actually worth solving.

As a bonus to also share with you those quality checks for evidence informed OKRs to diagnose whether the the lack of evidence might be the reason your okrs feel a bit off.

One question is to think about can you name the specific user problem the key result addresses and do you have the evidence?

Can you name the evidence?

And evidence has so many different strengths, but can you name it?

Because if you're measuring behavior changes without validated problems, you're tracking company desires rather than user success, which is not really what we're trying to do here.

And the other question is, are your key results based on what users actually do or what they say they do, which is one of those core holy grail activities of discovery?

Do you really understand the behavioral question, behavioral data, or are you trying to just get lost in the anecdotal attitudes people report to you?

Now, to wrap this up, again, to get pragmatic value from OKRs, it's about diagnosing, asking questions rather than looking for rigid frameworks.

The next time you feel you're struggling with the OKRs, think about which of these four attributes could be misaligned that causes this lack of value.

Is it the degree of not being very influenceable?

Is it, that the OKRs are not really rooted in evidence?

Might it be that they're not very strategic?

Or, might it be that they are simply not as leading enough to provide continuous feedback to people?

And if you want more guidance on how to do that, I invite you to check out my book which is called Real how to Connect the Dots of Product Strategy, okrs and Discovery.

You will find much more ideas of how to introduce this healthy sense of pragmatism to OKRs and where things like strategy and discovery might be more helpful than trying to write okrs harder.

In the book you will also find access to resources like my useful okrs map, which helps you to navigate these attributes and collects all these different diagnostic questions and assessment possibilities in one place.

Make sure to check it out and feel free to reach out with any feedback you might have.

I, love hearing from people, how they enjoy the book and how it hopefully shapes their work.

Thank you so much.