#47 Strategizing Success: Mastering OKRs with Jeff Gothelf
33:26 Share

user experience designers, UX designers are particularly well suited for the OKR conversation because we focus on the customer, we focus on the user, we focus on the human in the process that we're building. OKRs ideally are set at the beginning of an initiative.

before we start to build anything, before we decide to build anything. Basically, what we've done is we've identified... Hello friends and welcome back to the Future of UX podcast. I am Patricia Reiners, your host, and today we have a super interesting guest with us. Many of you might recognize him from his influential book Lean UX. It's Jeff Gotthof.

I read Lean Your Axe many years ago and this is definitely one of the books where I got back to many times throughout the last years. So I'm especially happy to have Jeff in the podcast today.

So Jeff has written a lot of books since then on various UX and strategic topics. And currently he's imparting with vast knowledge through workshops, consultancy work for clients and also sharing a lot of valuable insights in his newsletter and on LinkedIn. And in today's episode, we will dive deep into the concept of OKRs, objectives and key results.

Because I think the more designers can position themselves strategically by understanding the goals and also things like the key performance indicator of products, the brighter their future prospects become. OKRs are just one method to do that. And OKRs are pivotal in defining success for a product right from the beginning.

So together with Jeff, we will explore what OKRs are, the anatomy of the effective OKR statement, its metrics, and why there's a pressing need to revolutionize how we set goal and gosh success. Jeff shares many captivating insights in this interview, so make yourself comfortable and enjoy this enlightening episode packed with insights.

Hey, so hi, Jeff. So happy that you're here. Welcome. Hi, Patricia. It's nice to be here. Thanks so much for having me. Super excited to talk to you today. And before we are diving into the amazing topic of OKRs, I would like you to introduce yourself, tell us a little bit about yourself, your background and what you're doing.

Well, so my background is UX design. I started off as a web designer in the Web 1.0 days, and I worked into more of my way into information architecture, interaction design, user experience design, team leadership, product management, entrepreneurship, and now solopreneurship. So a variety of roles over the last 20 years or so with...

you know, a heavy, heavy focus on building products that customers love and building teams and cultures that, you know,

enable us to build products that customers love. And that's focused these days on training, speaking, writing, and coaching teams on ideas like Lean UX, product management, objectives and key results, product discovery, and organizational design and agility or organizational agility through design, which is an interesting way to think about it.

Because I think a lot of organizations are set up in a certain way and you try to introduce them to a new way of working, and then they're not designed to work that way. So I help them kind of think through how to redesign their organizations. And I've written a few books over the years. Probably the most successful has been Lean UX. Now it's in its third edition. I've co-written a book called Sense and Respond.

lean agile design thinking and then a book called forever employable which is about staying employed forever and uh and then most recently josh side and i are working together again on our third book together um about objectives and key results and that's that's kind of what i saw i work with large clients primarily um with those types of trainings and and speeches and and coaching

Wow, very impressive. I mean, I'm following you for a long time on LinkedIn. I read your book like this one a couple of years ago. So it's a good one. It's a really good one. Like I'm thinking back of it like several times. So it's something that I come back to from time to time. It's definitely a great book.

But now I am really excited to hear a little bit more about the topic of OKRs. I mean, you mentioned you're writing a book about that currently. So for everyone who is not familiar with OKRs, can you give us a brief overview of what OKRs are and why they are important for designers? Yeah, the concept is super simple.

And it's interesting because it's deceptively simple. I'll explain the concept and then we can talk about why it's difficult or complicated at least to implement it. But at its basic level, objectives and key results is a goal setting framework for teams. It's an alignment tool for the teams to understand why they're working on something and what success looks like.

And the fundamental difference in OKRs versus traditional goal setting is the objective is a qualitative statement that we aspire to achieve, become the best, the easiest, the simplest, the most reliable system that does X in the world, right?

And then the key results that are the measures that tell us whether or not we've achieved that qualitative goal, the quantitative measures. The thing that makes this

unique, and interesting, and then ultimately difficult for organizations is that your key results must be outcomes. They must be measures of human behavior. That's how we know we've delivered value. That's how we know we've achieved something worthwhile is when we see the people who consume the thing that we make change their behavior in a positive way.

So that's fundamentally all it is. The objective is a qualitative statement that says we aspire to become the simplest way to buy furniture

on mobile devices in Europe by the end of the year. And then our key results are the quantitative measures of human behavior that tell us that we've done that. So we're gonna see a 90% increase in customer acquisition in Europe. We're going to see a 15% increase in average order value.

and we're going to see an 80% reduction in checkout process abandonment in the next year, something like that. But those are the measures of success. And then you'll notice, so that's it. That's the framework. And why this is different is you'll notice that in neither the objective nor the key result did I talk about what we're going to build or what we're going to make. That's the variable in objectives and key results.

Overwhelmingly, certainly all the companies that I work with without fail, I don't like to speak in absolutes, but I don't think there's one company that doesn't work this way. Overwhelmingly, the companies that we work for and the companies that we work with measure success as the delivery of a product or a feature or a service or a campaign, whatever it is. And then they celebrate.

You know, let's have a party. We shipped it. But then the questions come up. Did anybody look for it? Did anybody find it? Did anybody try it? Did anybody try it more than once? Is anybody paying for it? Are they using it consistently? Are they telling their friends? Are they renewing their subscriptions, right? Are they buying more? Like those questions come up too late in the process. OKRs bring those questions to the beginning and then allow the team to

to discover the best way to achieve those behavior changes. Okay. So when you think about the process of creating these OKRs or coming up with the right OKRs, help us a little bit to understand the process. So when you are in design team, you're starting a new project, you have a certain problem that you want to solve with a product that you're building. At which point would OKR come into the game?

So I think, look, I think user experience designers, UX designers are particularly well suited for the OKR conversation because we focus on the customer, we focus on the user, we focus on the human in the process that we're building. OKRs ideally are set at the beginning of an initiative.

Before we start to build anything, before we decide to build anything, basically what we've done is we've identified a problem that we'd like to solve in the market or an opportunity that we would like to take advantage of in the market. And then once we've identified and agreed that this is a problem worth pursuing,

We can then set goals using OKRs that tell us if we've solved the problem or if we've taken good advantage of the opportunity that we found. And so this comes in right at the beginning. Instead of saying, hey, we're going to build a mobile app that allows us to sell furniture.

Right. We're going to say, wow, it seems like every single furniture, online furniture buying experience is heavily focused on the desktop. And we know that the majority of folks really like to use their mobile devices for pretty much everything. So we believe that there's a real opportunity to solve for shopping for furniture on a mobile device. Right. That's the opportunity or the problem statement that we've identified.

And then, okay, great. Now let's set goals for that. What's our objective? Our objective is to create the simplest way to buy furniture online on a mobile device. And the words that you use there make a difference in how you design and build the system. I use the word simplest, which is a qualitative word, but it will determine many design decisions.

I could have said the most engaging way to buy furniture online. That's a different qualitative word that drives different design decisions. And so I think for this reason, it makes a lot of sense for UX designers to be involved in this process.

both on the qualitative objective side of things and on the quantitative sides. You could say, right, a UX designer could relatively easily, I hope, say, right, okay, we've agreed as a team that we want to build the most engaging way to buy furniture online on a mobile device, okay? What are some behavior changes that would tell us that we've achieved that? Well, if it's most engaging, right,

I think I want to see people spend a lot of time in the app, right? I want to see them look at lots of furniture. I want to see them, you know, imagine what this furniture looks like in their house, right? I want to, so time spent in the app, I want to see it go up. That would be a good indication that we've built the most engaging app. Think about it the other way, right? If we decide that we want to build the simplest way to buy furniture on a mobile device,

Maybe I want time in the app to actually go down. If it's the simplest way to do it, in and out. I want that chair, that table, those curtains, and that bed, let's go. That's a fundamentally different experience. And so this is why I think UX designers fit really well into this process, particularly in help in defining it upfront.

What would you say who is responsible for OKR writing at the moment or in most teams, product teams, who's actually writing those OKRs at the moment? Generally speaking, I think there are two different roles that are writing it. One, if you're lucky, your product manager is writing them on the team.

And I say that because your product manager is on your team and is close to the work. And so they will take on realistic goals. They will take on realistic metric targets for you. And they know a lot about your work. If you're less lucky, then it's some executive two or three layers above you who has determined that your department is responsible for these OKRs.

And then you've got to come back and tell them, yes, this is realistic. No, this isn't realistic. Here's how we're doing. Here's how we're not doing. So those traditionally, those are the two people I've seen do it so far. It's either your product manager or some executive that's top down telling you what to do.

What would be the ideal scenario of coming up with these OKRs? Would this be like a team setup, a workshop or just like your ex-designers coming up with an idea and then talking it through with their product managers? Or what would you recommend?

Yeah, I mean, look, you've read Lean UX. And so the answer is the same answer that's in Lean UX and has been there forever. A cross-functional collaborative effort is the best way to do this, right? Now, look, I know teams can get big and I know that there's a lot of roles. If we're boiling it down, then we're looking at a representative from product design and engineering at the very least.

One from each, working together to determine goals and then commit to those goals. Because the team, these aren't design goals. These aren't product goals. These aren't engineering goals. These are team goals. So we win or lose together. And so there has to be input from every discipline.

And so ideally, some cross-functional collaborative team going through this process together is the ideal scenario. I mean, that makes total sense. And for me, what would you recommend or like,

What would you say makes it easy for the team to also stick to those objectives that you set in the very beginning? Because what I realized working with different teams, you come up with some goals in the beginning, some objective, maybe some key results, and then

work gets in the way, other problems get in the way, you get distracted. So I think a big challenge is also to really sticking to those rules that you said in the beginning. How do you do that in the best way? Do we have any tips maybe? I mean, look, discipline is the answer. But look, the discipline is...

is key in that somebody on the team and look, traditionally, that's going to be the product manager needs to consistently remind the team what the goals are, how we're trending towards those goals, and then use those goals as a filter for determining what we're going to work on next. And for

prioritizing and deprioritizing new inbound work. So for example, let's say everything's working perfectly.

Okay, you're working in the most ideal situation cross functional collaboration customer centricity, you're solving problems you're not implementing solutions. You've got your OKRs in place, you start to work towards your key result goals. And then as you're working towards them, you discover some new opportunities.

right? Some new problem spaces that you didn't know were around before. And you come back to the team and you say, "Wow, we could also do this." And so then the product manager or the team has to be disciplined enough to say, "Okay, great. Our current key result goals are to change these behaviors. How does this new discovery help us achieve that?" Right? And if you can't make a compelling case for that, then it's a not now, right?

That's the key, right? Great discovery. We'll keep it in the backlog, but we're not doing that right now because our goal is to change this behavior right now. So that's a really nice use of the discipline there. The other thing that happens in less ideal situations is somebody, sometimes it's on the team. Usually it's some executive from outside the team that says, you know, what would be great is if you folks could build this as well. And you can say, okay, boss,

Great idea. Our current goals are to increase customer acquisition by 15%. How does your idea help us achieve that? Well, it does or it does or it doesn't. The point is you can have an objective conversation that isn't, no, we're not doing this, right? Or, okay, we'll do it. But it's more like, if you think this is something that'll help us achieve our goals, terrific. Let's talk about it now. If not, we're not going to talk about it now. It's not a no, right?

It's a not now. And then if we decide that this potentially has the capacity to help our key result goals, then we have to start to figure out how to prioritize this stuff against everything else that we're doing. Because you can't just add it to the backlog and hope that we can get it done. You can't just keep stuffing work into a backlog. That's not the point of it.

Makes total sense. I mean, what would you say? I mean, I think like communication over all is like super important. You just mentioned it, talking things through, making sure that it's aligned to the goals that you said in the very beginning.

What would you say or what would you recommend to especially your UX designers who would like to work with OKRs? I mean, it's a very important strategy also to make sure that business and user goals are aligned and that you create an amazing product in the end. So what would you recommend UX designers especially would like to work with OKRs who have no experience with it,

but want to use it, maybe want to become a part of creating these OKRs in the beginning, how would they proceed to become a part of this process of setting the goals in the beginning? So it's a question of inclusion, right? And I think if they're not included in the process, right? And let's be honest, UX designers are rarely included at the beginning of the process.

then when the work gets to you or when you finally become aware of the work, then essentially the conversation that you want to have with your product managers and your engineers or whoever's making these decisions is why? Why are we working on this? Now, look, the reality is that asking why in certain organizations, in certain contexts can be a career limiting move.

right and and and so we want to be sensitive to that and we want to be realistic about that instead of so instead of just sitting there and kind of folding your arms and saying why are we working on this right that's yeah always a bad idea um instead really thinking through um a different line of questioning so not challenging but saying great i love this idea i can't wait to build it um

When we build it and we succeed, what do we expect our users to be doing differently than what they're doing today? What you're saying there is you're not saying no, which is important, but you're asking a clarifying question that says, look, there's an infinite number of ways to implement this, to design this. How do we know that we've got the right one? What do we want to see people doing differently? And what you're starting to do is you're starting to shift that conversation into

towards outcomes, towards human behavior, towards key results. So we're starting to nudge that conversation forward. And I think that if you can successfully get that conversation to happen regularly about your work, then maybe after a couple of projects, products, sprints, whatever it is, you can bring that conversation up at the beginning of the next cycle.

Right. Hey, you folks remember the last couple of cycles, I kept asking what people be doing differently we agreed on a on a behavior change we didn't quite hit it.

why don't we set that up at the beginning here and then decide what we're going to do based on that. Oh, right. That's so you're kind of, you're kind of doing that. So if you, if you're not directly included in the conversation, that's a nice way to steer it back that way. And even if you are included at the beginning of a conversation, that's a good question, right? Cause everybody's going to think about features, right? Every, everybody's going to focus on what we're building your job.

is to bring the conversation to how are we making people's lives better or more successful or whatever the goal is. And so always what will people be doing differently when we succeed is a really nice question to kind of take folks on that journey with you.

Love that. Yeah, that makes total sense, right? It's all about the communication and how you actually address the concerns that you are having in a way that you are not a blocker, but actually support the team with your knowledge and still keep the user in mind. Make sure that it's not moving track towards business goals too much. Super important.

So in the beginning, you already mentioned that you are currently writing a book about OKRs. Tell us a little about the book. What can we expect from the book? What will be in there? What insights and who are you actually targeting with the book? So for who is it interesting? Yep. So I'm co-writing the book with Josh Seiden, who I co-wrote Lean UX with and Sense and Respond.

And the book is called Who Does What by How Much, which is the way that we teach OKRs. So when we work with a team, as they start to think about the behavior changes and to set the goals, that's our prompt to them. Who does what by how much, right? Existing customers, you know, add one more product to their cart every third visit, right?

Something like that. Whatever it is, right? But like, who does what by how much is the name of the book. It is designed to be a practical, tactical implementation guide to OKRs across the organization. So it's not a book necessarily for tech teams or product teams or design teams. It is for those people as well, but it's not exclusively for those people.

It's for the entire organization. So if you work in product of any kind, this book's for you. If you work in HR, legal, finance, marketing, et cetera, this book is also for you because I believe that we believe that everybody who makes something has a customer, right? So if you go to work and you make a thing, it's easy for us in our work to say, well, I made a prototype, right?

Or I made a design or, you know, I made a content strategy or something along those lines. But if you work in HR, for example, you're like, I don't make anything, right? It's not true at all. You make lots of stuff. You make a vacation policy.

right? You make job descriptions. You make decisions about my professional development as an employee in the company, right? Those are all outputs. Those are things that you're making. And so everyone has a customer that consumes what they're making. This is a key point in the book. Everyone has a customer. So again, for us, as UX designers, for example, your customer could be the end user,

Your customer could also be the engineering team that has to implement your designs. And so what are you making for them to make their lives better? If you're in HR and you're making vacation policy, then your customers are the staff.

of the company so that's a key point that we make in the book and then we're trying to get people to move away from this mindset of this kind of you know manufacturing mindset that says well I made a thing right isn't that awesome I made the thing there it is right and then and and move them towards well how did that thing change your customers Behavior

Right. The example I use all the time is there's been a trend for years in the United States from companies where they implement an unlimited vacation policy. Sounds amazing, doesn't it? Right. Unlimited vacation, which in America, by the way, is significant because most folks, you know, get two weeks, three weeks vacation, four weeks is a lot. You're lucky to have very lucky to have four weeks paid vacation.

Unlimited sounds incredible. Who wouldn't want to work at a place with unlimited vacations? Why even go to work? Right? Here's the fascinating thing that happens with unlimited vacation policies in the United States. People take less vacation. Wow. Isn't that interesting? Yeah. Because it's infinite. There's no scarcity.

Traditionally, with vacation policies in the United States at least, you get two weeks or three weeks. And if you don't use them in a calendar year, they're gone. They're gone, yeah. So there's a scarcity model there. And so, crap, I got to use my vacation days or they're gone. With unlimited, that FOMO, that scarcity fear of missing out,

doesn't exist. And so people actually end up taking less vacation in the United States. And that becomes an interesting question for the organization. Is that the behavior you want to see in your customers or not? Your customers being the staff, right? And so the book talks about OKRs in those contexts, product, tech, manufacturing products, HR, legal finance, just to make it obvious that

There's a new way to think about setting goals and determining the success of your work, no matter what you do. And it's very practical. It's very tactical. It's how to create OKRs and think about them in various contexts. What happens after you set OKRs, scaling OKRs, helping managers think about how their jobs change when you're using OKRs as the goal setting framework. So it's a very, very thorough book, I think. Nice. Yeah.

Sounds amazing. So do you already know when it will be published or when it will be available to purchase? Well, as these things go, so we're self-publishing, right? And, you know, there's the benefit to self-publishing is that you can do whatever you want and you're not beholden to anyone. You're not beholden to anyone's deadline, right? That's the beautiful part.

The negative part of self-publishing is that you can do what you want and you're not beholden to anyone for a deadline. Yeah, that's true. So you can just go forever and we're not going to do that. We had aspirations to get the book finished this year. In fact, in a month, that was the goal. That is not going to happen. We've simply been too busy writing.

this fall to give it the time and attention that it needed to get it there. So the plan now is late Q1 of next year. So if I was guessing, I would say early March at this point, just given the holidays and everything else that we've got planned. I'm saying early March is the target. And I don't think we're going to miss that. Nice. Okay. Good to know. So if the listeners, if you hear it,

After March I will link the link to the book shop or where you are going to have that available in the description box so you can check it out. If not then check out Jeff's I would say like newsletter stories or a post on LinkedIn and then you definitely won't miss the book if that's interesting to you.

100%. Yeah, I mean, it sounds super interesting, especially for designers to dive deeper into the topics of OKRs, but also like all the business relevant information that are super important for your ex designers to also be taken more seriously and to be sure that you're actually developing a great product in the end. Get not only users, but also like business loves.

Do you have any other tips, recommendations or resources that you would like to share with the listeners for UX designers who become better designers? I'm trying to think. It's interesting. My daughter is studying UX design these days. Nice. I'm very excited. Yes, she's entering the family business. And so I think about this stuff a lot for her.

I have to find a link for this, but I saw a really interesting collection of templates from Vitaly Friedman, the smashing... Oh, he's amazing. Yeah, he's amazing. And I

I don't have the link for it. I'm sorry, but I'll find it. But he's been posting a series of very practical, tactical resources on LinkedIn where it's like, here's a guide for better search design. Here's a guide for writing hypotheses. Here's a guide for thinking about assumptions testing. So I'm really, really pleased with what I'm seeing coming from him. I think he's a great resource for this kind of stuff. I also had him in the podcast some time ago. Oh, great. But yeah, he's amazing. Yeah, definitely follow him.

Vitaly on LinkedIn. He's great. Perfect. Like amazing resources always. Yeah. Great. Good tip. And also, I mean, you haven't mentioned that, but I would also recommend to follow you on LinkedIn. You're sharing great insights there. Great posts. The newsletter is always very interesting. Definitely a treasure trove of infos. So check it out. I will link your LinkedIn and any other social networks that you would like to link in the description box so people can

Find you, follow you, see what you are up to and also learn from all the insights that you're sharing. Terrific. Thank you so much, Patricia. Thank you, Jeff. It was so amazing having you in the podcast and talking with you about OKRs. Thank you so much for your time. My pleasure. Thank you. Thank you.