Tim Herbig - Stop Making Alibi Progress & Start Making REAL Progress (with Tim Herbig, Product Management Coach & Author of “Real Progress“)

The one thing I encourage people to think about, whatever it is, whatever, if it's strategy, OKRs or discovery, but whatever your way of working is, what is it supposed to do for you? Like, what should be changed through it? And whatever that is, what you define as the success, achieving that that could be your real progress. And I think the difference is, you follow the playbook where it's not connected to what you want to achieve with this way of working compared to, I know how I want my organization to change, and I adapt the practice in a way that it supports that. So that's how I would describe it, like that real progress means of adjusting a way of working so that it fits your context and helps you achieve whatever goal you have at a given time. Yeah, it kind of reminds me of a point that I've made in the past when talking to teams about their own processes. It's like, there's nothing wrong with, like some people would just like, they just hate any mention of the word process. From my perspective and how I've tried to frame it is like, there's always a de facto process when you build things, right? And obviously you should be as intentional with that as you can. But it's more about like making sure that the process serves you versus you serving the process. Like if you're just doing it, as you say, as a checkbox exercise, or because a book said to do it, then maybe it's the right thing. Maybe it's not, but you should be intentional. You shouldn't just be doing it because someone else said to do it or because you used to do it and no one ever changed it. Like I've had enough people that I've worked with or clients that I've worked with that are like, oh yeah, we've just been having this meeting for years and no one even knows why we go into it anymore, but we just keep having it because it was on the calendar. It's a recurring thing. The person who set it up, they've left by now, but we still keep doing it anyway. No one gets any value out of it. But like, I'm going to go out on a limb and say, you've probably seen a bunch of that sort of stuff going on as well when you're out and about. Yeah, a hundred percent. I mean, whether it's adopting a framework, templates for other people, and suddenly you see how frameworks are being used in a different way and you are like, that's not what this was ever meant to create. Like nowhere near like cramming font size eights on a canvas and replace, like using that to replace a 40 page PRD. Like that's not the idea of this canvas. And I think it's just funny to see how, like, you can't swap the tactics, but if the fundamental approach of, we want long requirements documents, just use that as an example, is still there. Or leadership wants outputs, not outcomes. The framework, the method won't save you. Like OKRs won't save you. They won't make you do anything different. And I think it's, as you said, I think there's no wrong method or wrong process at all. It's just I love that you said the intentionality, the awareness, like, okay, are we making this decision based on that? Are we all agreeing like that is what we're doing? Okay, then let's do it together. But let's not pretend it's like we've validated this thing or something. Yeah, well, you know, it's always interesting seeing what people make out of these things as well. And certainly you've got some war stories that we could probably share after this. But let's stay on topic and talk then about, like, imagine that you've got a team or a company, but let's say a team that's very much sort of stuck in this alibi progress to start with, doing some of the things that you've described, kind of doubling down on the practices rather than actually adapting them or worrying about the actual progress that they're really trying to make. So you've got those people kind of stuck in the alibi world. And now you've got those people wanting to move over into the real progress world and actually start to make a difference. Now, there are presumably, and I've read the book, so I have a basic idea, but there are presumably some core ideas or principles that you'd expect teams to follow if they were going to try and make that hop. And that does then prompt me to have to ask... And that does then prompt me to have to ask, is there like a checklist that they can follow to do this thing, or is that all too meticulous and template-y? I don't know. Some people might perceive it that way, but what I got as a feedback from readers, often that I have this section that I call the quality checks in the book, which are meant to be a bit of like diagnostic questions. And by no means do we have to use all of them, but what I've gotten from people is that these questions might make them aware of the issues they have with the sort of practice. I mean, one of the most common things that I hear is OKRs don't work for us, for example. It's like, okay, what does that mean? Like, what does not work for us mean? It's like, yeah, people stop looking at it. It's like, okay, then you look at the, then you can use these kind of reflective questions, just like you and I would do with clients. Like, what is going on? Like, what is the issue? And that's what I'm trying to do with the book. It's like, I think the value of some of these practices I talk about depends on a certain set of attributes and meeting some of these attributes can influence how valuable the practice is for a team or not. And I think what I oftentimes see is that people look at these attributes and then they can suddenly see, oh, that's why it's not working. It's not working because none of them are leading indicators or our strategy is not working because we can't connect it to company strategy. And then you can look at the actual issue. And so I would say, it's, it's, I think it's not a checklist. What I would describe it is, I think the quality checks might allow you to spot the reason why you feel stuck with the practice. And then the book offers you a set of potential practices you could utilize to, to, to cure that symptom, so to speak. And then move on. But it's interesting what you say around kind of asking the questions. And I guess maybe to some extent, that's a big part of the problem, right? Is that people don't always feel comfortable or they're not allowed or they never think to ask the questions in the first place. So in a situation where they don't really know what's working or not or what's not working other than, you know, obviously, yeah, sure. There's stuff being delivered or there's stuff not being delivered and they certainly know that, but they don't necessarily go back and look at the, you know, the constituent parts that, that led up to that. So is part of the purpose of your book then almost like a call to action to say, look, at the very least, go and look at what you're doing and try and actually identify any, any sort of roadblocks or blockers. Do you think that even if people just did that, that that would be a start? I think it definitely would be a start. And I mean, my hope would be that some of the stuff, I mean, I would say that most of the stuff that I point out in the book, like none of that is by any means a new invention. I think what I found very often is like to, to, to, to ask a genuinely naive question to people, like genuinely not to provoke it, just to really understand, what, what is this? And then to say like, look, there are these fantastic things out there that you could utilize to, to fix that. Like my favorite example is always the, the sphere of influence idea that I call out in the OKRs chapter. It's like everyone for ages, for ages, but few people seem to connect it to the problems they might be having with something like OKRs or metrics in general. And for many teams I get to meet, it's like a light bulb moment. It's like, oh, my OKRs don't work because I can't influence them. And if you say that, it makes you feel borderline stupid because it's like so obvious. It sounds so obvious, but it's not, it's, it's not, it's, it's, it's just not. Because if you follow the outcomes of our output idea a bit too pragmatic, too dogmatically, you, you, you consider that the main quality criteria compared to, can you influence it? And that, that makes you blind for these other options. No, absolutely. And there's obviously also an argument that OKRs, you know, back from the Google days and stuff that OKRs worked because of the culture and the kind of how they measured success in the first place rather than just trying to retrofit them onto a company that just doesn't measure things at all like that. So like you sit in there and we've all seen them like the OKRs and there's 150 of them and they're all kind of output based anyway. So like per person and per team and they're different between teams and the key results are just this thing was delivered or that thing was delivered. And like, you know, you talked about Jeff Gothelf earlier, obviously, and Christina, like they've both obviously done tremendous work in this area. They've both passionately talked about like the, the, what a good OKR or a bad OKR looks like and you know, like what a good organization that's using them would look like as well. And some of the kind of OKR crimes out there. And again, maybe we can talk about those in a bit. But I do think that when you're talking about real progress, you're talking about, I think two core ideas. You're talking about what is it, value over correctness? So, you know, making sure that the practice, you know, we talked about it already, the practice delivers in the context that you're in rather than some idealistic version. You know, not just trying to be right for the sake of being right and also integration over isolation. So this idea that, you know, you're doing a bunch of things that kind of support each other versus just a bunch of disconnected things that, you know, are going off in different directions. Do you feel that, that those are both kind of, like that you have to do, get both of those right? Can you start with one? Can you start with the other? Like, can you start to adjust some of the practices and then integrate them later or is it more important to integrate them first and then fix for your context? Like how does that work from a kind of a, again, I don't want to get too dogmatic about it, but like when you're, when you're looking at that as an approach, like what is it that you'd kind of look at and say, if they don't have any of these things, this is where we start. Yeah. My favorite starting point, and I think that the, the quote-unquote problem is that, I mean, at the same question I wrote the book, like what's the main angle? Is the main angle the, this contextual improvement of the practices or is it the connection between them? And I went for both. In the end, of course, you have much more weight on the, the contextual practices than the connection in the book. My favorite, I think the, the easiest starting point, the easiest starting point is, is an idea that I describe as, uh, like treating your way of working like a product, like looking at something, one thing that you're doing, whether it's a meeting you described or a certain adoption of a new framework, workout or product, whatever. And like, okay, why are we doing this? Like, what do we even want to get out of that? We want to transform the company. We want to have a product operating model. Okay, cool. But how does that look like? Like, what does it mean? How, when is this successful? And that honestly is oftentimes the easiest start because you realize oftentimes, or companies realize how unclear that is. It might be clear in the head of one leader. It's not clear to anyone else. And what I think what this brings to the table is that you then can reflect on this way of working publicly and like, look, we wanted to achieve this by working this way, but we don't. So we have to change it because it's like, like you could change a product. And I think that is oftentimes the, just acknowledging that can get you so much more buy-in from people and like realizing, okay, it's not just the one-way street playbook someone's implementing, but like, okay, we're actually trying to adapt that. And I think if you, if you, if you set that foundationally, then you have a, should have a much easier time of going to the individual practices and improving them. Well, no product book is complete without some kind of canvas or template or framework. And you've got, you've got a wheel. So slipping directly onto Petra's territory, you talked about Petra a bit earlier, but obviously she's got the PM wheel. You've got the progress wheel, which is detailed in the book and seems to aim to fulfill kind of three interconnected or supporting purposes. Is it reducing uncertainty with evidence, saying yes or no, and measuring the progress. But within that, there's loads of inner boxes and arrows and miniature wheels, all of which kind of interlink and kind of go back on each other. So like that will make, I've looked at it, it all makes sense to me, but at a high level, how does the progress wheel help me do all of the things that we're talking about with regards to, you know, evidence, saying yes or no, measurement in ways that I couldn't do before? Yeah. The idea I would say is, it goes back to this point I made earlier. I think, uh, this idea of that 50% of your OKR issues are not OKR issues. They might be rooted in whether it's culture, as you said, or something else. And So I think the more decisive you are in your strategy, your product strategy, again, you could enforce the yes or the no. Yeah, for the small amount of time before it ends up getting changed again. But I know what you mean. And for me, I also think it's important to kind of come up with scenarios as well. Like, you know, what's going to happen if we do this? What's going to happen if we do this? What's going to happen if we do this? Now, this is the one that we recommend, but like, you know, these are the other alternative futures that you could go after. So yeah, it's definitely an interesting kind of this idea of like trying to almost force strategic thinking, which in a way sounds kind of almost arrogant in a way, like that these kind of clever product managers are going to come in and somehow change the mindset or the thinking or, you know, make a strategy come from nowhere from where there wasn't one in the first place. And I guess there's that kind of risk as well, that the product people aren't seen as this kind of, you know, wannabe strategists that have kind of maybe, you know, operating in a slight bubble versus actually, you know, kind of getting to get in with the program and like you say, sort of love it, leave it or change it. But it does feel to me that that is the risk of trying to be strategic when maybe those above and around you, maybe you don't feel that they are being that, that maybe you are starting to sound a little bit like, you know, you're the kind of the arrogant, Oh, Hey, look how clever I am. Like, is there a risk of that? I think there is. If you're trying to take yourself and that too serious, I think there's the, I once read this, this great idea, like be sincere, be sincere, but not serious. So I think if you take this, I think this goes a bit into the uh plays into that topic of like how dogmatic are you about this work working? And I think I love that you mentioned, like, it's more, I think it's more about strategic thinking than the strategy. And I think by trying to always come up with the strategy, you might get bored faces and people feel like you're lecturing them compared to, well, one of the essentials of, of strategic thinking, again, I could just be, Hey, can we just be more decisive in a bit and provoking that might just be enough to give you again, what you might want from strategy without going through the whole, the whole process and, and, and Oversizing it too much. No, absolutely. Yeah. Right size and move forward. But talk about then OKRs, which is another element of the wheel. You talked about it and you touched on it earlier as well, the importance of spheres of influence and kind of working on what you can influence versus stuff that you could just contribute to. So I think you talk about kind of areas of contribution and spheres of influence and zones of control. Now, obviously, yeah, we've touched a bunch of times already about some of the problems with OKRs, but like, what do you see as being like the big problems with teams and their OKRs in the kind of the context of that model of like people operating in those different zones or spheres? I think the, the biggest pattern that I'm seeing is that you have this top-down, bottom-up conflict, like so many things. It's like management or leadership wants to measure the team against metrics that matter to them, which is ARR, EBITDA, whatever it is, which is from a product team's perspective, really just something they can contribute to because it depends on a gazillion factors, internal teams, other teams, market conditions, etc. So it, it doesn't really work, right? They might use the, they might attach that metric to the team, but none of, nothing the team does can be really connected to moving that metric and then they are labeled as, as unsuccessful. Compared to the team who, who might see, okay, I know what I can influence. I know what I can, what kind of customer behavior I can influence. I think that's important to acknowledge. You can only influence customer behavior. You can't control it, even though some of us might wish they could. But then the, the, the task on the team is, okay, if I know that, what I can influence, how do I prove or at least point out to the company leadership how it's contributing to those metrics they care about? But there has to be this agreement on this handover moment of like the company saying, we want you to focus on this company metric and the product, like, please figure out the best lever, the best leverage point you have to improve. And the team needs to say, we believe this is the best leverage influenceable thing we have based on that kind of evidence. And here's how we think it contributes to the company goal. And then there has to be this agreement of this neutral zone, so to speak. And I would say that's, I'll say that's the most common issue for, again, whether it's OKRs or not, any kind of team-based metrics, measures of success, the lack of influenceability of the metric and trying to move a metric that is so far out of reach. Is there though, I mean, you talked about trying to connect the two, but is there a risk that people almost start trying to almost locally optimize for things that maybe aren't really that important just because they are within their realm of control? Like whether, whether or not they try to somehow connect that, like somehow, sometimes those can be quite difficult to connect. So is it always possible or do you think that sometimes it makes sense to locally optimize and, and, and hope? Like how could you try and bridge that gap so that you're not, you know, you're talking about making real progress, right? So if you're kind of just controlling the things that are within your direct zone of control, sometimes it might be a bit of a leap. And, you know, this is, you know, maybe slight tangent, but something that you see a lot with, for example, very sales-driven products where you're sitting there saying, well, you know, the product team can do all of these things to drive up usage and quality and, you know, functionality, etc. But the sales teams still have to go out and sell it. And if they don't, then, you know, it doesn't really matter what the product team did. Now that's obviously a bit of an us and them type of mentality. It's not quite that simple, but there is some, there's certainly something to the fact that, you know, like the product team can't always succeed on their own. And, yeah, is there some maybe chance of like locally optimizing when actually you should be trying to, you know, almost, almost force your way into being able to influence bigger things? I think the risk is certainly there. And I think I would say from a, from what I've heard from teams, I think it's just like you said before, it's like the, the topic of intentionality is, am I, like, am I, do I want to harvest that benefit of using a more influenceable metric, which is easier to measure, more leading maybe, but I trade off a bit of that 100% certainty that you might get from if the EBITDA moves, the company is more financially secure. And I think it's, it's, it's, again, it's a conscious decision. Like, do I want to take that trade-off for a better, a more useful metric for the team? And I, I take that into consideration. And honestly, I would say even the companies that I've met that are more mature from an analytics perspective, you have to bet a lot on correlation at some point. And it's, it's like finding the signals for just enough correlation to believe in that this metric, the team can influence actually links up to the, to the company. Because again, like the big company metrics, they're all like, they're the aggregate of so many factors, that are, that's like moving the tanker. And I think it's like the more informed you are about which metric, which metric you, you can influence to, to have enough, yeah, insight or confidence conviction on it that improving it should benefit the company goal. How many different teams have crashed against the rocks of should? But no, I, I take the point. But one of the things that also stuck out and we, again, touched on it earlier this idea that discovery is a common problem or lack of discovery is a common problem within many organizations. And one of the things that you call out in the book, which kind of caught my eye, is this idea that sometimes if you're in a good old fashioned feature factory and you're given a bunch of solutions or kind of very specific outputs that you need to build that, you know, obviously a lot of the time people just kind of complain about that and, you know, gnash their teeth and then probably just build it anyway. But you recommend something that, to some extent, I always recommend, which is this idea almost reverse mapping the solution. So you've got a solution and you want to kind of work backwards a little bit. Now, some people might sit there and say, well, that sounds like a bit of a waste of time because we've got to build the thing anyway, right? So why don't we just concentrate on building it? But why don't you tell me through just quickly this kind of reverse mapping idea and why that's beneficial even if you have been given an output to work on. I think it's beneficial for two reasons. It depends a bit on the, let's say, the willingness to change of the company. I think the most immediate benefit you can get is to say, okay, if I reverse engineer the customer behavior, the outcome I