The OKR Podcast
The OKR Podcast

Episode 33 · 1 month ago

OKRs for Agile, Outcome-Focused Organizations


Jeff Gothelf, business agility and OKR framework expert, organizational designer, author and speaker, sits down with Deidre to share his unique approach to cultivating a product-focused mindset across large, complex enterprise organizations. Jeff uncovers how agile organizations that manage to outcomes are fundamentally in opposition to legacy, command and control leadership practices - and more importantly, how leaders can empower their people with the right framework for autonomy, discovery, and learning.

Jeff’s Recommended Reads:

  • Jeff - Blog
  • Sense and Respond - Jeff Gothelf & Josh Seiden
  • Continuing Discovery Habits - Theresa Torez
  • Lean UX - Jeff Gothelf & Josh Seiden

You're listening to the okay Our Podcast. We talk about the power of lateral alignment and outcome mindset and empowering teams to do their best work from anywhere. We also talk about operating as a digital company, which is crucial now Here journeys learnings and victories from our guest speakers and get expertise from our host to scale your leadership capacity and operate with high impact, trust and efficiency. Here's your host daydream pack nod Welcome to the okay Our podcast Today. My guest is Jeff got Health. He is the author of lean Ux and Sense and Respond. Anybody who makes products has heard of both of those books before. He's an expert on helping organizations adopted kaurs, adapt okay rs, and adopt more agile ways of working. It's a keynote speaker, a trainer, and a coach on okay ours on product management and organizational a Jelly. I'm very excited to at this conversation about okay R is with you, Jeff. We have a good set of topics lined up, in particular on how leaders get in their own way as they try to adopt okay ares and the organization. Let's start with maybe you tell us a little bit about the work you're doing with UM companies today in helping them adopt occres, kind of companies you're working with, what kind of teams and organizations are you working with? So generally speaking, I work with large organizations as they try to become more agile with a lower case A, so not not necessarily applying a specific process, but increasing the agility of the organization, improving their focus on the customer, and UM really starting to focus more on product thinking or a product centered approach to their to their work rather than sort of a delivery focused approach UM. In doing so, I help them figure out how to change their goal setting frameworks, which generally speaking means we end up and some version of objectives and key results, which is important to those pieces falling into place. And then subsequently I helped them a lot with things like product management and product discovery, which is the process of actually figuring out what we're going to build in order to achieve the behavior change that we're seeking with with key results. Work with large companies because it's it's it's big, and it's challenging, and it's and it's difficult and Frankly, I I like the impact. So if if we improve a situation in an organization, we're improving the situation for five thousand, fifteen fifty thousand people rather than a smaller a smaller audience. So typically it's going to be multinationals, a lot of legacy industries in most cases, and um big sort of hairy problems inside those big successful organizations were wondering why they even have to change in the first place. Yeah, yeah, yeah, As you know, we we do most of our work in large enterprise as well, similar demographics, and I think there's there's both the imperative that you change and evolve and to reflect what customers want from our organizations and what people who work in our organizations want from them as well. And I actually think there's never been a better time for organizations to think about clarity and a common language around what are we trying to achieve and how would we know what results are we trying to create and transfer ownership of that two teams in the organization, which is what I think the promise of maybe the most interesting promise of of okayres really is there's an appetite I think from teams and there's a need from leaders in the organization. It's a really good moment in time in history, I think, to be doing this kind of work with large enterprises. Yeah, the appetite from teams that I agree with, I mean, for the better part of the fifteen years I've worked on or with or coached or advised...

...or trained teams. When I'm talking about sort of product development teams, um, and all of them want that autonomy, they want that control, they want that empowerment to make decisions that are the closest to the work. The interesting part is that there are leaders who are willing to hand that over. They're not the majority, and at least in my experience, UM, And it's a terrifying prospect I think for those leaders because it fundamentally redefines what they do as leaders as well. And that and look for folks, nobody gets into leadership position in the first three years of the certainly not enterprise leadership in the first three years of their career. So these folks have been working for a long time years thirty years more with with a certain perspective of what it means to lead, and we're asking them to change pretty drastically now. And and that's that's not an easy request and it's not an easy change for a lot of folks to go through. A lot of times, those the leaders are senior leaders of a large span of the organization, but they're not the leader of that organization, and so they have this dual road where they may intellectually appreciate what they're trying to achieve and what the potential of distributed decision power is, but they're being asked to and their job requires them to operate in and I'll call it old school way where this sort of command control, read out, read up dynamic persists, right, And those those leaders, I think are have have the toughest spot right where they can lean in and see the potential, but they have to operate upward in an environment where, um, where not everybody has decided to travel the road yet. Right. My my co author Josh Sidon calls that grinding gears, because you've gotta have one gear sort of turning one way, and then you've got a bigger gear on on the outside of it turning the other way, and there's a real grinding there. And we see that all all the time, right, We see teams struggling or asking having that appetite to work differently, being trained to work differently, being asked to work differently. But then the demands on those teams, the incentives put on those teams are those command and control, those you know, predictable, Tell me what you're making, tell me when it's gonna be done, tell me what the r O I is, and you know, tell me when I can sell that type of thing. And and that that grinding of the gears creates a lot of friction, and frankly, it's a lot of the reason why a lot of these digital transformations, these agile transformations, of which okay, ours product management, product discovery, are all a part of struggle. They struggle because of that, the grinding of the gears. This this, I don't know, Maybe it's a lack of awareness, or it's a lack of a lack of of of um understanding of what it means to lead an organization that's managing two outcomes and an agile organization. Again, I every time I say agile lower case a right, an organization that that that that thrives in agility is a fundamentally different organization than a command and control organization. M yep, yep. Let's jump into and our topic today is to try and help those leaders who want to have more agile organization, faster and more innovation in that organization and want to shift to an outcome minded approach versus an activity centered approach to how they operate right and how they run. Let's jump into five areas where leaders trip themselves up right, where they get in their own way. Talk about what are the behaviors whether you know, maybe they have an intention to adopt more edgeways of working and use okay, ours and outcomes as their center that intention, but they're not recognizing or maybe don't appreciate the behaviors they continue to exhibit that that actually are their own roadblock to that agility um and into the velocity they want. So let's... through each of those five let's call hazard areas for leaders, and we're particularly trying to help them actually see their pattern and break their pattern or improve the pattern to better suit their aspirations for agility. Let's let's start with one that you and I think see all the time, we've chatted a bit about in the past, which is they maybe start with the premise of deep and go through some deep introspection like, oh yeah, this technique would help us the objectives and key results technique would help us put outcomes at the center, would help us move to something other than hierarchy and manager authority as the way of of operating. And so we're gonna do okay ours. They forget the why and they transition to just we're gonna do okay rs and that divorced from the why do it at all? Too? We're doing it and it's a process that that divorce creens. So ton of problems in dynamics. Tell us a little bit about what you see there, what your observations are, what's that, what's that misbehavior pattern look like the anti pattern. I'll start with the story. So I was recently working with a global healthcare organization, and I was working with the leadership team minus the CEO, so sort of CEO minus one. So it's the leadership team, some CC level, some sort of e v P, s VP folks. And they were doing okay ours as as you said, right doing, and we were working through it, and I was challenging them because the the the key results they kept coming up with were very task oriented. They were very output oriented, and they said, well, this is I know, we hear what you're saying, but this is what the CEO is demanding of us. And so I said, okay, well let me talk to him. And so he and I sat down and I said, look, this is what I'm saying. This is what I'm hearing right, this grinding of the gears that we just talked about. And I said, well, why did you bring in so let's talk about let's talk about this. Why did you bring in okay R's in the first place? And I commend his transparency and his honesty, and he said, I don't know, right, And I think that that's true in a lot of cases. We've seen it with the Agile conversation for decades now, and I think we're seeing it with the okay rs conversation. There's a bit of cargo culting here, right, Well, they're doing it, so we're going to do it, right, I see them. The competition is doing it, so we have I read in a in an article in HBr that this is the thing. So now I have to do it without really recognizing what why we're doing it and what it actually means. Right, It's it's this application. It's funny because there the fundamental difference that teams need to grasp for okay rs to be successful is the difference between managing to output and managing the outcomes. And if you if you kind of take that up a level, sort of as a metal description level, the application of okay rs in this case, right, doing okay rs is an output. We are doing okay rs okay terrific. How has the b if you're changed as a result of that, Well, that's not my that's not my job, or it's not that's that's not why I brought it in. I brought in to do this right. And so when they forget the why, then the what okay, we've applied this goal setting framework is the definition of success. Right. And then when it as it starts to filter down to the teams, the teams are grateful for this new way of working because it gives them that empowerment and that autonomy that they've been seeking. But top down the request to remain the same because there's a lack of understanding, and so they either forget the why or they never actually understood the why, and so the the there's a push top down to to make this happen, but a lack of understanding of how to support it, of what it means for you as a leader around it. And I've seen that. So I saw that with this particular leader, and I see that consistently, honestly, like I think this looks I'm not speaking in absolutes. There are different levels of understanding, but there is there is a there's a really deep struggle at the at the highest levels of leader ship to let go of command and control two, especially with the companies...

...who build digital products and services. Right, So let's talk about that for a second as the context. Because there's so much uncertainty in digital products and services, there's so much risk. The pace of change is enormous, right, Um. And so this this idea that some one person can predict exactly what everybody needs to do and when it needs to get done, and what it needs to look like and what the r o I of that is going to be is absolutely ridiculous these days. And yet that's the background for these folks. That's how they've been trained, that's how they've been brought up, that's how they've they've been educated. Um. And so at the very least, at the very least, we need to get this level of leadership educated into the why this is different and what this means for you, and then then they can make an educated decision about what and they actually want to do this. M h yeah. Yeah. One of the tactics I love in early in the conversation with leaders who think, let's do this is just straight up so what would the objectives and results were trying to achieve from objectives and key results be like, let's let's clarify our intention, like actually use the framework to talk about why we'd use the framework and it's um. Among other things, it helps them see feel the difference between outputting activity and results and value created. Uh. But it it also sheds light on Okay, we don't really have a lot of clarity on what the objectives are, right, and we hadn't thought about what the impact or value created for the organization might actually be. It's pretty cathartic conversation though. You can actually start to then id eight on what it might be UM and do what the technique promises, right, actually get the clarity on why we do anything at all? Right, Yeah, and look, I think I think it's extremely powerful actually, because UM. The key question I always ask folks, regardless of what level we're training, okay, are so, whether it's like product level okay RS or organization level okay, ours externally facing, internally facing, whatever is. Once we've identified the target audience for a particular initiative, right, for a particular objective, Um, then the question I always ask them, Okay, what will those folks be doing differently if we succeed? Right? And um, and and that that starts to trigger the realization that starts to trigger the oh right, this is this is different And here's why it's different, right, Because I'm not that The question isn't what will we then have built, right, what will we have launched to market? Or what new process will we have implemented in the company. It's what will those people be doing differently than they're doing today? And generally speaking, most folks, particularly even in leaderer positions, aren't thinking like that. There's still this sort of production manufacturing mentality because it's so easy, right, it's so easy to measure, right, whether you made something or not. It's binary, right, you did it, you shipped it, or you didn't. Whereas this kind of behavior change it's it's fuzzier, it's messier, it's not as binary. Yeah, particularly when you you're making a transition from one that is very discreet, very obvious, and very tangible to another that you don't yet have any fluency with. Right on the other side of that, and with fluency, it's um, it's an easier move, but it's the non obvious before you start, right and maybe even not obvious in the first quarter that you actually do it as well. Let's talk about another roadblock that gets in the way of leaders, and it's um. There's no wants to it, like to everything,...

...but there's both sort of maybe personal arrogance and maybe there's a little institutional hubris um that impede the change that they when they do have intention and they do have clarity, it impedes how quickly they might actually see that change. Yeah. So look, you and I both work with large companies. Large companies are are large and they're successful, right, They've they've done something right because they're large, and so there is that there is that arrogance that says, look, we're big, we're successful, we we did this, we know how to do this, we're good at this. We understand the market, we understand the need. We've been here for a while and and we get it. First of all, why do we have to change in the first place? And and secondarily, we've gotten this far on you know, the intuition, the experience, the expertise of senior leadership. Why does that have to change? And look, that's a fair question, right, But I think and so the answer the answers that I give in these situations is, first of all, what got you here isn't necessarily going to get you there. So congratulations on being successful and and a bit lucky to get this far and too and to be this big that is not going to get you to the next you know, the next ten hundred years. Again, the pace of change. We build businesses on top of software today, that's that's the nature of business. You're you're in the software business, regardless of what you do. Right, the pace of change in technology is ridiculous these days. Consumer consumption behaviors and frankly, as as Rita McGrath talks about, the barriers to entry are are ridiculously low. You know, ten years ago, I remember living next door to a guy years and years years ago in Virginia and he was starting a bank, and I was like, how are you starting that? Yeah? I was like like what are you building? Like are you building a building? Like what? Like? I don't understand how you're starting a bank? And it was this was ten years might Haven fifteen years ago, even like it was, it was it was an arduous process where he literally was working for years to do this. Today, right, there are entrepreneurs who can launch banks that compete and that pull customers away from the Bank of America as the Wells Fargoes, the capital Ones of the world in in months, in months, they can launch these financial institutions that live entirely on top of software. Right. And so this arrogance that says we're big, we're smart, we know the market. What got us here will get us there is terribly risky. And and the thing that I try to get across is you don't need to take that risk. Now, it's gonna hurt your ego a little bit, and I'm sorry about that, but if you want this business to survive and thrive and grow, then that ego might have to take a hit, but you don't. You don't have to take this risk. What I noticed is uh, where ambition exceeds arrogance, they're very mobile, right, Like the innovate iterate change is quite high. But it's the but ambition is higher than the institutional arrogance. Where the reverse is true, where there's complacency that matches the institutional arrogance. That the challenge of doing anything different is far, far, far far greater. And in big enterprises you can have like some of every kind. Like you have a leader on this side of the business who's got huge ambition and low ego, high appetite, right, and that's that's the business unit that's blown it out, and that's innovating the same company. You have another business unit where uh, this prison has been running it for fifteen years and grew up there and it is deeply committed to status quo uh and almost an immovable object by comparison into the...

...higher ambition lower lower hubrists part of the organ even within one entity. Right, It's interesting. So one of I had this experience a few years ago where we did six months of coaching with one of the big banks in the U s six months of executive coaching without the big banks in the US, and this was largely focused around agile and and sort of um product management, but inevitably managing the outcomes was part of it. I'm not sure we were using the phrase okay rs back then. Nevertheless, um uh this, And there was the president and it was it was a fairly well known fact that the president was going to step down shortly. And there was the air apparent, the person who everybody sort of assumed was the next in line as soon as the president stepped down. And this individual had been working at the bank for a couple of decades years something like that, and every single move that this individual had made was for that corner office, for that position, for that title. And so the concepts that we were introducing were introducing risk to that ascension plan, to that succession plan, to that to that goal that this individual had planned out over the course of more than twenty years. And so there's a lot there's a lot of that ambition that kind of gets in the way of this with there's a lot of lip service. Yes, yes, yes, this sounds great, Yeah, we'll definitely do this, and then it's like, but nothing's not you're not moving the goal post on me. Now, I'm almost there, right, and I've seen. I've seen that several times. That was just one example, but it's it's again, it's there. There needs to be a recognition that says, actually, if you embrace this, then once you do sort of ascend to that position, you can really, as you said, blow it out and really start to take this to your legacy. It will have impact. Yes, exactly. Let's talk about another hazard along the way, which is, um, we're gonna do okres. That's new, but also we're going to do more of the same. So the behaviors around deadlines and milestones, Well, the launcho cares, but we're gonna spend all our time talking about activity delivery and milestone delivery. And in fact, that's how we're going to organize with the Vineyer of okayre is an outcome mindset over it you particularly with your product management and the experience and the exposure you have and the impact you have in that space. Teas that apart for us, what in particular, what are the legacy behaviors? How do those need to change for teams to have their biggest outcomes and impact Versus the feature factory um that anyone can build just use his money but without generating value. I'm two lines around deadlines, the the overwhelming. So the first, the first mind is, in my opinion, the overwhelming majority of deadlines are artificial just uses motivational techniques and generally not particularly helpful in those cases, um and the kind of an antiquated tool. Um. The other is you work in a in a business that has actual seasonal deadlines. You're in retail and you've got the holiday season. I had a client earlier this year who is in the student loans business. They've got a student as a student loans season, it's usually summer, and like, no one's getting a student loan in December, right, They're getting them in in May, June, July, for the fall, that type of thing. So in those cases, you've got a legitimate case for a deadline, like we've got to get this stuff up and running so that we can support our season. So that makes that's not an artificial deadline, that's just a realistic component or constraint of your business. Here's the problem. The problem is this, as...

...soon as you fix time and you fix scope, right, I need you to deliver this by this date. Okay, let's go out. The window. Agility goes out the window. Product discovery goes out the window, and it's just sort of a mad dash to to plan backwards. We've all we've all been there, anybody who's done any kind of software developments. We started the deadline, work our way backwards right to figure out what we need to do, and we try to get it into there's no room for variability, there's no room for learning, there's no room for course correction um and so we're taking and we're taking tremendous risk in doing so. Again, this we're saying in the future, we're going we're going to deliver this that's already risky enough as it is. And when we deliver this, this is what people will do with it. And this is how much money will make of it out of it, which is again tremendously risky in all of these cases. And so if if you don't you know, if you're going to fix the deadline, then the scope has to be variable, right, so for Examp. But if we've got we've got a retail deadline, terriffic. We know we've got code freeze on October one, right for the for the rest of the rest of the year, terrific. We're going to do our best to build the best possible things we can and learn the most by October one, at which point we're going to freeze code. Yes we've got specific goals, specific targets, et cetera, but we're going to We're gonna adjust the scope based on what we're learning along the way. The other option, of course, is is you can try to fix scope. But again, as soon as you fix scope, you really I mean, and then, and then and then let the day to be the variable right in that. But the risk there is that you're tying your team's hands to deliver, to deliver things that they may or may not need to. Right as we develop software, particularly as we developed products, we learn things about that product, about the market. Things happen in the world, The competition launches new too, new new products, new services. Maybe there's a pandemic. I don't know. Maybe there's a war that starts in Europe. You don't know these things that have happened. So anytime you fix anything, anything related to scope, you run the risk of building and launching things that are that are inevitably going to be irrelevant. I mean again. Another example, perfect example is in UM in October of two thousand eight, So a hundred and fifty seven thousand years ago is what it feels at this point, right. But October of two thousand eight I got a job in New York City as the director of User Experience for the Ladders. Now, the Ladders was a job board for people who made a hundred thousand dollars or more. October of two thousand eight was a bad month for the US economy. Within three weeks of of taking my new my new job, which I was very happy about, is moving back to New York City, um Lehman Brothers melted down. Yeah, and the financial crisis precipitated from from that. Now, our sites like a dating site. You need you need job seekers and you need employers. You need the two sides. And we had a fairly balanced ecosystem. And then overnight, literally overnight, our system became completely unbalanced. Tons of job seekers, no jobs. Right now, we had a nine month road map, fixed scope, fixed time r o eyes plan heavily negotiated right and and with deadlines and milestone deliveries for all of this stuff. And we had a real choice. The real choice and organization was to sort of stick your head in the sand and say follow the plan right because we so we we spent so much time setting it up and we signed up for it. Or it's to recognize what's going on around you accept those learnings and adjust course from there. And I think that when we rigorously apply deadlines when we don't need to, or milestones that that particularly dictate fixed scope, we are again taking tremendous risk and building things that are going to be outdated or unnecessary or relevant by the time we shipped them. Yeah, I think the the gift of the last three years and lots of hard things has happened the last three years, but the gift... actually the world has just told you twelve times that about every ninety days things really change. Yeah, it's told us that quarter after quarter after quarter for three solid years. If you miss the lesson, I don't know what let you need to learn it. It's it's been it's been repeated every quarter since the first quarter of I think for digital transformation and organizations in transformation, one of the most important points is you don't know what you don't know. So if you're a car company trying to become a software company, you don't know what it means to be a software company yet, and so the iterate and learn, iterate and learn. The essential aspect of learning cannot be lost or squashed in the process, right, And if you are a car company trying to be a software company, probably been a car company for a really long time, and the machine works the same way over and over and over again. Not where you are. If you're trying to enter a new segment or transform into and operating an entirely digital way from an entirely analog way, I think you're When you talk about the risk of building something irrelevant in transformation situations, at risk is multiplied many times over by the elimination of learning, and that only comes with faster iteration. So new dynamic another one that comes up, and we talked about how do we how might we enable leaders to prepare and anticipate? In this one's I think a bit maybe the hardest of the ones we've talked about where just mere consciousness can help you. This one there's more enablement required, which is, uh, you do okay, as you do them, well, you remember your why, you demonstrate the behaviors that you want other people to to show up with your lot Okay, rs and teams have the power, they have the autonomy, they set their okay ours, but they're not really prepared to actually then own the decision making that comes from well, if those are the outcomes, now we need to go plan and execute there. They're less prepared for operating in or with that kind of autonomy locally. So what the behavior see and most importantly, what what guidance can you offer people and leaders on how to prepare their organization and their teams to be super successful with local autonomy. Yeah, it's it's it's fascinating because teams want it and and and managers and leaders say, okay, there it is. You have it right, your autonomy, your empowerment and and to your point, they've done a good job. They've written good okay our statements, they've set the goals, they're tied to strategy, et cetera. Everything everything is going great. And the teams and then the teams I see this literally on a weekly basis. They ask like, okay, so what should we work on. You're autonomous, you decide right? And they said, great, how do we decide right? And that's a really interesting question and it's super important for leaders to understand this that if you're going to if you're going to implement objectives and here results, and you're going to do it well, and eventually you will. It's not that hard. Eventually you will. You will do a good job of writing these goal statements. You have to be prepared for that. Now, what that next step? Right, If you do not give your teams a decision making framework, a a training, or or some sort of sense of how they're supposed to go about deciding what to work on next, they will simply sit around and wait for you to tell them what to do. So, regardless of your efforts to give them that autonomy and empowerment, and regardless of the collective efforts to write really great objectives and here results, right, we're still going to be back in that old way of working of you telling them what to do and so, what these teams need and it's it's and I love that you brought up learning...

...before, because what they need is ways of working processes, methods that allow them to learn quickly. Now we're talking about product discovery, we're talking about design thinking, and we're talking about lean u X, all variations on the similar theme, which is these teams need to understand what problem they're solving, articulate the assumptions around those problems, define some potential solution hypotheses, and then design experiments to learn whether or not those ideas will actually deliver the behavior change that they've written into their goal statements, into their into their key results or not, and then adjust course based on that. So we're combining lean startup agile design thinking, lean u X product discovery. But teams generally speaking don't have don't know how to do that. Number one. The other pattern on antipatic scene is teams that do know how to do that, and a lot of organizations aren't allowed to really deploy that learning because learning work is work, right, which which sounds ridiculous, but so many organizations forget that. They just sort of expected to magically happen outside of the sort of the engineering backlog, right, and then sort of deliver that insight the learning work is work, and if you're going to do that work, it means you're not doing something else. And they're like, well, our our production capacity, our velocity will drop down, right, And so they're not allowed to do a whole lot of those learning work that learning work, And then the third anti pattern. So they know how to do it, they're allowed to do it. They developed the learning, but the learning contradicts the plan, and that course correction becomes really difficult, Like, but they're not allowed to actually make the course correction. And so so the takeaway here is that once you've gotten your okay ours down and they're great, you need to invest in training your teams in product discovery, in different ways of doing product discovery. You need to allow them to use those techniques. And most importantly, the autonomy and the empowerment of choosing what to work on is frankly, it's not that hard when you compare it to the autonomy and empowerment necessary to actually change course and decide not to work on something. That's when people get truly paranoid, like wait, wait, wait, we're not going to work on that, right, but we said we would, Yes, we said we would, but our experimentation has revealed that this is not going to deliver the results that we're looking for, and so we're going to adjust course. That's the hardest part. So enabling that, allowing that, being comfortable with that um and frankly, I'll just add one one time, a bit here. This is where the the sort of the core mechanics of scrum or agile really come into play really, really nicely, because they give your teams these really short time boxes, and at the end of those time boxes, they've got to make a decision do we persevere, do we pivot or do we kill based on what we've learned, And if they decide to pivot or to kill an idea, the level of investment is small. It's two weeks, it's four weeks. It's not six months or twelve months that hurts, right, a four week or two week investment, Okay, Like we've lost a couple of sprints on this, No big deal. And so that's the key to moving past this. Now what Once the okay ours are good? It feels like trust is an element to white teams get too good okay ours, but don't quickly get to the fruition of the learning and the decisions and the iterations that they can come from that. You have to believe that management really means it when they say it um and I see that as a slow process in in some organizations, not not all by long shot, but in somewhere like they're just saying there right there, they're going to take the rug out from a radar feet soon enough, um, and they're watching what leaders do and say. Leaders get it right by saying and doing the right things in the first month, and then they blow it by three months later, four months later, defaulting back to be a you or forgetting that people are still looking for this signal.

Let's change topics to planning season, which is upon us as we speak ulmilst everywhere where. We're going to decide in advance how much money you have, and then later you're gonna tell us the strategy and what you're going to achieve with the money. Always felt weird to me, But tell us how planning season and the road mapping that goes along with that. What are the hazards in those behaviors and those institutional norms that hold back organizations and product and innovation organizations in particular from achieving our biggest impact creating the biggest value. Yeah, so look, the fact that we're calling it a season gives you a hint. Right, there's a significant level of investment here of time, people, negotiations, bargaining, etcetera. To get to some sort of a plan, some sort of a commitment, some sort of of a direction for the next twelve months. And so it's not it's totally understandable that the folks who did that work in that negotiation and who suffered through all those PowerPoint decks are loath to change the plan when new information comes to light. And so the reality is is that this this concept of planning season has to start to sort of we have to produce the scope of that and start to do it more frequently, right, instead of doing it once a year for two and a half months or whatever it is, right quarterly for example. Right? Why quarterly you set it before? Right, because it's an opportunity to learn four times a year, right, whether we've made the right strategic decisions for the year, rather than once and we're gonna hopefully we're gonna hit that, right, it gives us four times more opportunities to actually learn whether or not we we've made some good decisions. So deciding on strategy, sure, deciding on sort of high level objectives and key results to determine whether we're achieving the strategy terrific. Right, But let's check in on a much more regular basis to see a how we're tracking towards our key results and b what have we learned along the way from that discovery work that we've been talking about that confirms and validates or challenges the strategic directions that we have that we've chosen. You know, my my favorite article on strategy right and sort of planning strategic planning is Roger Martin's The Big Lie Strategic Planning from HBr from two thousand fourteen. At this point where he talks about, really this is the two key questions are where will you play? And how will you win? He talks about how how strategy is a hypothesis, right, it's your best guess about where you should move forward and if you can identify how you'll win and how you'll measure whether you'll win. Basically objectives and key results, he just didn't call them that right at the time of the time of that writing. Um, then you've you've got a clear north start, like we're trying to increase market share in the Asian market, whatever it is, right, something along those lines, and you know, and then your teams can hypothesize about how we're going to get there, right, and as they start to validate or invalidate those hypothesis first of all, that they'll find a better direction to get there, or they might come back and say that our product is really going to struggle in Asia for whatever reasons. Right, it's just not like we really should reconsider whether this is where we want to spend the rest of as we move forward, because the feedback that we're getting from the market is that there is tremendous resistance to the way that that we're offering this particular service in the market place. And here's why. And to me, that's that's infinitely more valuable. Like I would rather spend three months testing and experimenting and validating and invalidating the strategy than negotiating it, because the negotiation is it's, well, I can predict the future better than you. Okay, That's that's what it comes down to. And then what it comes down to do his job titles and...

...and and you know, and and pay grades and that type of thing, and so it really it really is is like, hey, let's do this more frequently. Let's talk about our strategy, let's set high level okay rs, and then let's let's adjust them based on what we're learning along the way. It's the very definition of agility, isn't it It is? It really is? Yeah, just in course based on evidence period. Yep, yep, alright, perfect, ending. Thank you Jeff very much for sharing your experience in your wisdom as anyone listening and you and I know we can talk about this all day easily, absolutely deep geekiness about it. But I very much appreciate in particular the wisdom you bring in product and technology organizations where you have perhaps deeper ectoportiase than than it's certainly anyone I know, which is a decent set of people. Um, So I very much appreciate your bringing that forward, particularly great advice on how to enable technology product teams in particular after they said, okay, like so now what that was incredible wisdom. If you'd share a couple options for where to read more, assuming sense and respond is a really good source there, but where to read more people can bring that into the practice that they adopt would be really helpful. Let's point them to resources, and of course you are one of the best resources as they try to do that. Yeah. So, I mean I write about this weekly on my blog at Jeffcott health dot com. So that's a great place to go Um a big fan of Tersa torress work, so her latest book, Continues Discovery Habits, is basically, uh, you know, a how to guide for product discovery, and that type of works sense and respond, as you mentioned, is a great place to go. Um. Those those are great places to start. And you know plugly Neux as well, always a regular favorite with the product discovery crowd. But those are those are fantastic places to start, and there's lots more, lots more directions to go from there. Terrific. Great, Thank you very much, Jeff, Thanks for being our guest today, My pleasure. Thanks so much for having me. You've been listening to the Okay our podcast. Subscribe in your favorite player so you never miss a moment. Thanks for listening. Until next time. M.

In-Stream Audio Search


Search across all episodes within this podcast

Episodes (33)