Radically Rethinking OKRs with Radhika Dutt - Productized 24

We wrap up our coverage of Productized 2024 with an engaging conversation with the renowned Radhika Dutt. As a returning guest and a fan-favorite, Radhika brings her unique insights into the challenges product teams face when using OKRs and shares her radical rethinking on this popular framework.

In this episode, we dive deep into her new talk on “Radically Rethinking OKRs,” where Radhika passionately argues for moving away from the traditional OKRs model, which she believes often leads to short-term thinking and performance gaming. Instead, she advocates for a shift to hypothesis-driven objectives and key learnings, emphasising continuous learning over rigid goal-setting.

Radhika on LinkedIn - https://www.linkedin.com/in/radhika-dutt/

Episode Highlights:

• The pitfalls of the traditional OKRs and how they push teams toward short-term fixes
• How a hypothesis-driven approach fosters true learning and long-term success
• Real-world examples from Radhika’s extensive experience in helping teams break free from vision debt
• Practical tips on how product teams can implement these radical ideas into their own OKRs process

Whether you're new to OKRs or a seasoned product manager, this episode is packed with actionable insights that can help your team thrive in a constantly evolving product landscape.

Don’t miss out on this transformative conversation and be sure to connect with Radhika on LinkedIn if you’re eager to dive deeper into her radical ideas!

Use code PROD24 for 15% off training courses at Sheev – https://www.sheev.co.uk

Host Bio

Ben is a seasoned expert in product agility coaching, unleashing the potential of people and products. With over a decade of experience, his focus now is product-led growth & agility in organisations of all sizes.

Stay up-to-date with us on our social media📱!

Ben Maynard

🔗 https://www.linkedin.com/in/benmaynard-sheev/

🐦 https://x.com/BenWMaynard

💻 https://sheev.co.uk/

Product Agility Podcast

🔗 https://www.linkedin.com/company/productagilitypod/

💻 https://productagilitypod.co.uk/

🖇️ https://linktr.ee/productagility

Listen & Share On Spotify & iTunes

• Spotify - https://open.spotify.com/show/0lkwAYJzVSuk5zfJ1vIDZq?si=4c691fb12f124a56
• iTunes - https://apple.co/3YvTX8p

Want to come on the podcast?

Want to be a guest or have a guest request? Let us know here https://bit.ly/49osN80

Transcript

0:00

Welcome to a very special series of episodes of the Product Agility Podcast, broadcasting for two days, direct from Lisbon Portugal and product ties 2024. This year we're bringing you more exclusive bite-sized wisdom with our talks in 10 format, where we're going to be diving into actionable insights from some of the best and brightest minds in product leadership. And attendees this year are being spoiled with talks and workshops from the likes of Radakadat, creator of radical product thinking and rich Moronov, author of the art of product management, helping us all find some joy in what we do. But it would be a pretty shitty conference if it was just two people. There are so many more people here and they're going to be getting as many of them as possible on here to share their talks in 10. Now before we begin a huge thank you to our sponsor Sheev Limited. Sheev is the company which has bankrupted this podcast pretty much since day one. I want to take an opportunity just to share with you and make you aware we do some awesome stuff. Whether it's training your product teams or coaching your product teams with clarity and alignment or you know just a simple thing of actually making OKRs work in organisations, these are all things that we are very good at. So do head over to www.sheev.co.uk, see what we do and get in contact with us. Also check out the show notes for a tasty little discount code over any of our courses. Grab a notebook because the next 10 minutes are going to be packed with action tips from the best in the business. And here begins a talking 10. This is the last episode of George that we're recording at productized 24 and we've timed it perfectly and what I was really going to do is start this last recording when the noise started and it's been just worked out so well. Brilliant. Isn't it brilliant? Can anybody guess whose voice that is? In fact you probably know because you've read the episode of the internet, it's rather good. Hello. Hello. It's good to be here again Ben. Yeah, one year. Exactly. Yes. About that. 360ish days. And here we are again. You are the longest standing keynote speaker at productized. As in you've done three? Two? That is true. I have done three productized keynotes. One was during the pandemic and that was online. So I don't know if that counts but last year and this year and I think that feels like it was truly special. Yeah. Last year was, yeah, the first time I ever saw you and I came for a chunk of your talk. I was just blown away. It kind of really opened my eyes a lot of things and I was lucky enough to get to interview you and we explored your talk last year and then you gave another talk today revolving around radical product thinking and OKRs. Yes. It was titled Radically Rethinking OKRs because it is such high time that we give up on this idea of OKRs because they do not work even though we have faith in them as if they were religion. So we will talk about that talk. We'll talk about the talk. You can see the passion already. Yeah. I thought I'd just nip that in the bug and just get an end and then do what I was supposed to do which is explain to everyone who's listening that we're going to be talking about your talk first of all and then after that we're going to be taking some questions from people who have provided me with questions for you to answer Radically. I love that. Yeah. I get to be always on. Yeah. And then you finish and then after that you're are you done then? Are you off? Is there ever an off? Maybe I'll let the listeners judge that at the end of this podcast. Am I ever off? Are you ever open question? Right. So you're talking about a clear thinking OKRs. Tell us a little bit about your work. What is it about OKRs is really pissed you off. Well, first of all, the fact that it's a religion that we don't question. We don't question if OKRs work or don't work. We just believe that they do. And so what I found through my entire career of experience of maybe 25 years or so is that they work about as well as putting duct tape on foundational cracks. So meaning really not very well. What truly pisses me off about OKRs is the key results part. And that's because it really messes up the yin and yang of long term versus short term. What makes the product good is when you have a good balance between the long term versus the short term. And what happens with key results is that it makes you think short term. It makes you feel like you have to pass this end of the year exam. Set by these key results and you have to meet this target or this number. And so that means you're sort of forced to think short term and work on whatever it is that you've set yourself up for as a target. So I'm sure people hear that. I say, well, hold on, you're just not using a chaos correctly. Exactly. We all silently question that faith internally. Maybe I'm not doing OKRs correctly or the preachers among us go like, you're not using OKRs correctly. Right? And the reality is it's not about how you are using them. It is a fundamental aspect of setting these short term, setting these goals, which actually even though the OKR model tells you that they have to be short term goals. Right? So when you set those goals to be short term, how can it not lead to short term behavior is the big question. So even if you have an objective that sounds long term, and let's take an example. So one example would be improving software quality. Sounds wonderfully long term. But the way you implement it then, a key result. And this is an actual example from a company. The key result was achieve 90% test code coverage. And it sounds wonderful. Again, you think, oh, wow, we're going to invest in writing good test cases and improving test coverage. Well, how did they actually implement it? Because it was a short term incentive. Like, by the end of this year, we really want to get to this test coverage. What did people do? They ended up writing bogus tests. And so they got test coverage, but did it actually improve code quality? Not at all. So when I think about this, Ying and Yang of vision versus survival or long term versus short term, if I think of it on an X and Y axis, which is what we talked about last time in our podcast, if your Y axis is vision fit and your X axis is survival, then what is good for vision and bad for, sorry, what is good for vision and bad for survival is investing in the vision. That's when you're investing in the vision by doing things like refactoring code. The opposite of that is when you take on vision debt, when you're doing things that are great for survival in the short term, but hey, it's not good for the vision. And so this key result, this example of 90% test coverage, the way we actually end up implementing it, ends up meaning that we take on vision debt because we write bogus test cases, for example. It's an interesting one because I've experienced exactly that. There are no OKRs involved, but simply the act of measurement was enough to, it was very interesting. So this was around the time I shared a story earlier about a gentleman called Harsh, who was learning about queuing in England. And this is when he was, I think he'd just started stop working on our team, and we decided we wanted to have a nice high level of unit test coverage. And they saw some developers and they knew, for them it was a target to help them improve their practices. And all of a sudden one day we went from like 70 to 90. And my friend Mark was like, how the hell have you gone from 70 to 90? And he looked and someone had figured out that as long as he wrote a unit test, which exercised all the lines of code, you didn't have to make any assertions. As long as it exercised it, the tool was folded, you think, and that was the case. So in that instance, exactly the measurement was very wrong, but what it did allow Mark to do was and sit down with a person that wrote that and said, let me take some time to explain what's going on here. So it did catch that. So is there something here? Yes, OKRs are like, they don't know if they should have them, they are a bit of a religion, but is there something here just also about the flaws of measuring things? Absolutely. And in fact, there's something called Goodheart's Law, which a British economist came up with in 1975. And what he said was, measure seizes to be a good measure when it becomes a target. And it's exactly what you're observing, that when you set a target like 90% test code coverage, you know, that now seizes to be a good measure because everyone's going to game it. And that's the thing with OKRs, that, you know, we've known this about measurement and how it seizes to be a good measure when it becomes a target. We've known it since the 70s. Why do we then still insist that that's how our companies make progress? But what you said, I think, you know, measurement in itself is good. We just don't have to set targets. So what I propose in the talk instead is we should measure, and this is that's law, by the way, which is that a measure is only effective if it is used for collaborative learning. So metrics are useful for collaborative learning, but when they become a target, they become an end-of-the-year exam. And that's when we want to game the system. So what are you proposing as an alternative? Or not an alternative, maybe a reimagining of key results? Yeah, and it is an alternative too. I'll talk about both an alternative and reimagining. If you are choosing an alternative, and your company today uses OKRs, what you could try to move towards is this perspective of radical OKRs. So instead of objective and key results, create objective and then hypothesis and key learnings. So instead of key results, what you want to move towards is hypothesis and key learnings. It changes the framing that instead of a target, what you're going to do is you're going to create a hypothesis, and then you're going to say, what are we going to measure to be able to tell if it's working or not? And those are going to be the key learnings. And you'll measure everything to understand that hypothesis. And what you will share is not just the good metrics, but also the bad metrics to talk about what's not working so you can improve it. So to give you an example, in the same case of improving software quality, so instead of creating 90% test coverage, what you would do instead is in this hypothesis model, you write a hypothesis in the format of if we do this experiment, then we expect this outcome because of this connection. And so in that case, for writing better software, you'd say if we get buy-in from software developers and help them see the importance of writing test cases and train them on writing test cases, then we expect better code quality and better inclusion of test coverage on code because we'll have buy-in and people see the importance. And now the way you measure it might actually be qualitative. It might not even be a quantitative number. So in this company where they were originally measuring test coverage, and they did this actually in this company by writing bogus test cases, and what I meant by bogus was exactly what you said, which is just no assertions. So instead of that, when they moved to this hypothesis-driven approach, the way they started measuring progress was looking at the code reviewers and their qualitative feedback where developers actually writing better test cases and was their buy-in. And because of all of this, where are we seeing better software quality? I really like it. I mean, it's a, it flicks things when it's head a little bit, but I think it really plays into what's important in organisations and it's important for us to be able to adapt, which is learning, learning is critical and that ability. And I think that key results, they are so often misused, I think, because of the word result. I think then people will just use what they've already done historically and just shoehorn it in rather than, I think, providing a bit of a challenge on actually how we could think about it differently. So, yeah, I really like it. And this isn't something which you wrote about in your book, is it? This is new. It is new material. I mean, you know, in the book, I do talk about the problem with OKRs, and I talk about how we need to use metrics for collaborative learning. So I touch on this topic, but this concept and making it much more articulate and clearly visualisable in terms of changing out the key results for hypothesis and key learnings, I feel like this is something I arrived at as an alternative only now. Oh, you know, speaking of alternative, I remember, I did say we would also talk about reimagining. What if your company doesn't do OKRs today? I mean, if you're in that lucky position where you don't actually use OKRs, it's easier to move towards the model of having hypotheses and key learnings, etc., without needing to fit it into this mental model of OKRs. I think you're in the lucky position, because then you can do the radical product thinking approach, which we talked about in our last podcast, which is start with this clarity of vision, translating it into a clear strategy, which is a set of actionable steps, then into priorities, and then your hypotheses are derived from your strategy. The problem with OKRs and objectives, even, you often sort of pull them out of thin air, like, you know, what's an objective? You know, if you instead tied it into every element of your strategy and every element of your strategy becomes a hypothesis, and then you're measuring, is this working or not, that's really a fundamentally better way of building a product, taking this hypothesis-driven approach? Yeah, I love it. I'm going to be trying it, I think. Next week, I think as a fan, so I'll be calling on you for a bit of guidance, maybe. Brilliant. I'm looking forward to it. Yeah, I'd love to experiment with it, because I think it is a very different approach. I mean, my concern is that, and I think maybe I'm kind of playing devil's advocate here somewhat, is that the people that have, I think, some good attitudes towards OKRs. Radical focus is a great book, and yeah, and the way that OKRs are kind of espoused in there, because I think it's quite healthy, and this guy's saying they have very few, and they treat your key results, I don't know, maybe it's a way Jeff got help, it added to it, and it's going to behave your outcomes, and I like that. But even with that, which is a step, I think, before kind of, the more radical approach that you're taking, is that people just find it hard to get their head around with it, and I do wonder that, you know, is some of this just a great, too great elite for an organization, that they can't get their head around, like, maybe how to make, how to write a single OKR, and kind of all the effort it goes into making an objective, which is really impactful. Are they going to then get their head around writing hypotheses for learning? Is it going to be too much of a leap for them? Yeah, you know, it is a mindset change, right? One of the things about OKRs is that it is so core to our beliefs, that the way you manage a team, and the way you make progress, is by having goals, goals are really just so set in our system of beliefs, and so we tend to ignore research that challenges our system of beliefs. I mean, in fact, if you go all the way to the 18th century, they had found the cure to scurvy in 1735, but they didn't start actually using limes and lemons Navy ships until 1795. Why? Because leaders were convinced that it was good hygiene and good morale and exercise that prevented scurvy, right? They refused to look at the evidence because they were convinced and all of their research went against their system of beliefs. This is kind of what happens with management and our belief in OKRs. So how do we convince management? One of the problems with this OKR approach is that often what you measure is a lagging indicator. So if you're looking at, let's say, customer retention and hitting this number of, you know, reaching a customer retention metric or target of BLA. Well, that's typically a lagging indicator. There might be tons of experiments that you're running to be able to test if you are indeed affecting customer retention in a positive way. And so instead of waiting to measure all of those lagging indicators with OKRs and then giving your team, you know, a pass or a fail on your exam, you know, you could measure leading indicators and then do course corrections along the way. So yes, it is a change in mindset, but I think it's a matter of education and helping them see the benefit of it. Yeah. Yeah. Yeah. How do you motivate people? And continually motivate people enough to kind of break through those mental models that they have carried with them for so long. Yeah. And that's right. I think, yeah, stuff like that. Your talks and your books are great ways to really inspire and like push people along. I do want to kind of turn the conversation onto some of the questions because I know we haven't got all the time in the world, but the talk that you gave obviously will be out on the product highest website on YouTube channel at some point. But if people are interested in learning more about your radical ideas around key results, is there any way they can get that information like before that video is released? Well, you can definitely read the radical product thinking book. It has all of that information in the chapter on execution and measurement. It's just I haven't visualized it as well as I have in the talk. And in fact, I'm thinking of writing a second book titled radically rethinking OKRs. So if our listeners are interested, please feel free to ping me on LinkedIn and tell me all your thoughts on OKRs and what resonated for you on this podcast. And I'd love to either interview you or we can chat about it. And I might include that in the book. I'll go a few people. I'd love to talk to you and them about this topic. And I'm looking forward to actually interviewing you after you implement this next week. Oh, no way. Interviewing. I'm not sure if I've been interviewed very often. I was interviewed by a lady called Shelby actually a little while ago. She returned the favor after I interviewed her. So yeah, I'm happy interviewing me. It'll be fun. Time to turn the tables. Yeah, we'll do it. We'll get that booked in. So let's move on. And we do have a few questions. Excellent. I love listener questions. Yeah, I kind of wish that it was like a radio phone or something. You know, like a news online one. But no, unfortunately, we can't do that. I did ask so James, this CTA by the way, I did say, do you want to send me a voice note? And then I'll ask the question, but then I'll kind of splice the voice note into his like, I'm too old for voice notes. So James, you'll be listening to this. I did. Did you actually say you were too old for voice notes? I think he said, yeah, he's a texter, which in my eyes it means he's a certain age, and you're a texter. Anyway, so we'll just do a couple of questions. Because I've been there, it's been very good questions. And this first question, I think is particularly astute. And I think it really talks to James' level of insight and having his Rachel book. I think he's a big fan. And he asked the question, what do leadership teams look like for the best radical product organisations? Do they have separate CTO and CPO or CPTO? What's the starters of leadership? Is it servant leadership or force it? And then any other styles of behaviours that seem to promote success? Excellent. There's a lot to unpack in that question. I'm having them pick it apart and give them a few pieces of it. Hello, James, I love the question. So let's start with the first part. What does good leadership look like? Or that would work well with radical product thinking. I think the biggest part is alignment and openness. Being able to have psychological safety, I don't think it's so much about how you structure it. But it's really about the alignment and your ability as a leadership team to balance the long-term versus short-term. My own experience has been separating the role of CTO and CPO, has been helpful to balance that ying and yang of long-term versus short-term. That you need these separate roles only because typically the kind of person who takes on the CTO role, and James, you might be the exception, but typically they're not the ones who are going to be insistent on doing proper user research, on doing enough discovery. The focus is often on wanting to find use cases for technology. And having a CPO mindset, someone who's really focused on being able to do adequate user research to be able to shape what we build is really helpful. But if someone has the right personality, you can have CTO, CPO mix. To a certain extent, it's a different career path. And you end up going on not because of the nature of the role so much. It takes a lot just to do one. And to find somebody who can do both consistently and at a certain scale. It is a very special person to be competent enough in both, to do both, I guess. And so actually, having that ying and yang, having that tension between the two is really powerful. But also, I mean, if I've been really dubious that someone came forward and said, I'm excellent at both. Because that's a lot of stuff you have to have learned and to be able to do, I think, in order to be effective. Exactly. I mean, it's just like saying, you know, what if we take the chief revenue officer and take a chief product officer and put those together? I think we very clearly see the difference and why that ying and yang gets messed up between sales and product if you combine that in role. And it exactly the same happens if you're trying to do the same with a CTO and CPO role, but from a different angle. I suppose, and we'll move on in a second, but the important thing maybe is that as long as the leadership team are all aligned against that radical vision release, they articulate it differently, but they all are believing in that kind of that, you know, the radical product vision, which is I'm putting them forward and they bought into it. But it doesn't matter where what the roles are, if everyone's aligned and working together to achieve it. Is that a first statement or? I think it's not that the roles don't matter. I think you all understand your role in this ying and yang that sales might be pulling you towards the dark side. I call it the dark side, but who knows? Like you can call it the light side, dark side. It's one side, right? Sales pulls you towards one and product pulls you towards the other. But similarly, I think, you know, tech pulls you towards one and product pulls you towards another. I think it's just each person in the leadership team knows their role and they work together and to be able to create that balance. I think it's being able to work well together to create that balance that's the most important part. Okay. And the last one on this particular topic, then is it a particular type of leadership style or behavior which works better in medical product organizations? Yeah, for me, an authoritative role never works well. Like I've never found that to work well in the long term. When a product, when a company does well and or a product does well, and there's someone with a very authoritative style who is in power, I typically see that the product is doing well despite that style, not because of it. Yeah, I think the whole radical product thinking approach helps you bring everyone with you on the journey. And I see that as super important, you know, you need a team to be extremely motivated to stick with you on the whole marathon of building a product well and continuing to find product market fit and improving on it. It's not a short sprint. And in an authoritative style, it might work for a very short amount of time, but you burn people out so quickly that you don't really get people to run that marathon with you. And the more complex your product is, the more you need the marathon runners and not the sprinters. And when you say the radical product thinking approach, that's more than just the vision. That's the whole, the whole shebang driving is kind of picking and choosing or exactly. And so the radical product thinking approaches, you have this clarity of vision, which you talked about, and it's a fill in the blank statement that helps you outline the who, what, why, when in house, we have a very detailed vision, not one of these fluffy statements like being the leader in data storage. Then you have a very detailed strategy. And it's called an RDCL strategy, which is the R stands for real pain points. The D is designed, sees capabilities and it allows logistics, but it helps you identify the pain points, how we're going to solve those, the engine underneath to bring about that design. And finally, the alpha logistics is about the business model, pricing, etc. And it all comes together to create a well thought out strategy. And then you translate that into priorities and into execution and measurement that's hypothesis driven. But all of these elements of radical product thinking, I know that when I describe it in these, in this step by step process, it might sound like, well, that sounds very linear or almost waterfall. And I don't mean it in that sense. The product development process itself is not linear. Surely you'll go back and forth between these steps. But if you just imagine the visual of going back and forth in the Brownian motion between these steps, and if you remove all of those elements of communication, it starts to look like chaos. So that's why we need all of those steps to really bring everyone with us on the journey. Excellent. Thank you, Radhika. You up for another question? Yes, let's do it. This is an anonymous caller. So it says, I'm in a relatively formal hierarchy with a good talent to influencing peers and engaging with directors. But when decisions need to be made, these are still deferred to middle management. And this is from a digital product director, a manager, leaving me out of a loop. How can I break this habit and get into those conversations? Hmm. This is a hard one because sometimes it's a matter of company culture where you're left out of those conversations. One thing that I might suggest is helping the team with a facilitative approach, where you insert yourself in some of these meetings and use some of these tactics that I share about vision or strategy. You know, my secret tool is using the vision versus survival two by two and using that in a meeting, drawing that up on a board. And then, you know, by talking about vision versus survival and where a decision fits on that, I don't directly challenge because when I hear this caller saying that they're in a hierarchical organization, one of the reasons that they might be leaving someone out of the loop is they don't want to be directly challenged. So the solution that I've had to figure out over time is just how do I influence that change without directly challenging? And it helps me get myself back into the loop. And so hence this idea of vision versus survival, when you start to draw that up, you start to introduce terms that will start to spread. So for example, you draw this vision versus survival on an X and Y axis. You know, when it's good for vision and bad for survival, I talked about that as investing in the vision and good for survival, bad for vision is vision debt and good for both vision and survival is of course, you know, the easy decisions quadrant. When you draw this up and talk to people about how you're prioritizing things and balancing priorities across this long term versus short term rubric, it really helps people start to use the vocabulary and recognize when they're taking on vision debt. And being a little bit more introspective about the consequences of the decisions that they're making and you're doing it all in a way without directly challenging. And you're not directly challenging their vision, but it honestly begs this next question of, well, when you draw up the sex and Y axis, I wonder what is our vision, are we aligned on that? And what is survival for us? Are we aligned on that? You know, so it's a bunch of ways in which you start to tackle the status quo, bring in new thinking, but without directly challenging. I've listened to that, I look at the next question here and I think it's also applicable for the second question because it was saying how stakeholders have been relatively engaged after a lot of work to have them understand the product and they are now beginning to engage and giving feedback and ideas. Unfortunately, similar ideas are also great. So how do I maintain their energy but still the better ideas about shaming them? Which I think shows you makey cares about them, and just wanted to make anyone feel awkward, but I think what you were saying with your axis is actually, if it's a way to help people see that their ideas aren't maybe a good fit and then help them take on a sense of journey to combat better ideas. Would you say that kind of matters? Exactly, I love what you said, because you might point out that it's vision debt. And you know, honestly, they might be right and saying right now we need to take on that vision debt. Maybe the company is bootstrapped, you're still raising more funding or even the stakeholders are under a bunch of pressure and you might have to take on that vision debt in the short term. So, you know, just having those conversations and figuring out what is that right balance between vision and survival might be the right approach to go. Thanks, my job, Ralke. I think we're going to have to call it a day, unfortunately. It's been brilliant. It's been brilliant. And I do urge everyone, if you haven't read the book Radical Product Thinking, do buy in some form. It's a fantastic book and it's been an honor to have you on the podcast once again. Always a pleasure and never at all. Very much the same Ben. Always a pleasure to chat with you and I'd love to do this again soon. And I'm going to get back and listen to our episode from last year just to compare voice, because last year you were Husker. I hear a tanger for Grett that my voice isn't Husky this time. Always a pleasure. So, thank you so much for coming on. You mentioned if people have ideas or things that want to talk to you about OKRs and contacts you on LinkedIn, did you say that? Did I mention that? Yes. No, I did very much say that. Please feel free to reach me out and reach out to me on LinkedIn. You can also read the book as Ben was saying. And also, I've launched Radical Product Thinking certification on my website. You can check that out at radicalproduct.com. Fantastic. But Aradik, thank you so much for coming on. Everyone, thank you so much for listening. Vista draws our time direct from Productized24 to a close. It's been a fantastic two days for me and maybe more days for some and still more days to come for others. So, thank you to everyone who has been here. It's been a tender thank you to all the speakers. And thank you to Andre, Marquet, who's done a fantastic job ranging another awesome Productized24. And I really hope that we get to come back for 25. So, this is us signing off from Productized. We'll see you all soon. Thank you.