Episode 156: OKRs for Focus and Alignment with Jeff Gothelf of Gothelf.co & Josh Seiden of Seiden Consulting
In this episode of Product thinking, Jeff Gothelf and Josh Seiden join Melissa Perri to talk about their exciting new book on OKRs (Objectives and Key Results). They tackle common mistakes made when implementing frameworks like Lean UX, and how OKRs can solve this. Plus they share all the insights they’ve learned over the last 10 years since their first book, Lean UX. Tune in to discover how OKRs improve your business, business unit, or team’s overall focus and alignment.
You’ll hear them talk about:
[09:52] - Organizations are continuously looking for ways to improve efficiently. Organizational agility should be at the forefront of businesses minds and OKRs is how to do it. Having your organization aligned around achieving specific goals changes the whole process of how companies work. It affects the management style, incentive structures, team motivations, and more. These make for a correctly customer centric operation and improve agility.
[15.54] - Changing tact and implementing new frameworks of working is hard. This isn’t just an issue faced with OKRs. A lot of businesses find this out. A new framework might give us the language we need to change and to plan change, that's the first step, but it doesn’t make the change. This is where many businesses stall. It’s easy to lose track of why you’re making the changes. It’s important to clarify why you want to use the framework rather than simply adopting them without clear reason.
[26:39] - OKRs are objective and key results. It’s important to be clear on these two elements. The first is qualitative, the reason to get out of bed and work for the business. For example, to make a product more efficient. It is the alignment statement and the overall objective. The key results have to be outcomes. Outcomes measured by the changes in human behavior. The aim is to see people change their behavior in a meaningful way for them, which also positively impacts the business.
[29.13] In some cases OKRs have been used for individuals in a business. OKRs are meant to be used for focus and alignment of the team at the organizational level. Individual OKRs as incentives create conflicting priorities. OKRs are scalable down the organization; they apply to your sphere of influence. A key note is to use them in setting objectives and key results for these areas of influence, as well as focusing on alignment.
[36:52] - Using OKRs isn’t limited to digital product management or software. In fact, it’s been used in healthcare, starting with the CEO’s sphere of influence: the organization. The goal is to be the best clinic to receive care. A change in human behavior, the KRs, is to reduce serious safety events or regrettable turnover. How this applies to other sectors is OKRs force people to rethink how they work and how to improve work as a team to ultimately influence the behavior of customers or users.
Episode Resources:
Other Resources:
Melissa - 00:00:01:Creating great products isn't just about product managers and their day-to-day interactions with developers. It's about how an organization supports products as a whole. The systems, the processes, and cultures in place that help companies deliver value to their customers. With the help of some boundary-pushing guests and inspiration from your most pressing product questions, we'll dive into this system from every angle and help you think like a great product leader. This is the Product Thinking Podcast. Here's your host, Melissa Perri.
Hello, and welcome to another episode of the Product Thinking Podcast. Today, we're talking about agile and OKRs. I'm very excited to say that we have two expert authors here. They're also coaches and public speakers, Jeff Gothelf and Josh Seiden. I met Jeff and Josh 10 years ago when we were all speaking at the Lean UX 2013 conference in New York City. And since then, I've been following their work very, very closely. And it's been amazing to see how it's evolved. They work with companies internationally to help leaders understand how to truly make their organizations agile and foster great collaboration between teams. Jeff and Josh are launching a new book on OKRs, and we're going to dive deep into that more on this podcast. But first,it's time for our Dear Melissa segment.
All right, this week's question. Dear Melissa, how do you use Product Cata or do product discovery for products which don't have users? For example, a pricing system or an inventory ordering system in e-commerce, or a rider matching algorithm in Uber?
All right, so Product Cata, for those of you who are not familiar, is something that I have developed based on Toyota Cata to help us lead product discovery and think through continuous improvement frameworks. So I teach this online in our classes at Product Institute. And the whole purpose of Cata, which was originated by Toyota Cata, is to help people learn and understand how to get towards outcomes, which works so nicely in product development.
So when you think about the kata, what we're really doing is step one, understand the vision and the goals that we want to get to. Step two, try to think through what the current state is or what's happening now. Step three, we then break down based on the current state where we think the problem is and set ourselves a smaller goal to get to that big goal. And then step four is we execute towards that goal.
We run an experiment or maybe we launch a product. Whatever it is, we put something out there, we try something, and then we get some feedback. We learn from that and then we keep iterating through this cycle. So then we typically would go back to the current state and say, are we any closer to our desired end goal or desired outcome? So when you think about the product kata and the way that I've described it in a blog post that's out there on the web is I do talk about us in the current state thinking about what our user is doing now. But it doesn't necessarily have to be users, what the users are doing. It could also be what the current state is of the framework or the product. So for example, if you are building an app, and you have this outcome that you want to achieve for the business based on this algorithm, you can actually just look at what the current state is of matching, let's say, riders and Uber today, right? And that would be what your current state is. So let's say that your outcome is to be able to match people to riders in Uber a lot closer than they are. I'm making this up on the fly, sorry. But let's say like we wanted to make it less than two minutes that anybody has to wait for a ride. Right now, what is the current state? The current state is that it takes over five minutes on average in certain cities for people to get rides because we're not matching them correctly. Okay, that's the current state, right? Right. So now that I know that, I can start to say, what do I have to do to try to make this better? And then you would want to go out there using the Prada Kata and go through what are the obstacles standing in my way of trying to get to that two minutes? Is it that we don't have enough riders on the road? Is it that our algorithms in matching is not good? Maybe there's plenty of riders. We're just not matching them correctly. Is it something else? So you would want to go through all of those problems and figure out which one is preventing you from reaching your goal.
Then you're going to execute towards it. So if it is an algorithm problem and it's a matching problem, you would step through and say, okay, I now understand that it's an algorithm problem. Let me set a goal for making this algorithm better. Maybe the goal is to get them in less than two. That's your goal, right? Less than two minutes. And you want to break down what to do to try that. So maybe you narrow down your subset and test this algorithm on a small city that has this problem and see if you can get it down to two. You keep iterating on your algorithm until it gets there. Something like that. Or you run scenarios in the background to see. If it gets to be less than two, you test it out. You try it. You can do that. It doesn't have to necessarily be user-related. And actually, Toyota comes from a place of continuous improvement on the Toyota production line. So they weren't really looking for outcomes from customers until the very end. Instead, it would be like, how do I make it easier to put wheels on these cars, right? How do I make it better to be able to switch up different colors depending on demand? And people would think through what they needed to change in their process or their deal. They work to do that. And they would work with their leaders to understand the goals above them, figure out how they contribute to it based on their part of the world, go out there and try to continuously improve. So that's really what the Kata is there for. And that's how I think about discovery and how I think about getting towards outcomes in product management is to constantly be saying, where am I going? What's the strategy based on my part of the world? What's happening now? What are the problems standing in the way of me trying to reach that strategy with my view? How do I break? How do I break those down into smaller goals we can achieve? And then how do I execute on them to learn what we should build? That's really what the Prada Kata is for and systematic way to help you learn, right? Systematic way to help you learn. That's what you really want to be concentrating on. So when you think about discovery or you think about any of these frameworks for discovery, it needs to be around things that are uncertain. So let me start off with that. If you are 100% certain that by doing X, you will achieve the outcome you're looking for, you don't need discovery. Just like go do it. If you know exactly what it is, if there's a bug and it needs to be fixed and that's going to fix something, like fix it. Do not discovery around that. Like that's not what it's there for. If there is uncertainty, Prada Kata, product discovery helps you lessen that uncertainty. And that's really where we want to be looking at product discovery, which you can do internally and which you can do around algorithms because there are questions that you need to answer around that. So if you have questions you need to answer about how certain things work, how people will behave about anything. About if it will work or not, like that's where you use discovery and that's how you think about product discovery in that way. So I really hope that helps.
And now we're going to talk more about outcomes with Jeff and Josh. Did you know I have a course for product managers that you could take? It's called Product Institute. Over the past seven years, I've been working with individuals, teams, and companies to upscale their product chops through my fully online school. We have an ever-growing list of courses to help you work through your current product dilemma. Visit productinstitute.com and learn to think like a great product manager. Use code THINKING to save $200 at checkout on our premier course, Product Management Foundations. Welcome, Jeff and Josh. It's great to have you here. Hello, Melissa.
Jeff Gothelf - 00:07:31: It's nice to be back.
Josh Seiden - 00:07:32: Yeah, good to see you.
Melissa - 00:07:34: So I've had both of you on the podcast before. I'm excited to have you back together because you are talking now about your new book coming out on OKRs. But before we jump into that, I do want to ask you, how did you guys meet?
Jeff Gothelf - 00:07:48: I'll tell you how I remember it. I don't know how Josh remembers it because it wasn't like a single event. I think this is roughly sort of mid-2000s, mid to late 2000s. I'm back in New York and I am leading the design team at The Ladders. And I've started attending meetups and events and speaking at these meetups and conferences. And it felt like everywhere I went, if it was a panel discussion or some kind of a multi-person conversation, Josh was a part of that conversation. He was always there. He was one of the other people on stage, which I found really annoying. I was like, why is this guy always here? That's kind of how it began. And then there's Phil Terry's Creative Good Councils. In New York and all over the states, in fact. And Josh and I were both part of that. And I think we officially said hello at one of those events as sort of mid-level design leaders at various companies. And that was part of the event there. So it was a combination of both professional networking, but also repeatedly ending up talking about the same thing at the same places, often at the same time, is what happened.
Josh Seiden - 00:08:59: And an overlap of interest. We were both interested. And kind of that intersection of design and agile and how they could work better together. So it ended up being an alignment of both place and interest.
Melissa - 00:09:13: So it's actually the 10-year of when I met you two as well, because it was at the Lean UX Conference in 2013. So happy 10-year .
Jeff Gothelf - 00:09:22: Yeah, that's crazy.
Melissa - 00:09:24: I know. I can't believe it's been 10 years. I'm like, where did time go? That was actually the first conference I ever spoke at. So that's pretty cool. So since you guys met, you've done a lot together. You actually wrote two other books together, Lean UX and Sense and Respond. What have you been observing out there in the product communities since you wrote that book? And what led you to concentrate on OKRs now?
Josh Seiden - 00:09:47: I think when Jeff and I first started working together and thinking about the things that we were interested in, the big problem, I think, was how technology teams could work together more effectively in a cross-functional way in an agile context. So Lean UX was a design book, but it was really a book about how designers and product people and engineers and all the other roles that go into making digital product, how those folks can work together in a collaborative, cross-functional, agile way. It was one of the first books, I think, to really grapple with that problem. Certainly, it felt early in that question at the time. Ten years on, I think we understand that that's how digital products get made effectively with cross-functional collaboration. It's not that everybody's doing it or that we've solved the problem, but we understand that that's the key component of the answer. And so the question then sort of becomes, like, how do you coordinate the activity together? Of lots of teams in an organization, right? How do you think about that management layer? Sense and Respond, the book, was an attempt to kind of think about that from a principal's point of view. But OKRs has really emerged as a system that companies are using to try to put that management layer in place for organizational agility. And it just felt like in all of the work that we were doing, that topic just kept coming up over and over. And so it felt like the right time to address it. Thank you.
Jeff Gothelf - 00:11:18: I think in many ways for the last decade, we've been backing our way into the OKR conversation. I think initially not deliberately, and then in recent years, deliberately, right? So Lean UX was a super tactical, practical book, right? About how to very specifically work together as a team. Sense and Respond was, well, how do you manage a bunch of these teams trying to work together? And then kind of back it out a layer further. And you think, well, how do we set goals that enable us to manage these teams successfully so that they can do this really great collaborative work really well? And so in many ways, we've kind of been on this journey for a long time. I don't think, I certainly didn't know it at first, but then in recent years, it really made sense that this was the way to go. Because if you set goals appropriately and you align an organization around achieving those specific goals, the rest of the things, management styles, incentive structures, team motivation. The level of customer centricity, humility, course correction, all of those things that make for a great customer centric, agile organization. They begin to happen, not overnight, but they have at least the opportunity to take place there.
Melissa - 00:12:31: What have you observed as like some of the bigger shifts in agile and Lean UX and OKRs since you wrote the two books, right? It's been almost 10 years that you've been working with these companies. Let's say 10 years ago, people were trying to stand up agile implementations of this in their organization. Now they're maturing. What have you seen as like the biggest shifts in organizations and how they approach product development?
Jeff Gothelf - 00:12:56: Not much. No, I mean, I really, I was trying to find some optimistic way to say that. But recently, a friend of ours came back from maternity leave after a couple years away on maternity leave. And I think she asked, she asked a group of us, hey, what's new? Are you all working on? That's different since I was last active and working. And the answer was same old stuff. I think people are using different language. I think people have a good understanding of what good looks like. I think that there's a lot of positive intention and intent inside organizations. But when it comes to sort of the day-to-day problems that we deal with with our clients, the conversations are the same. I hate to say it. Again, it's about, well, we have to deliver this feature by Friday and we have to make it red. Well, how do you know? Well, because the boss said so, so it has to be done. Or the client demanded it or the competition has it. And it just feels like we've been having the same conversations. And so while I think there's a greater awareness of better ways of working, and I think to some extent in most organizations, there is some deployment of the conversation. And so I think that's a great way to do it. These better ways of working, the challenges that we're solving. In my opinion, are roughly the same as we were solving a decade or 15 years ago.
Josh Seiden - 00:14:16: I'm going to disagree just a little bit. Well, I would say the conversation has changed a little bit. Like some of the stuff is settled. Like the notion that we were first kind of working in this agile world, there were people who were like, no, agile doesn't work. Just like give up. And I think like, okay, that's kind of a settled conversation, right? The question is how do we get agile? And then I think a conversation that we're in the middle of about how do we do quote unquote agile at scale? And the first answer was SAFe. And I think I'm starting to see the first post SAFe organizations, right? So organizations that adopted safe were all in, were like, we found the answer. And then a few years later, they're like, oh. That wasn't the answer. And they've jettisoned SAFe, and they're trying to keep the parts of safe that were useful to them and throw away the parts that were not, which I think is a really positive sign, right? That's a learning organization right there. So I think in some ways the conversation has moved forward. I think, to Jeff's point, the day-to-day practical challenges of being agile in a large organization are the same ones that we've been seeing for a while. But I think the maturity level of the industry as we're trying to address this stuff has advanced.
Melissa - 00:15:31: Yeah, I'm pretty happy that a lot of people are starting to jettison SAFe. So I've definitely seen that too. I was pretty worried when everybody was. Grabbing onto it and be like, this solves all our problems. But I've seen the same thing that you have. I know a lot of large companies that started with it earlier now are like, yeah, that didn't really work for us. But these typical practices are still good. When you think about the core of the things that worked, you know, out of SAFe or some of these agile cadences, what did companies tend to hold on to? What have you seen them stick with?
Josh Seiden - 00:16:00: I was at a dinner the other night with one of these, some folks from one of these post-safe companies, and they were saying to me that they threw out some of the bigger, heavier ceremony planning rituals, but the need to do that cross-team, cross-program coordination remains. And so they've tried to metabolize that into their own kind of organic version of that planning. And so it's a little bit of the, like a shoe-ha-ree story.
Melissa - 00:16:27: That's what I want to bring up too, that SAFe totally just sprinkled Lean UX into that framework. How has that affected, I guess, you guys being brought into organizations and are people trying to figure out how to put Lean UX in the SAFe?
Jeff Gothelf - 00:16:43: It hasn't come up recently, but it has come up, especially when I think it was SAFe 4.5, and I have no idea where they are today. That was the version that consumed Lean UX. So it was like a big Pac-Man, just like cool. And at that time, I started getting a lot of inbound. Hey, can you come tell us how to do this? Can you come tell us how to do this? And this was just about the time where I think it's my most popular blog post came out, which is SAFe is not agile. And that was where I sort of like, look, this isn't an agile. It says agile and it says SAFe, but it's neither one of those things. I mean, it is SAFe, but it's not agile. And I lost work because of that. People would come to me and say, does this work? And I said, just because it's in there, given the way it's, and I read, I read up how they wanted to deploy it as part of this thing. I said, it doesn't make sense to me in this way. And several organizations that I think considered hiring me at the time that were going all in on SAFe and wanted to include Lean UX into it, ultimately decided not to hire me, ended up losing work because of my honest opinion that it doesn't work. Certainly these two concepts together didn't work. And so I don't think. But there's, there's an obvious way. To make it fit given the lack of agility, the lack of any kind of realistically short-term feedback loops that are needed that don't exist in SAFe.
Melissa - 00:18:06: That's really interesting. So with those companies that were going all in on safety, you still see them going all in?
Jeff Gothelf - 00:18:11: I hear the language. You know, I think the language remains. The vocabulary, release train, release train engineer, those type of conversations are still there. How religious people are about it, I don't know anymore. There definitely was a point in time where it was like, it's either SAFe or it's out. Like it's either in the recipe book or it's not. I don't get the sense that that's the case anymore, but I'm not sure. The language has persisted for sure in the enterprise.
Melissa - 00:18:41: I think SAFe is one of those frameworks that very much like OKRs, right? Where people latched onto the terminology, didn't quite understand what they were getting, try to implement it. And then it's coming out in all different ways. And I also see that happening, you know, happens with a lot of stuff. And I just had Heaton Shaw on the podcast and we were talking about how Lean Startup got butchered and, you know, all these different things, growth hacking, how all those terminologies just became like something of its own, right? Its own beast where people didn't really deeply understand what they were getting when they adopted them. And I see that happening with OKRs as well. And I'm curious what your take is on it. When Measure What Matters came out, everybody wanted to latch onto OKRs. I think SAFe also has OKRs sprinkled in somewhere, somewhere in there, just, you know, on the top. But everybody has been trying to adopt OKRs, some with more success than others. There's kind of a misunderstanding of what a objective is, what a key result is, how you actually use it. You guys are writing. You're writing a new book on this. Why do you think people misinterpret this? And how have you seen them misinterpret OKRs? And what should they really be focusing on there?
Josh Seiden - 00:19:48: Maybe I'll say one thing that's not specific to OKRs, but maybe more about like frameworks that help us work in a new way, which is that working in a new way is hard. Changing the way we do things is just a hard problem. And it's hard because we work in these systems that have. Resulted in making it easy to work in the way we're currently working and hard to work in a new way. That's just the context of all of this stuff. And so frameworks, whether it's Lean UX or I'll put SAFe in here, agile, OKRs, they give us a language to talk about the change we want to create. And that's great. That's just the first step is having a language to talk about it. Then you actually have to make that change. And so a lot of times I think. It's just easier to talk about the same old stuff with new language than to actually change what's happening.
Jeff Gothelf - 00:20:47: I think there needs to be a clear reason to change as well, right? And I think that's missing from the conversation a majority of the time, or at least it's not explained to the, why are we adopting agile? Why are we adopting SAFe? Why are we adopting OKRs or Lean UX? Those conversations rarely happen. It's more like, we're doing this, starts Monday, good luck.
Josh Seiden - 00:21:08: Even with the methods that we teach, Jeff and I, we really Lean into this notion that Lean UX, Lean Startup, these kinds of methods where we are leaning into discovery. That's what we're about. But that's not the right way to work for every team. That's the right way to work when you're facing a tremendous amount of uncertainty, which for most digital product teams, most of the time is true. But there's some work that's well understood, and it's just a problem of executing well and consistently. But when we teach these methods, I think people lose track of why we're using the method. And they think, oh, Jeff and Josh think you need to use Lean, Lean UX everywhere. Can we Lean UX our dinner? Let's really take a moment here and understand, what's the method for? Why are we using it? Let's not make the mistake of painting everything with a Lean UX brush.
Melissa - 00:21:59: I think that's a really good point. I see people do that with experiments all the time, like just experimenting your way to things that are already known, like no knowns, like a bug. Like you don't have to experiment around a bug. You don't have to experiment around certain things that have been done before that have proven that they work. But I think a lot of people do embrace these tools and it really gets back to like that first principles debate. Like, do you understand what you're actually using this thing for? Or are you just adopting it and running with it and trying to put into place and then getting frustrated and blaming the tool because you used it inappropriately and you didn't understand why you should be using it and why it was beneficial and what outcome you actually wanted before you adopted that tool. And I see that kind of happen all over the place. So this kind of resonates.
Josh Seiden - 00:22:44: Jeff and I used to do a workshop with Barry O'Reilly. It was about proving your enterprise agility. And we would have all these agile coaches come into these workshops. And their starting point was, we wanna help the organization be more agile. And it's like, okay, why? It's like, well, we have this hammer and we wanna hammer more, right? And so really getting at like, okay, well, agile is just a hammer. So what are we using it for? Is it the right tool? And what are we trying to improve in the organization? That was genuinely, it was a two-day workshop. We would spend the first day just trying to help people clarify like why we wanted to use the tool.
Jeff Gothelf - 00:23:20: Yeah, and so a bunch of CEOs read Measure What Matters and they saw Google's doing it. So we should do it too, but never understanding why they should do it, what the implications are of it and how it might actually need to change the organization as a whole, right? Setting goals, it's a short phrase, but the impact is literally huge. It touches every part of an organization when you change what the measures of success are for the organization. And what I think didn't do us any favors was Measure What Matters, right? I think it did us a great favor by introducing the concept to a lot of folks and to make it in-demand conversation, which I think was smart and great. But what it didn't do us any favors on was being specific and deliberate about why this is different and why it should be different. In fact, it was very loose. It was very loose. On what the goals could be. And I think that when you're loose about what the success criteria could be, people will default to the path of least resistance, which is what are our current goals? Do they fit into this framework? Oh, they do? Terrific. Then yeah, yeah, yeah, we're doing OKRs. That's great. We're doing it. And I think that's one of the fundamental differences in our book is that we are making a strong stance about what a good OKR is and why that's important. And if you don't stick to that, it actually breaks the idea and it devalues the exercise. You might as well not do it.
Melissa - 00:24:51: So what is a good OKR?
Jeff Gothelf - 00:24:53: That's such a great question. I can do it really quick. A good OKR, and it's two parts, right? Objectives and key results. The objective is a qualitative, aspirational, and inspirational statement for the work that your team is doing. So this is the reason they get out of bed every day. This is an alignment statement. And depending on where the team sits in the organization, it could be more strategic, it could be more tactical. But the idea is to really think through about why we're doing this work. We're trying to make something better, more efficient, easier to use, more accurate, whatever it is. We're looking for those kind of qualitative descriptors. And again, something aspirational. Make it a lot easier for first-time homebuyers to get a mortgage, something along those lines. That's the objective. The key result is the quantitative part of the conversation that tells us how will we know we have achieved the objective. And the fundamental difference in the OKR ideology that we're pushing forward in this book is that your key results have to be outcomes. They have to be measures of human behavior, the humans that you're actually serving in this particular case.
And that's how you know that you've actually delivered value. And I think that where this gets fluffy in Measure What Matters and in a lot of organizations is that they're not strict on that. They will let outputs become the key results. And if you have an output, like a feature, we're going to make it the easiest way for first-time homebuyers to get a mortgage is our objective. And our key result is mobile mortgage application by Friday. We've changed nothing except the name of the goal. The goal is now called OKR, but all we've done is fixed time, fixed scope initiative. Same thing we've always been doing. When you change the goal to a key result, increase the number of first-time homebuyers applying for a mortgage with our bank by 100%. All of a sudden, you get a clear sense about whether or not you've actually delivered something of value. But the fundamental difference here is that the goal isn't dictating what you're delivering. The goal, the OKR, is dictating how you'll know you've actually delivered something of value. We want to see people changing their behavior in a meaningful way for them that positively impacts the business as well.
Melissa - 00:27:11: Are you eager to dive into the world of angel investing? I was too, but I wasn't sure how to get started. I knew I could evaluate the early stage companies from a product standpoint, but I didn't know much about the financial side. This is why I joined Hustle Fund's Angel Squad. They don't just bring you opportunities to invest in early stage companies, they provide an entire education on how professional investors think about which companies to fund. Product leaders make fantastic angel investors. And if you're interested in joining me at Angel Squad, you can learn more at HustleFundVC. Find the link in our show notes. So one of the big misconceptions that I see with OKRs as well is that people use them more for like an HR management tool. And they make every single person have an OKR. And they want every single person's OKR to be slightly different. And they usually get very output centric like you were talking about. Should you be doing that with OKRs? How many OKRs should an organization have?
Josh Seiden - 00:28:08: If you kind of go back to why OKRs are useful, I think one of the ideas that I like a lot about OKRs is an idea from Christina Woodke, which is that OKRs are for focus. We don't use OKRs to describe 100% of the work that's going on in an organization. We use OKRs to talk about what is the focus of our work and how to align focuses across large groups of people. First of all, there's going to be stuff that falls outside of OKRs. She calls those health metrics or heartbeat metrics. You hear some people call them KPIs, whatever. Some portion of the work is focus work. Some portion of the work is not. But now if we think about focus and alignment, what are we trying to do? We're trying to get everybody pulling in the same direction. And so the more complicated that your incentive system is, the more directions people have to pull in. If you give everybody the same incentive, then everybody pulls, in the same direction, theoretically. But when you start multiplying the incentives, and how do you multiply the incentives by the number of employees you've got? You give everybody their own OKRs. Then suddenly everybody's got their own incentives in addition to team incentives. Okay, fine. Now you can measure individual performance, but you've just messed up your ability to align all of these people by giving them contradictory incentives. So I think the reason you don't use OKRs for individual incentives is, exactly. You want to simplify the alignment process by introducing as little noise into the process as you possibly can.
Jeff Gothelf - 00:29:40: I'll also add here that there's another reason why OKRs break down at the individual level is because ideally OKRs is you're measuring the impact that what you're doing has on other people. But the way that individual OKRs typically take shape is something like, well, my objective is to become a 10X developer by the end of next year. Cool. What are your results? Well, I'm going to attend three conferences, take five online classes, and give a speech next year. Okay, fantastic. And then you did that. Are you a 10X developer? The answer is, I don't know. I did all those things, but that's not an effective way to measure whether or not I've actually improved my contribution to the company. And it's a lot harder to set goals that measure that. So the organization will default to those very easily measurable activity-based goals. Take a class, read a book, go to a conference. Give a speech. And then that ends up being super hackable and achievable, but it doesn't actually tell the organization whether or not you're better at your job. And so generally speaking, it just breaks down at the individual level.
Melissa - 00:30:47: Okay, so we're looking at OKRs then on the team level. How does this work to like scaling up to executives? Do executives have OKRs? What do those look like? And then how should we think about cascading them down to teams? And I also see people do this wrong as well. I feel like somewhere, and I don't know where the hell this was written, honestly, but I see people interpret that somebody's OKR, their key results should be somebody else, the next team down objectives. Objectives. I read this somewhere and I've seen teams do this and I'm like, what the? Like, I don't know where that came from, but no idea. But I've seen several companies do this where it's like, OK, I have the top level objective and key results. And then the next team takes those key results and those become their objectives. And I was like, what the? So curious how you see these things cascade correctly.
Josh Seiden - 00:31:36: Well, I think in an informal way, that certainly can work. You know, I think there's a useful question to ask, which is like, OK, this is the organization. This is the next level. This is the start at the top. This is the organization's goal here. What can my team do to contribute to that goal? And so I think, you know, looking up to that OKR is important and looking at the pieces of the OKR. Oh, well, the key result is to increase the number of registered users on our website. OK, well, what can we do to increase the number of registered users on our website? That's an interesting conversation. Is it a mechanical conversation where you just copy and paste? No, it's not right. This whole thing has to be a critical thinking exercise. Yeah.
Melissa - 00:32:15: And I totally agree with that. Like to me, like that's strategy deployment, right? It's like you have to actually make sure all these things go together. And then if my objective above me is to increase, let's say, adoption of a product, then there has to be some kind of data behind my objective, right? About how solving this problem will increase adoption, right? And the results we can track that show that it leads to it. What I see people do is literally copy and paste it, which is wrong. So I want to just point that out that if you were doing that, that's wrong. But I like the way that you're describing it. So tell me more about when you're like working with executives as well, like what types of OKRs should they be handing down? How do they make sure that they set the right tone and the right, I guess, scope for an organization so that people can look at it and say, how do I contribute to those OKRs?
Jeff Gothelf - 00:33:02: So the way that we talk about it is that you should be setting objectives and key results, goals for the organization that you have influence over, right? So what is the world that you can impact? That's where your OKRs go. So if you're an executive and you own a company, like you're in charge of an organization, then you're setting corporate goals, enterprise-wide goals. If you're an executive in charge of a business unit, your OKRs are going to be focused on that business unit. If you're in charge of a product within that business unit, that OKR is going to be for that product. And if you're in charge of a portion of the customer journey of that product, then your sphere of influence is just, your OKR is going to be focused on that portion of the customer journey, right? You're the authentication team. Your OKR should be focused on making the easiest, smoothest, most efficient, most successful authentication process, right, in the world, that type of thing, because that's the world that you can influence. I wholeheartedly agree with you, Melissa. You should be able to then say, when we make this authentication process the best it can be, that actually leads to more folks interacting with the system more quickly, and it reduces our operational costs, because we're not getting calls to the call center to reset passwords, right? So that's how we're contributing to the organization, by making the best authentication process possible. But that, to me, is what do you have sort of influence over? And that's the scope of your goal, of your OKR.
Melissa - 00:34:27: That makes a lot of sense. When you think about this, too, we've been talking. We've been talking very heavily about digital product management and software product managers. You just mentioned you could be overseeing, as an executive, a different part of the organization that's not necessarily software or product management. Have you seen OKRs work successfully in things that are not software-related?
Jeff Gothelf - 00:34:48: We have, in fact, and it's a really interesting conversation. So the case study that I love to share often is one from the Cleveland Clinic. Cleveland Clinic is a high-end medical healthcare organization. It's global, but perhaps no surprise to anyone, it's headquartered in Cleveland. The CEO of the Cleveland Clinic publishes their organization-wide OKRs publicly every year on their website, and they are incredible, right? So the two that come up every year that seem to be kind of perennial favorites in this particular case are Best Place to Receive Care Anywhere as the objective, which is qualitative, it's aspirational, it's inspirational. It's the reason why everybody gets out of bed at Cleveland Clinic every day. And it's the scope that the CEO has, the scope of influence that the CEO has. It's the organization, right? So Best Place to Receive Care Anywhere. And it's the scope of influence that the CEO has. It's the organization, right? How do we know? Well, they're looking to reduce the rate of serious safety events, and they're looking to reduce sort of the absolute number of serious safety events, things like that.
Those are the behavior changes that they're looking for in the staff. So I really like that as an OKR from the healthcare space. And then in that same OKR scorecard, the CEO also shares in the internally facing OKR, which I think is fantastic. And I think a lot of times we don't talk about this as much, but the... The objective is best place to work in healthcare. And the key results for that are the percentage of current employees who would recommend it as a place to work, the percentage of employees who actually have recommended as a place to work. And they have a metric that they use occasionally called regrettable turnover, which is folks voluntarily quitting that we didn't necessarily want them to quit. And so those are, again, measures of human behavior that tell us that we're building the best place to work in healthcare. And so I think that's a really good Now that's, again, org-wide. It's delivered to the rest of the organization to figure out how to solve for it, right? They don't know how to build the Best Place to Receive Care Anywhere necessarily. Like it's not dictated to them, right? They have to go figure out how to make that a reality.
Melissa - 00:37:01: So with these other organizations, as they're thinking through these, you talked about like their OKRs and their key results are a little more contextual to what they're working on, obviously, like if you're in HR or if you're in legal or something like that. Is there anything else that you see drastically different about the way that they operate with OKRs or how they use OKRs if they're not working on a digital product team?
Jeff Gothelf - 00:37:22: What it does is it forces people to rethink how they do their work and what happens to their work once they're quote unquote done with it. So there's a conversation I had with a client and the client makes shoes. It's the business of the company. Now they sell shoes online, they sell shoes in retail stores, they have multiple brands, but at the end of the day, they're a shoe company. It's what they make. And one of the folks that we were working with when we were setting up their OKRs was the shoe designers, particularly there's a shoe designer in the conversation with us and his job was to design these shoes and then he would just hand over the design to a bunch of different people. And he never really thought through sort of what those folks needed to do with his work. He just needed to define a shoe design and then hand it over. And when you start to have a conversation with folks and help them realize that the people that they hand off their work to are in essence their customers or their consumers or their users or whatever the best word is for it. And then those folks are going to use that output to make themselves more successful and more successful. It's a different conversation, right? So the shoe designer puts out a shoe design. Now it's got to go out to the merchandisers.
It's got to go out to the marketing folks. It's got to go out to the folks who procure and buy material to make the shoe. It's got to go out to the financial planners who have to figure out how to make profit on the shoe, what to charge for it, et cetera. There's all kinds of folks. And so once you start to consider what other people have to do with the work output that you're creating, you start to think about, well, how can I make those folks more successful? What does it mean for the merchandiser to be more successful? What does it mean for the buyer, the procurement buyer who has to go buy a bunch of leather and shoelaces or whatever, right? For their job and how can I make my work more effective for them? And I think that that is an awakening in an organization that really is one of the biggest benefits of using OKRs because folks generally, I made a shoe design. I hope it works for you. Take care, right? As opposed to, hey, did that help you be more successful? If not, what can I do differently to make you more successful at work? And that was a really interesting conversation because particularly with folks who don't make digital products or services, they don't think about their work this way. In fact, sometimes they don't even think they make anything at work. And I think that that's a huge flaw. And I hope that our book helps awaken that in some folks.
Josh Seiden - 00:39:51: If you think about the earliest kind of expressions of Lean UX, Jeff wrote an article, which I think crystallized it for a lot of people. It was the article became the book. The article was called Getting Out of the Deliverables Business. And it was about shifting the conversation in the design world from how can we make more beautiful deliverables? How can we make better deliverables? How do we make a deliverable like this or like that? To how can we be more effective members of the team? And how can we help the team be more user-centered? And that's a really, really big shift in the way we work, right? Instead of thinking about, like, I'm going to polish this book to a high, high gloss to say, like, actually, my job is to make this team more successful. And I think that goes again back to maybe some of what we were talking about with why we don't use OKRs for individual performance management. Because ultimately, the focus needs to be on making our team most successful.
Melissa - 00:40:47: Think that's a really good way to start to frame it and think about why do we actually use OKRs. So Jeff and Josh, there are a lot of books out there on OKRs already. We've got, you know, What Matters, which we covered. We got Radical Focus by Christina . And what can people expect from your book that might be a little bit different or things that you've seen people
Josh Seiden - 00:41:08: struggle with that you're trying to solve for? So I think our reader is a person in an organization whose boss read Measure What Matters and got excited by it and said, hey, folks, we're doing this. And so I think one of the things that we're good at as a team is taking complicated ideas and making them practical and actionable in the real world. And so this is not a theoretical book. This is a real practical book that you can open and keep on your desk and get practical guidance for how to create my OKRs, how to manage the OKR process. How to help my teammates do it. So that's the first thing. The second thing is the pitch that you've heard Jeff make a couple of assertions about our point of view. The first one is that everybody has a customer. So how do I, a person working inside a huge organization who's not allowed to talk to customers, how do I make a difference? For the business. It's this notion that everybody has a customer, which means that who's that person in the next cube who consumes your work? And I think the third thing is maybe that this really is about taking this idea of outcomes, which is that we want to be more results-oriented, and simplifying it down to the core message. So the name of the book is Who Does What by How Much? If you answer those three questions, you've described an outcome. An outcome is a valuable change in human behavior. So who's the human? What's the behavior? Does what? By how much? How can we measure it? And so the whole book is about that. It's about really taking this very abstract world of ideas and making it simple, practical, and applicable to everybody in an organization.
Melissa - 00:42:53: My last question, well, second to last question for you, when can we expect the book?
Josh Seiden - 00:42:58: One of the challenges with any kind of creative work is that you don't know when it's going to be done because it has to be good. And so we've got a good first draft, which is what you need. And we're going to start on that second draft, which is going to get us across the finish line. The book should be available in Q1 2024.
Melissa - 00:43:17: Awesome. So we will definitely link to that in our show notes so that you can sign up and be notified when the book goes live. So if you go to productthinkingpodcast.com, you can find the link to the book. My last question for you two is third book together. You both written books by yourselves as well. First of all, do you just love torture? And second of all, how are you not sick of each other yet?
Jeff Gothelf - 00:43:39: I'll tell you this. I mean, look, and it's not just third book together. I mean, we wrote Lean UX three times. It's in its third edition. So this is like sixth book together or whatever, whatever the number is. But I think about this a lot, actually. I mean, we're super lucky. Like we have a fantastic partnership and a very, very open and honest working relationship. I mean, Josh was just here recently visiting and we hung out and we're friends and everything. But like, I think what works really well is we have complimentary personalities. And what I mean by that is I speed Josh up. He slows me down. That's a really healthy tension, which makes everything better. We end up shipping stuff, which is nice. And I think there's a mutual respect, I think. And there's an honesty and transparency that when something isn't right for one of us, we just bring it up. I mean, there's no negative feelings. There's no bad blood or anything like that. It's more like, hey, listen, when this happened, you know, this didn't work for me. Can we do it differently next? And that comes up, I don't know how often, whenever it needs to come up.
And we deal with it like adults. And I think partially is because I'll speak for myself, but I think both of us really value this partnership. And so every now and again, I partner with somebody else, not for books or stuff like that, but for a class or a collaboration, or maybe it's an article or something, along those lines. And every time that starts, that process starts, I always back channel Josh. I'm like, oh, I was like, I wish you were here. Well, I mean, it's just, there's a level of, and again, there's a lot of sort of unspoken stuff. Like we've done this so much and so often on such a regular basis now for so many years that there's a lot of unspoken stuff that doesn't need to be said, right? There's just sort of like assumptions. I know he's going to pick something up if I drop it and vice versa, right? So like, it's a good collaboration.
Josh Seiden - 00:45:32: I'll tell you, early in my career, I was very aware of the things I wasn't good at. And I thought the solution to that was to try to get good at all these things that I wasn't good at. And what I came to realize was that it's much more effective to be good at what you're good at and partner with somebody who's good at the things you're bad at. And I think speaking for myself, Jeff is really good at a lot of things that I'm really bad at. And I value the things that he's really good at. And so it seems to work.
Melissa - 00:46:00: I think the quality of your books and your work has definitely reflected that this is a great partnership. So I am looking forward to reading the new book. Thank you both for being on the podcast. If people want to learn more about the book, what website can they go to?
Jeff Gothelf - 00:46:13: Www.okr-book.com is where the mailing list signup is. And then we have an OKR community on LinkedIn as well. So either one of those is a great place to go. The mailing list will eventually get you to the book community on LinkedIn as well.
Melissa - 00:46:29: Great. And we will post all of those links in our show notes again at productthinkingpodcast.com. And we will link to Josh and Jeff's LinkedIn so that you can stalk them and see all of their great writings. Thank you again, both for being here. And thank you to our listeners to listening to another episode of the Product Thinking Podcast. We'll be back next Wednesday with another episode and another fabulous guest. So make sure that you hit that like and subscribe button so that you never miss another episode. We'll see you then.