Featured Links: Follow Itamar on LinkedIn | Buy Itamar’s new book ‘Evidence-Guided: Creating High Impact Products in the Face of Uncertainty’ | Free e-book downloads on Testing Product ideas, ICE Prioritisation, OKRs done right, and many other resources at Itamar’s website | Sign-up for Itamar’s ‘High-Impact Product Management’ newsletter | ‘High-Integrity Commitments’ feature at SVG | Itamar’s previous episodes on The Product Experience podcast
Episode transcript
Lily Smith:
Randy, I’ve been thinking I know it and you know it, but actually how do we really know that we have the best product podcast around?
Randy Silver :
Ooh, that’s a good question, lily. You know, I had a math teacher in high school that would joke about some of the proofs he was teaching us by saying it’s just intuitively obvious to the casual observer. I mean, that’s the case for the podcast as well, isn’t it?
Lily Smith:
I do not believe that your teacher would let you get away without showing your work. So how do we prove this?
Randy Silver :
Hmm, okay, well, let’s use some of the principles of great product management. We can start by following the evidence, and I know just the guy who can help us with that.
Lily Smith:
Ah, that can only be one person. Itamar Gillard joins us again to talk about his great new book Evidence Guided, which you can check out at evidenceguidedcom.
Randy Silver :
It’s a great read and it’s almost annoyingly good, but I’m going to be sick of how many times I reference his name and the name of the book to the people I work with over the next few months. So let’s get right into it, because it’s a really great chat. The product experience is brought to you by Mind the Product. Every week on the podcast we talk to the best product people from around the globe.
Lily Smith:
Visit mindtheproductcom to catch up on past episodes and discover loads of free resources to help you with your product practice. You can also find more information about Mind the Product’s conferences and their great training opportunities happening around the world and online.
Randy Silver :
Create a free account on the website for a fully personalized experience and to get access to the full library of awesome content and the weekly curated newsletter Mind. The Product also offers free product tank meetups in more than 200 cities. There’s probably one near you, Itamar. Thank you for coming back to the podcast. It’s very exciting You’ve got a new book out.
Itamar Gilad:
Thank you for having me, guys. I’m super excited to be back, and thank you for inviting me again. The book is out, so I’m celebrating.
Randy Silver :
And just so everyone knows, the book is Evidence Guided. Why this book? What made you decide that you wanted to write this?
Itamar Gilad:
This book has been a four and a half year project. I thought it would be an easy book to write about, explaining my ideas of how to bring evidence-guided principles into your organization. That’s what the book is about. I was lucky enough to experience those in Google and other companies I worked for, and it turned out to be much, much harder than I expected. So here we are today, finally.
Randy Silver :
Okay, so we’re going to get into the methodology and applying the methodology, but there was something in the introduction that I really liked that you talked about, which is the fact that we’re all agile these days. We do that right, but planning, strangely, is stuck in waterfall. So tell us a little bit about why is that happening? Why that is not fit for purpose in an evidence-guided world. So yeah.
Itamar Gilad:
So back in the day we were not agile, we had project waterfall. It was horrible. We all hated it. I don’t know if you guys got the chance to enjoy this thing. And then agile came and now we’re super agile. We can change our minds from one week to the next and life is good. Do we change our mind from one week to the next? Absolutely not, Because we’re already committed to roadmaps, which are often just very large-scale kind of plans, strategies, projects. So we are actually very committed. So it’s kind of waterfall planning leading to this extreme agility. So my point was we need to make the whole stack agile. We need to stop with this very static form of planning where we decide upfront which ideas are good and which are bad and unfortunately the statistics are very clear. We’re terrible at determining this, partly because it’s impossible to tell. There’s so many moving parts in the marketplace, in the product, in the technology, In our own organization. You never know which ideas will succeed and which will die. So trying to foresee the foretell the future and burn into the plan, set the ideas and then develop them in an agile manner, for me is what I call opinion-based development, and the book is trying to show the alternative, which is evidence-guided development.
Lily Smith:
And a big part of this process is using something like your GIST framework, which we covered in the last episode with you. But I think, given it’s so kind of pivotal to being evidence-guided as well, it would be great if you could just give us a quick kind of recap of what GIST is and how it works.
Itamar Gilad:
So this is just a framework, or rather a meta framework, that kind of tries to help you break this big challenge of becoming evidence-guided and it is big because it goes against a lot of things we believe in and we practice into four slightly more manageable parts Setting goals that’s the GNGist. Picking ideas, which ideas to work on. So if you’re familiar with the term prioritization, this is where it fits. Testing these ideas and testing them at the same time. So discovering delivery, build, measure, land loop, whatever you want to call it. And eventually, the tasks layer is about the things we managed today in Kanban or in Jira or you know, the things your team is really focused on, and there we don’t change that much, but we are trying to connect the tasks as much as possible to the steps, the ideas and the goals. The steps is the layer where we build and measure and learn and getting the team to become a bit more discovery-oriented. So their job is not just to deliver code as fast as possible, it is to discover the right product that will create the right outcomes as soon as possible. And doing both of these things requires these four changes in my mind. I will say Jira is not an original new thing that I just invented. It’s a meta framework that brings in product discovery and design thinking and lint, startup and a bunch of growth hacking and a bunch of other things that much smaller people have created. But it does create some sort of structure that I found when I worked at Google and other companies and some of the people I consulted and coached found is helpful to move things along in the right direction. I have to say.
Randy Silver :
I’m really annoyed at your book and I’m annoyed at it because I know I’m going to be referring to it so often over the next few months. But some of the diagrams and the explanations in it, the way you show how GIST works with Scrum, with Kanban, with Lean Startup, with all these other things it’s really intuitive, it’s really useful and it’s just annoying that I’m going to be saying your name and the name of this book so many times over the next few months.
Itamar Gilad:
Coming from you. It’s a great compliment. I’m sure that the audience knows that you and Lila are two black belts in product development, product management. You guys know this stuff very well. You don’t need my book. So thank you very much, randy, for the kind words.
Randy Silver :
I think we’ve both been beaten up a lot anyway.
Itamar Gilad:
I don’t know about the black belt part.
Randy Silver :
So one of the things that you go into this as well is dealing with some of the challenges to adopting this methodology and evidence-guided methodology that you use GIST for. One of the things I really like at EMAR as well is that not only do you introduce the methodology and we’ll get into a lot of the ways of implementing, but you’re very upfront about the fact that there are challenges with this, and there’s some very common challenges, some common pushbacks that you see, and I’d love to deal with a couple of those up front. So let’s talk about this in order. Let’s start with lack of trust. How do you move to an evidence-guided approach when there isn’t trust in the system?
Itamar Gilad:
I think a preliminary question is to ask why isn’t there trust? Why aren’t all the managers trusting the product teams to make decisions? Why aren’t the product teams actually trusting the plans that they are given that much and that’s correct me for a moment. That’s a very common situation that we all see all the time. Why in between disciplines, there’s lack of trust, why the stakeholders are not trusting the product and vice versa. Part of the problem is, of course, siloing and some fundamental issues with the way organizations function and the deep concept of culture that I’m not touching on very much in the book. It’s really there are much better books and much deeper on this subject. What I did observe it’s some of the lack of trust comes from the fact that we do this planning waterfall that we mentioned earlier. So the managers, the stakeholders, the senior PMs they spend a huge amount of time developing the plans, developing the perfect roadmap, developing the perfect strategy, and then the people who are not invited to this party are, unfortunately, the people who are going to make it work the value creators, the developers, the designers, the junior PMs, which in some companies in Europe are called product owners for some reason, and they are supposed to honestly work in kind of a feature factory or the delivery team and deliver on these big expectations. Sure, there are PMs in the middle that are supposed to connect the dots and bring the context. But it’s very natural if they don’t understand the context and it’s not explained to them very clearly and the goals aren’t very clear. The goals are always expressed in terms of we want you to launch this big thing or forget about that big thing. We came up with a new one that is even better. Over time, after you work on master features for a while, you lose trust in the system. You realize all these big promises lead to very little or even if you launch them, nothing happens. It turns out that just two years big project wasn’t as important as we were told and someone is not doing the privatization right. So when you do the retrospectives or if you attend retrospectives, planning comes up again and again as one of the problems. We need to plan better and usually the people will do the execution, pointed the plan and say this was not the right plan. On the flip side, the people who are creating the plans, the people who are really thinking about business goals, etc. They see the product teams as very detached, very focused on engineering, very focused on delivery or, sorry, on quality, launching their own big projects that are slowing things down and eventually nothing. They’re iterating constantly, but nothing comes out and eventually, when it does come out, it’s disappointing to them. So, after enough cycles, the two teams, the two groups are starting to drift further, further apart and there’s less and less trust, and usually what kind of fills up the gap is process. So we introduce more process or more layers of management and guess what? Things get even worse, because that’s the way it is. So I think what we really want to do is to bring everyone back into the same room, in a sense, to break the walls. So the first thing in my mind is to switch from output roadmaps to outcome roadmaps, where the leaders express in a very clear way what they want us to achieve, what are the business goals, what are their outcomes and by when. And that’s something you can lay out on the roadmap and say buy Q3,. We need to address this major challenge or we need to tackle this big opportunity. We don’t know how, but we expect you all to take part in it. The second part is we should stop the battle of opinions over ideas, because when we come into a room and the goal is to decide which ideas we’re going to build, that’s where usually the senior people win, if you are able to say here are the goals, but we are willing to test multiple ideas and we’re willing to do this in a very transparent way, meaning that the teams that are running with ideas are showing results constantly. And that’s something I learned firsthand in Google. Instead of committing to a launch schedule, you are committing to showing that constantly you are moving in the direction of the business outcome that the big boys really care about. You’re showing that more customers are engaging or that, when you tested in I don’t know the early adopter program or the beta or the dog food, people are displaying the behavior that you want them to display. That helps the business. These things are called evidence, and when you show this evidence to your leaders and say, look, I think we’re on the right path here, or look, this big idea that you guys came up with is actually showing negative evidence or insufficient evidence, you have a different type of discussion. It’s not about your opinions versus mine. It’s about more concrete things. If you are able to do the first iterations and show that the product team is continuously working towards business goals in this very transparent and objective way and evaluating ideas based on very clear criteria and testing them and deciding to poke certain ideas based on this criteria. It creates a chance for people to start trusting each other a little bit more. When a stakeholder comes to you and says you must deliver this feature for me because my top customer demands it. If you respect this message but you show that stakeholder that this idea, how does it stack up against other ideas and how they will benefit at the end of the day, if we’re able to address the bigger goal that the team is committed to, again, it enables some sort of discussion that breaks the walls a little bit. I know it’s easy to say, but from first and experience, once we introduce this kind of language and culture, it changes the context around people and eventually it will start changing their belief system.
Lily Smith:
I think that ties in quite nicely with one of the other challenges you pick up on in the book, which is the fear of slowing down with this different approach, because I was literally having a chat in one of my product leadership networks the other day about the C-suite perception of speed of the product and engineering teams and how there’s this constant pressure on what have you delivered? You’re not moving fast enough, that kind of thing. So I feel like you’ve touched on it a little bit in that lack of trust and building up trust by showing the focus on the outcomes as part of this new framework or this new way of working. But how does that specifically address as well the businesses worry of like is this going to slow us down? Or like how do we keep pace?
Itamar Gilad:
Right, this is the number one question I always get in my workshops. When I present this to executives, they always ask this question All right, cool Evidence delivery, but how much time can we give to this? When can we actually switch into doing the real work? And first off, news flash, this is the real work. It’s much more important that you will discover the right thing to develop. Because the statistics are so horrible, because one in three ideas on average, based on research, actually creates any measurable improvement, because all your past roadmaps if you analyze them, most of them didn’t actually move the needle at all. It’s much more important that you will spend the amount of time and resources you need on discovery and just when you reach that level of confidence and I explain in the book what that means exactly where you feel it and you have an idea that justifies the investment, then you switch into delivery. So, in an analysis of how fast did we ship the bits to production from the minute we came up with the idea, maybe it’s a little bit slower, I’m not sure. Actually, I have reasons to believe it’s actually faster and more efficient. But even if it’s slower, that’s not the right metric. The right metric is how fast did we achieve the outcome that we set out to achieve? Much more important, much more relevant, and I would argue that the evidence-guided method is far, far faster. And why is that? There’s a few reasons. The first is we are testing ideas and we’re dumping the bad ones much quicker, which means we have more room to pick up more ideas and we are increasing the odds that we’ll find one of these one in three best case scenario good ideas. Often, in many companies, it’s one in 10. Just how it is sometimes. The second thing is that initial investment in ideas is very low. You use very weak forms of light, forms of evaluation and validation, sometimes just doing an analysis on paper, sometimes a survey or fact-dota, whatever it is, and that enables you to actually discover that you can build a smaller version of the idea. You don’t need to do the whole thing necessarily and still get the outcome or still move towards the outcome. And that’s kind of the idea with the minimal, viable product that became very controversial and not very clear to a lot of people. You need to do something minimal in order to test the market and then sometimes you realize the minimal thing is good enough. We don’t need to, we just need to polish it and make it production ready. So that’s another reason why we are cutting down actually on investment while increasing on outcomes. Now, all of this is good in theory. The question is, how do you convince them, how do you show it to them? I recommend doing some backwards analysis, like looking at past roadmaps, past launches. How much impact did we do? You guys know Rich Miranov, the very famous B2B protoguro, if you like. He did a whole article with a spreadsheet explaining how much are we wasting by launching the wrong things in most companies. That’s something you can take and actually translate to your own company and you can talk to the big boys or big girls in dollars and euros and say, look, we are wasting every quarter tons of money just because we’re launching the wrong things. Shall we give this a go and try to optimize? Again, it’s a start over discussion. You need to show them that you are actually capable of. You need to create a space, a sandbox, where you are actually testing this system and showing them that you are able to create the outcomes faster. Together with Building Trust, you will be able to maybe move them gradually away from release roadmaps and more in the tight timelines and more into outcome roadmaps and more flexible timing.
Lily Smith:
Randy, what’s the most effective way to learn from the best in the industry? Connect with other PMs and sharpen your skills.
Randy Silver :
Why, Lily? You must be talking about MTPCon London happening this year on the 20th of October.
Lily Smith:
You know it, and this year’s lineup of speakers is shaping up nicely we have Tim Harford, behavioral economist, award-winning financial times columnist, data detective and BBC broadcaster. That’s all of those things is just him, Plus the legend that is Mark Abraham, product director at Backbase.
Randy Silver :
There’s also Randy Psydu, who’s the former CPO at Reliance Health, and Claire Woodcock, who’s the director of product for machine learning at Mozilla, and many more, including a great friend of this podcast.
Lily Smith:
That’s right. And don’t forget Workshop Day on the 19th of October. There are seven full day in-person workshops led by experienced product managers who share their secrets and tips for success.
Randy Silver :
And finally there’s the Leadership Forum, an exclusive event for senior product leaders, with carefully curated speakers, guests and delicious food.
Lily Smith:
So grab your tickets for MTPCon London today at mindtheproductcom forward slash London. So there’s your framework and does the book cover it Like? It mentions kind of evidence guided and we’ve just talked about roadmaps there. But I think I’ve read in one of your articles that this framework almost like replaces the roadmap, is just like a different way of visualizing the work that you’ve got, and you don’t need roadmaps anymore if you use this type of method of managing your work and planning your work.
Itamar Gilad:
Roadmap is a very overloaded word. I discovered the first time I published an article why you don’t need roadmap. I was surprised, but a lot of people were attacking me. You don’t know what a roadmap is because they migrated to a different type of roadmap. We have the classic release roadmap. We have the kind of modern version, which is the now next, later version, which is becoming very popular, and there’s outcome roadmap, which is me. I’m a bit more extreme, but not just me, of course. I learned this from other people where we are saying, yeah, you can put things on a timeline, absolutely, but try to put the outcomes rather than the launches, the output, with one exception. The exception is if you have ideas that are already validated and if we do our work right, we should have some of those always and we know we want to build them. We’re switching to delivery. It’s absolutely fine to put a little diamond there on the timeline and say we’re going to launch this thing by May 15. Why? Because we have high confidence, we validate it, we know it’s moving the needle, we’re just building it and this is our ETA. Another exception and this is I learned from Marty Kagan sometimes you need to commit to a project. I call this high commitment or high fidelity, or I don’t know High integrity, commitment, yeah, high integrity commitment exactly. I’m not really sure if this project is necessarily one you’ll be living, but for reasons you have to commit to it and that’s one you deliver. But that’s a rare exception rather than the rule. The rule is we are trying many ideas. We are committed to the outcome. We will project to you which ideas we have with color coding. Maybe we will say these are the short things we’re going to launch, these are the maybes. The confidence is medium and again I have the confidence meter that explains what medium means. And these are low and the medium ones should be on your radar. You may need to sell them, you may need to promote them, you may need to market them. The low ones are just FYI and it takes a little while for teams to realize that not everything that appears in this list is going to be shipped. If you try that, you know that they’re reading it very optimistically. But it is a way to be honest and to be very transparent and say here’s what we’re testing and here’s what we know and here’s the level of confidence we have in these things.
Randy Silver :
Edimar, you’re talking about this approach that you learned at Google and for lots of us who haven’t worked at Google or one of those types of companies, there’s a challenge in that big, successful companies Google, netflix, whatever they have the ability to invest in lots of ideas, try lots of ideas and kill the bad ones and keep and promote the good ones. But startups that are at a point where their run rate is hitting critical or enterprises that are marginally profitable or potentially losing money, they don’t necessarily have that kind of. They don’t give their product teams that kind of freedom to try lots of things. It’s always we know what’s best, just implement and move. It’s more of a feature factory approach. So how do you in those kinds of spaces, how do you start to shift the mindset and move in this direction? Does it work in those environments or can it?
Itamar Gilad:
First off, I will push back a little bit on your assertion that Google necessarily works the way I described just now. I think this is based on the DNA of Google, like the way Google used to work, and back in the day they had rules about this thing. They would say think big but start small, or fail fast or let a thousand flowers bloom, and this is kind of all aligned with my philosophy as well, and the philosophy, I think, of many other people in the space. What happened to a lot of these companies is they moved to the big bets they started creating, launching these big monster projects, and they didn’t validate as much. And what I’m finding is that there are pockets of people inside various companies I will not name names that are actually interested to relearn the old method, but apply it within the context of these big enterprises with all the you know, the levels of management, etc. Now for the smaller companies, I think it’s even more critical. Google can spend millions of person hours into a failed project, launch it fail publicly, lose a ton of money and still succeed, and we know this because this actually happened. My first story in the book is about Google+, which is exactly that A medium-sized company or a small company cannot afford to do this. You cannot possibly afford to start making bets and just launch stuff and work in a feature factory, partly because a few years in you will find yourself maintaining this bloated product. This is full of these features that almost no one is using, all of them, based on your assumption that they will be good. Are you going to kill them? Are you going to roll them back? No, because there’s always this one barnacle customer that insists on using that particular thing and you cannot disappoint them. So save yourself the cost, save yourself the effort, and you must find those products that you or those features that you need to launch. And I don’t know if any other way to find this out, except for maybe some science or some extra physical sensation thing to determine what’s going to be the future, except trying it out through experimentation, through evidence-guided approaches. So I think it’s a must.
Randy Silver :
I’m sorry, I’m definitely stealing that phrase. Barnacle customer, that’s brilliant Actually.
Itamar Gilad:
I learned this at Gmail because Gmail, while I was there, was making this massive switch in the back end, which customers, of course, didn’t need to know and didn’t feel, but they knew. But there were this set of customers with massive, massive inboxes and mailboxes that were very hard to move. They had a lot of messages and attachments and those were called internally the barnacle accounts and we had to scrape them one at a time and do some fancy manual work to transfer them into the new database. So just an inside story.
Lily Smith:
It sounds like kind of unheard of like thinking about Google employees just kind of manually moving female accounts for one place to another.
Itamar Gilad:
But anyway, it’s not manually, it was a script, but yeah it was. It was hard work.
Lily Smith:
Yeah, yeah. So I’m going to go a bit meta on you with the evidence guided in terms of, like, how people implement a change in the way that they do their planning, and if they were going to try and implement something like just and this kind of like evidence guided process, like, what evidence or experience do you have of people making that switch and and how have people done it really successfully? I know we’ve talked about some of the challenges, but what, what are some of the sort of success stories and what has happened in that business in order, you know, as an outcome of switching to this different way of working?
Itamar Gilad:
Great question. I actually list in the last chapter of the book some patterns that I observed that really help with the transition. And the transition is really hard, I have to say, because it goes against a lot of cultural and kind of best practices that we’ve been practicing for decades and I’ve seen also cases of regressions. So the company is starting to do the right things, it’s making progress, and then it gets a new CEO, a new CTO, a new CPO and boom, things regress. So try your best, but the statistics are not that good, unfortunately. One thing that I noticed is that those companies are not doing well, but those companies that do succeed are very focused on the sort of changes they want to drive. And because it’s such a wide gamut of changes because if you think about the changing the way you do goal setting, prioritization, developing projects and including actually discovery in this development and working with your teams and that’s what I cover in GIST, besides that there’s doing research and strategy and other things those are massive changes and it takes sometimes a company a year to really get to a good point. So being much more pragmatic about it and say the first problem we really need to fix is our goals, because we’re so misaligned, because we’re so siloed, because we’re aiming for too many things at the same time, because no one, that they stop in the hallway and ask them what’s the mission of the company or what’s the most important goal. No one can recite it. We have a problem. So let’s fix this, and this is usually a leadership problem at all levels. So, aiming for an all-star metric, a clear top business metric, creating your metrics tree and starting to use OKRs in a very sparse manner and what I mean by that is the company, entire company, mid-size company runs itself on three objectives and key results, three clusters, that’s it being very, very particular. That helps the organization tremendously because it creates this intense focus and alignment, the way goals are supposed to do. So that’s one step. So, focusing on goals or an idea prioritization, if that’s your main problem, or on the process of development and including evidence into it, or on kind of extraditing your teams from this agile jail where they’re just moving tickets to the down state Choose your battle. Where do you want to start? Another thing is find the right soldiers and captains. So you need someone at the top, you need someone at the exact level. So I’m going to start with the CEO, sometimes the CTO. I worked once with a company where the chief sales officer brought me in. He was from Amazon and the rest of the organization was working in a very old school way and he was a bit shocked. So he brought me in to try to help the CPO see some light, according to him right. So you never know who is your guardian angel. So it’s extremely important in working with other executives and reminding them what are we trying to achieve here, because on a day-to-day basis it’s so hard for them to just focus on the revenue and go back to the old ways. And inside the company, I would build also some task force or some sort of group that is helping teams across the board make the transition. Those are just some of the patterns that I’ve seen that help. I can go on, by the way. There’s others too.
Lily Smith:
Well, I just had one more question for you. I think we are running out of time, sadly, but as we on the podcast talk to more people and in my networks and everything, I feel like there’s a real movement in really understanding, being much more outcome-led and the whole product community has shifted from the early days of when I was doing product management. Everyone feels like it’s going on a bit of a journey and it does feel like everyone is beginning to understand and see the light of how to do that there’s a better way of doing things. What’s your sort of perception of that with the work that you do, are there still as many companies struggling with feature factory type ways of working where they don’t need to be like that and they actually could be more outcome-led and have more success? Do you feel that movement in the circles that you’re in, or is there still a real struggle in lots of businesses?
Itamar Gilad:
I agree with you, first off, that when I talk to at least the CPO level, there’s a deep understanding of the problems and the needs to change and the desire to do so, and many CPOs already are starting to change and they’re implementing some sort of framework. Sometimes it’s kind of a piecemeal thing that they are creating, just bringing different things that they believe in, or sometimes they take a wholesale solution off the shelf, but I see a huge struggle in actually making the transition. A lot of organizations are getting stuck halfway.
Lily Smith:
They make some of the changes.
Itamar Gilad:
They have OCRs, agile they already had for a long time. They have experiments, but things are just not clicking. The OCRs no one likes them. They don’t really work Experiments. They run three-quarter and they don’t learn from them. The experiments are being used as a kind of a stamp just to prove that this idea was good, and the teams are still disengaged and so on and so forth. So it’s really about there’s a lot of nuance in how to make the transition up to the critical point. I would say. You have critical mass, you have momentum and you are able to push the organization over that cliff and the way up is really hard. So that’s partly why I wrote the book.
Lily Smith:
And I guess the other part of that is something that you mentioned earlier, which was that regression that people do If they get to a certain point, then actually, if there’s a stumbling block or a lack of trust or a change in leadership, then it all just kind of regresses back to what people know when they’re comfortable with. And yeah, I know from experience of some of my friends that they, for instance, try to implement OCRs and then it’s just been a car crash. And then no one wants to do OCRs because they’re like no, that was terrible. So I guess it’s that if you don’t get it right the first time, then there’s a lot of damage to one pick as well.
Itamar Gilad:
It’s true. A lot of times when people say we do OKRs, they do a version of OKRs that I personally disagree with. It is way over-weighted, it is way cumbersome, it is super hard to do every quarter and then they get fatigued. So it could be that you’re not doing it the way it’s supposed to be. Again, my book. There’s some explanation in my book actually about this exact topic. Another thing I think it’s important to note this is a journey. This is not like an end stop. You do transformation, after that you transform. It’s like nilvana and from there everything is good. It’s an ongoing journey and it’s about making continuous improvements. That’s another one of these patterns. A lot of things, instead of waiting an entire quarter to improve the rate of experimentation, etc. They do smaller targets. In one month let’s try to launch double the amount of experiments we launched previous months. And just being on this path of self-improvement is very important for the organization and it is unlocking a lot of things that lead to the change over time. But you need to have the breath to wait years sometimes to really feel that you’re transformed.
Lily Smith:
It’s about on that note. We should wrap up there, but thank you so much. It’s been really great talking to you today.
Itamar Gilad:
Thank you, guys, and happy to chat again whenever you’re interested.
Lily Smith:
Always, the product experience is the first.
Randy Silver :
And the best.
Lily Smith:
Our hosts are me, lily Smith and me, Randy Silver. Lou Runn Pratt is our producer and Luke Smith is our editor.
Randy Silver :
Our theme music is from Hamburg-based band POW. That’s PAU Thanks to Arnie Kittler, who curates both product tank and MTP Engage in Hamburg and who also plays bass in the band, for letting us use their music. You can connect with your local product community via product tank Regular free meetups in over 200 cities worldwide.
Lily Smith:
If there’s not one near you, maybe you should think about starting one. To find out more, go to mindtheproductcom. Forward slash product tank.
Comments
Join the community
Sign up for free to share your thoughts