A (4:27)

always planning What I like about your approach too is I feel like it's very pragmatic when you're introducing okrs or this concept of how we measure things to companies for the first time. There's a lot of people who are very dogmatic about it and say, hey, we should have started with the outcome and the key results. And it's, yeah, in a perfect world, you should have. But we live in a world where we've got a lot of stuff in progress. And if we're going to do this for the first time, why don't we actually look at what's in progress, label that, and then next time when we go to do the research, then let's look at our okrs, then we can get into it. And I think that's such a realistic place for companies to start. And I'm so glad that you talked about it because I feel like sometimes people have that disconnect where they're like, oh, I want to do this the right way, so let's just throw out everything we're working on and start all over again. And you're like, no, you still have to deliver things. Like, the stuff you're working on may be good, we just haven't expressed it that way. And that lets us know if it's good.

B (5:20)

No. And I think a lot of people have used OKRs as an excuse to aspire to a lot. Right. But then you say, but what are you actually delivering? Yeah, is it worthwhile? And oh, but we're hitting these numbers that we set out. Either sometimes they're too cautious or, or you realize that they're building something, but it become, becomes a Frankenstein's monster. It has to be connected to, you know what, we have to keep producing, we have to keep bringing that value. And you might hit those numbers, but if the long term value is broken, it isn't worth anything. And so it's an education piece and everybody has their opinion. It's. You bring up okrs and we've got 500 opinions about everything.

A (5:55)

What Hugo laid out is something a lot of teams avoid saying out loud. OKRs can easily become a way to look ambitious without actually delivering. Splitting them into discovery, build and outcome types gives teams a more honest way to track progress and stay flexible without losing sight of what actually needs to ship. But even when you structure okrs well, there's still the question of what makes a key result truly meaningful. And that's where a lot of organizations quietly get it wrong. Here's Jeff and Josh.

C (6:24)

A good okr. So 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, you know, more accurate, whatever it is. We're looking for those kind of qualitative descriptors and, and again, something aspirational. Make it, make it a lot more, make it a lot easier for first time home buyers to get a mortgage.

A (7:13)

Right?

C (7:14)

Something along those lines, right? That's, 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 ideology, 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 behav behavior.

A (7:36)

Right.

C (7:36)

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 and measure, what matters in a lot of organizations is that they're not strict on that, right. They will let outputs become the key results. And if you have an output like a feature, we want to make it the will be the easiest, the easiest way for first time home buyers to get a mortgage is our objective. And our key result is mobile mortgage application by Friday. Yeah, exactly. By Friday. Exactly. Right. We've changed nothing. We accept the name of the goal. The goal is now called okr. But all we've done is fix time. Fixed scope initiative.

D (8:18)

Right.

C (8:18)

Same thing we've always been doing. When you change the goal to a key result, right. Increase the number of first time homebuyers applying for a mortgage with our bank by 100%.

A (8:29)

Right.

C (8:29)

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.

A (8:54)

I don't recommend tools unless I actually use them. So when I tell you granola has become A daily essential. For me and most of my team, that means something. We're all in a lot of meetings. Granola is an AI notepad that quietly enhances your notes in the background. No bots joining your call, no awkward recordings. Just cleaner thinking after every meeting. It's the rare tool that gives you time back instead of asking for more of it. You can try it yourself with 3 months free on any paid plan at granola. AI productinstitute. So we're looking at okrs then, on the team level, how does this work to, like, scaling up to executives? Like, 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, right? Like their key results should be somebody else. The next team down, 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, okay, 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. Like, what the hell are you doing? So curious how you see these things cascade correctly.

E (10:18)

Well, I think in an informal way that certainly can work, Right? You know, I think there's a useful question to ask which is like, okay, this is the organization. This is the next level up, right? This is. Let's start at the top. This is the organization's goal here. What can my team do to contribute to that goal?

A (10:38)

Right?

E (10:38)

And so I think, you know, looking up to that. Looking up to that OKR is important. And looking at the pieces of the okr, right? Oh, well, the key result is to, I don't know, whatever, increase. Increase the number of registered users on our website. Like, okay, well, what can we do to increase the number of registered users on our website? Like, that's an interesting conversation. Is. Is it a mechanical conversation where you just copy and paste? No, it's not. Right. It's a. This, this whole thing has to be a critical thinking exercise, you know?

A (11:09)

Yeah, and I. 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, 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, 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 working with executives as well. 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?

C (11:58)

So the way that we, 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, what is this, this, this kind of the, 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 own, but you're in charge of, of an organization, then you're setting corporate goals, enterprise wide goals, right? If you're an executive in charge of a business unit, your OKR is going to be focused on that business unit. If you're in charge of a product within that business unit, right. 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 OK is going to be focused on that portion of the customer journey, right? You're the authentication team, right? Your, your okr should be focused on making the, the easiest, smoothest, most efficient, you know, most successful authentication process right in the world, that type of thing. Because that's the world that you can influence right now. 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's to me is what, what do you have sort of influence over? And that's the scope of your, of

D (13:31)

your goal, of your okr.

A (13:32)

That makes a lot of sense. So Jeff and Josh made the distinction really clear. A key result is not a feature, a launch date or a project milestone. It has to be a measure of behavior change. If you can rename your existing roadmap as an OKR without changing anything about it, you've got the wrong goal. And the cascade problem they described is just as common. Every level of the Org taking the key results above them and calling those their objectives. That's not strategy deployment, it's repackaging. For our final perspective, let's. Let's hear from Anish on what it looks like to actually fix this inside one of the most complex product environments out there. Besides, you know, history of meeting all these deadlines and being accountable for it. Why do you think people have a hard time thinking in outcomes? What, what have you seen be the thing that people resist and what have you used as ways to get them to be more outcome oriented?

D (14:24)

Yeah, I think there's two answers to that. Number one is everybody loves to say it's okay to fail until you actually do, right? And then all of a sudden, everybody comes out of the woodwork and how could you let this happen? And for every one person doing something, there's six people telling they're doing it wrong and things like that as well. The other thing I'd say, Melissa, is the challenge with outcomes is you can't escape accountability. So it's not. There's a lot of sort of human nature. It says, well, wait a minute, I did my part, my project was green. I delivered this thing. The fact that I didn't get the outcome for the customer, it's not my fault. I was like, well, wait a minute, that's why we're here, right? How do you put the customer at everything, with the center of everything we do, right, and make sure that they are getting the outcome they need? If you do your little part building this widget or this feature and nobody uses it, what the hell was the point, right? And what I say to the team all day long is, you know, we have to focus on, you know, I forget exactly who said it, but it's basically fall in love with the problem, not the solution. And it's really easy to say, all right, I have a solution. I'm going to get building. I know how to build, and that's what I fall back on. And I build it and nobody uses it. We are much less likely to fall down on execution in terms of how we do the development or anything like that than we are to execute flawlessly against a solution that solves completely the wrong problem didn't need solving in the first place. So how do you get people thinking about what's that problem I'm trying to solve and how do I know when I've solved the problem? And that's hard because you got to spend the time doing discovery. You got to spend the time with the customers and make sure you understand what their problems are, not just the problems you think they are or the bankers think they are or anything else like that. Then you have to come up with a solution, then you have to deliver it, then you have to drive adoption and then you have to realize the business outcomes. It's harder. And there's a certain theme with a lot of people. It's like, boy, I don't want to do that. That sounds like work.

A (16:21)

Yeah, that's true. And I see it's like you have to wait, right, to get the outcome. There's all these lagging indicators. So everybody's like, well, I want to know now if I was successful so I can move on. Right. Instead of thinking in product terms, like project terms of, okay, I did it, let me just like kick it over and it's done now. So I see that friction happening as well.

D (16:41)

Yeah, that's fair. I do think there's probably a happy medium we have to get to, which is as much as we want to get away from deliverable based measures, there is a certain amount of that. Right? If you want to see this outcome by the end of next year, you have to work backwards from that.

A (16:57)

What kind of methods of reporting or, you know, looking at progress do you use to say, hey, here are the things that we're doing and this is how we're tying it back to outcome.

D (17:07)

You just try to strike this balance between doing everything top down and doing everything bottoms up. So then we asked everybody, okay, what are you working on? And how do you measure the progress? Just getting people used to that idea of those measures. And they came back with a set of krs for their objectives that they had, which was great. The problem is there were 341 of them. And I was like, well, wait a minute, like we can't be. And by the way, only, you know, less than half of them had targets unless that half of those were being measured. I was like, all right, you don't have 341. You have a lot less than that. If you took those 341, how many of them actually mapped up to those 11 objectives? We had about half. So what's the other half of the organization doing? So then we took another crank of it and that 341 came down to like 140, about 80% of which map to the top. So, okay, that's great. There's always going to be 20% of things that come up and life gets in the way and that sort of thing too. But then you look at all right, of all those things in there, how many, if we do them all, do we actually get the benefit that we expect from all these objectives? And the answer unfortunately was no. There's a lot of good stuff in there. Yeah, there are a lot of good ideas. Everybody's got a good idea. Right. We're long past the days of funding bad ideas. But it's how do you get the focus on those down to the handful of things that I refer to as the difference makers. If you get these things done, you make a substantial difference in the business outcomes that we have. So it is very much that it is that OKR framework, but it's getting it down to a handful of measures that really matter and clearing everything else out. So if you look at a lot of organizations, they get very focused on operational efficiency. Right? And okay, how do we do this faster? So I can reduce the number of operations people I have doing something or else like that. You can't lead with that. You lead with customer experience. How do I deliver a much better customer experience? And let's use the onboarding. If I can onboard a customer in 24 hours, they get a much better experience. And to do that, I have to do so much automation and process re engineering other things that you get the operational efficiency anyway. So don't measure 20 different things, measure the one in that case, cycle time of onboarding and everything else flows from there. So it is a handful of metrics that really make a difference. We have about 40. Right. Which is still a lot, but it's a hell of a lot better than 341. Right?

A (19:31)

Yeah, definitely progress there. And that's a wrap on today's episode. I hope you took away something useful. Whether you're rethinking how your team sets okrs, trying to shift from outputs to real outcomes, or just figuring out which handful of metrics actually move the business, if you want to hear the full conversations, check out episodes 216, 156 and 144. If you want to build stronger product management skills and learn practical approaches that you can use day to day, head over to Product Institute to learn more. And one more thing, for a productivity boost, I encourage you to try out Granola, a tool I use every day. It's an AI powered notepad for meetings that helps capture notes and decisions automatically. You can get 3 months free on any paid plan at Granola AI ProductInstitute. Thank you so much for listening to the Product Thinking podcast. Make sure you like and subscribe so you never miss an episode. We'll see you next time.