In the latest episode of Le Podcast on Emerging Leadership, I welcome back Gojko Adzic, renowned software development expert and author of Lizard Optimization. Gojko dives into an engaging discussion about his book, offering practical ways to identify hidden opportunities by paying close attention to unexpected user behavior—what he calls “lizard optimization.”

Below, I have summarized key insights to help you turn unconventional behavior into growth opportunities and foster innovation in product development.

---

Key Learnings

• Optimize for “Lizards”: Embrace unexpected user behavior as an opportunity. Often, these “lizards” (users who operate outside the norm) reveal gaps or hidden value in your product.
• Four-Step Approach to Lizard Optimization (LZRD):
  • Learn about unusual user behavior.
  • Zoom in on impactful behaviors to explore further.
  • Remove obstacles to support desired “misuses” that could offer value.
  • Detect unintended impacts of any changes to avoid compromising user experience.
• Focus on Problem-Solving Over Solutions: Avoid getting attached to your initial solution. Instead, support your product team in understanding real user needs, even if they diverge from the original concept.
• Organizational Insight from Desire Lines: Pay attention to patterns or “desire lines” where users—or even team members—create their own paths around perceived obstacles. This can provide valuable insights for better alignment of goals and processes.
• Adopt Controlled Experiments: Like tech giants Google and Microsoft, consistently test assumptions and validate ideas. Most innovations fail to deliver measurable value, so focus on learning quickly which initiatives drive the most impact.

Listen to the episode here or on your favorite platform.

1. “Build a Product with Gojko Adzic” – An episode of Le Podcast on Emerging Leadership
2. “Founders at Work” by Jessica Livingston – Stories of Startups’ Early Days
3. “Lizard Optimization“ by Gojko Adzic – Learn how to transform unexpected product usage into growth opportunities.
4. “Trustworthy Online Controlled Experiments“ by Ron Kohavi et al. – A foundational guide on using experiments to discover what truly works for users.
5. “Mismatch“ by Kat Holmes – Explore inclusive design and learn to recognize mismatches in user needs versus product design.

Here is the transcript of the episode

Alexis: [00:00:00] Welcome to Le Podcast on Emerging Leadership. I’m your host, Alexis Monville. And today, we are joined once again by a very special guest, Gojko Adjik. Gojko is a renowned author, speaker, and recognized leader in the world of software development. He’s been celebrated as one of the 2019 AWS Serverless Heroes, the winner of multiple prestigious awards, and the mind behind several influential books, including Impact Mapping and Specification by Example. In our last conversation, we dove deep into how to build a perfect product, how to avoid waste in software development, and explore the principles of impact mapping.

Today, we are excited to discuss his latest book, Lizard Optimization. We’ll be unpacking the core ideas in the book, how they apply to modern software development, and what it means [00:01:00] for leadership in an evolving technological landscape. Welcome back to Le Podcast on Emerging Leadership, Gojko. How do you typically introduce yourself to someone you just met?

Well, I say I’m Gojko, it’s like Beyonce, you know, it’s.

Does it work really well? 

Gojko: Oh, I guess so. I don’t know. I’ve never been in a situation where it doesn’t work because maybe people try to be polite to me. I’m a developer. I kind of build my own products. Now I write books mostly as a way of. Doing a brain dump so I can leave more space for other things. I stole that one from Henry Kniberg.

He said, kind of, he likes to do a brain dump to free up shorter memory. I think upgrading RAM in my head would be really expensive. It’s cheaper to write a book. 

Alexis: I love the way it’s said. I have to agree with that. When you try to write something, could be read by not [00:02:00] only you, but also by other people.

It’s really good to help you structure your own ideas. 

Gojko: Yeah, and it gets you to clarify things that might not be perfectly clear. It’s always fun. While I was writing this, my most recent ninth book, I was trying to hunt down some quotes in exact way, the way they were said. And I’ve realized that for years I’ve been doing conference presentations and quoting some people completely wrong.

I misremembered it the way I read in the book, but then read actually what they said and kind of, the meaning is there. I, I didn’t misremember the meaning, but Really shame on me for misquoting people. So yes, you get to consolidate your thinking and really verify that it’s still correct. 

Alexis: You spoke briefly about your latest book.

The latest book is Lizard Optimization. I would probably not have picked that book on a shelf. I don’t know anything about lizards. I’m not [00:03:00] really keen to optimize any lizard. That’s 

Gojko: your mistake as a leader. I think your job needs to be to watch out for lizards and support your product teams in optimizing for lizards.

That’s incredibly important. 

Alexis: So now you need to explain a little bit. You need to tell me what inspired you to write the book and what does that lizard mean? So what inspired me to write the book is 

Gojko: a really crazy growth phase for one of my products where the usage increased by about 500 times in a space of 11 months.

So that means that things that were weird edge cases that would happen once every two years now start happening every day. And the whole 11 months was a bit crazy and firefighting and things like that. But I’ve learned a lot and I wanted to pass on what I learned [00:04:00] to other people and maybe inspire them to investigate these things on their own.

And a lizard optimization is in a sentence, figuring out how people are misusing your product. And then figuring out whether you want to support that kind of misuse in a more systematic way, whether that should be done, or whether you want to block it and prevent it. And both of these things are valuable.

The one example I really like that’s not from my product, but I read this in a book called Founders at Work by Jessica Livingston. Was from a company where in late nineties, the company was started because some super, super smart people built some incredibly efficient cryptography algorithms. And they had a solution, but they didn’t have a problem.

We built this now what then somebody said, well, these are incredibly efficient algorithms, so they [00:05:00] can run on low power devices because they’re efficient. They’re not going to spend battery too much. And PalmPilot was a popular low power device there. So they said, well, let’s run something on PalmPilot.

What do you need encryption on a PalmPilot for? And they said, well, encryption brings security. You need security when, I don’t know, you’re transferring money. And then they build a system where you take your PalmPilot out of your pocket. I take mine and we bump it together. And money goes from my PalmPilot to yours.

That was wonderful. That was magic. And it was all insane. They had trouble getting people to know about the mobile application and to use it. Late 90s was a time where web was becoming popular and they built a website to promote the Pornpilot app. So as a way of getting people to try it easily and experiment, they had this really horrible, very rough demo thing where you could use the website to transfer money to somebody’s Pornpilot account.

And, [00:06:00] What people started doing is they were using the website not to transfer the money to somebody’s PalmPilot account, but to transfer the money to an account and opening it even without having PalmPilot devices. The product management was really furious with that because somebody was misusing their system.

They were not using it for PalmPilots. They had nothing to do with their brilliant app, nothing to do with These efficient cryptographic algorithms that were running on low power devices, because it was all running through the website. And people even started using the trademarks and the names on forums, like, Oh, send me money, buy this or something like that.

It kept fighting it. The product people kept fighting it. They were going in these forums and saying, you’re not allowed to use our name. We’ll sue you and fighting with the users. At some point, somebody looked at the numbers. The website had 1. 5 million active users and 12, 000 PalmPilot app installations.

And somebody who can do mathematics basically said, well, [00:07:00] this PalmPilot thing is really not as popular as the website. So they kind of killed the PalmPilot app and the web app became PayPal. That today is known as PayPal. PalmPilot no longer exists. And we do have. Low power devices and things like that.

And PayPal runs on mobile phones. And of course, you know, you can, I don’t know if you can transfer money by pumping it, I think that’s like a weird gimmick, but it’s used to transfer money all over the world by doing this PayPal pilot bump, you have to be next to somebody and you, now you can use PayPal to transfer money somewhere, halfway around the world in a different time zone.

And I think that the really interesting lesson there is that the product managers fought against users for a very long time. They fought against this misuse. They fought against people actually trying to benefit from the product in a different way because it wasn’t consistent with their vision that they were trying to stay true to the vision, not true to solving the problem.

And I think this is where people fall in love with the solution, not with [00:08:00] the problem. And, and I think that’s kind of one of the biggest issues product companies have. So I think as a leader of a company and your, uh, listen as a leaders. Helping your product, people like focus on solving the problem. Not loving the solution is really, really important and noticing when people are misusing your product.

It becomes important both for unlocking growth and for understanding where the market wants this product to grow, because it opens up some incredible growth opportunities. If the PayPal stayed on the Palm Pilot app, they would have had 12, 000 users and that’s it. They would have never made a kind of a decent company out of it.

And I think this is what becomes really interesting. Lizards in this terminology are people who do things that you can’t logically explain. It looks like it was done by somebody who’s not a rational human. They’re doing something you didn’t expect. They’re doing something you don’t want, but they are effectively misusing the system.

Now they might be [00:09:00] misusing the system or trying to misuse the system in a good way or a bad way, but kind of figuring that out becomes, I think, critical for good product management. 

Alexis: This is very interesting because yeah, you, you take the examples of product managers fighting against misuse of the product.

Just noticing that something is going on is already something important. And I, when I read the book, I was there and was looking at that to say, Oh, I don’t know if I would have noticed that. And the example of that video that is blank. How would 

Gojko: you even know? And that’s really an interesting thing. So, for example, one of the products built allows people to upload different types of documents and create an audio file using text to speech.

So, when users do something unexpected, like trying to upload an unsupported file type, they will get a decent error message. I set a number of people every day that try to upload MP3 files into a text to [00:10:00] speech system. I don’t understand why you would do that, what you expect, how that would even work.

Converting audio to audio, you’re not converting text to speech. It’s weird. There are people who try to upload Android package files every day. I, I don’t understand how you would do that, but occasionally there’s somebody who kind of does something potentially useful. Now, with the error message that people get, Oh, you know, you’re, you’re uploading something that is not text.

We can’t read that. In addition to showing the user an error message, I get a message. I get a log message that I can expect that somebody did something I didn’t expect. Now, I started noticing a pattern, uh, about a year ago where people were trying to upload subtitle files. Subtitle files come with video files, they are subtitles for a movie or, or something like that.

And, um, they’re text files, they’re not images, they’re not Android packages, they’re not [00:11:00] music, they are text files. So I thought, well, I didn’t expect this extension, but why not? I can just enable that extension in addition to txt and I enable that and then I started getting complaints from people saying that, uh, the system also reads the timestamps.

Subtitle file said timestamps when to show certain text. Yeah, you’ve uploaded a file with timestamps. What the fuck did you expect? It’s, it’s kind of reading the timestamps. It reads the content. But yeah, I wasn’t expecting it to read the timestamps. I was only expecting it to read the kind of voiceover.

I said, well, I can understand that. So it took me five minutes to just skip over the timestamps. And then people were complaining that it reads the text too slowly. It’s like, what do you mean too slowly? It is the text at the speed of it reading the text. I mean, and then I realized talking to people what they were trying to do actually, you know, in the jobs to be done category is they were trying not to just convert text to speech a step there.

But what they were trying to do [00:12:00] is to create an alternate audio track for their presentation video. And instead of creating lots of short clips and then aligning them themselves, what they were hoping to do with the subtitle file is to get the whole thing synchronized. Now, it was, you know, logical. I see the value in doing that.

It was a very tiny percentage of users doing it, but it was a small change. It was a technical challenge. It was interesting to do. So I did it. So in total, you know, we’re talking about two days of work in total, building on top, by far the most profitable thing I’ve ever done. By far, what happened later is that these features were discovered.

Like there’s an American mega church where they have these sermons, religious lectures, whatever. And then they want to have them in all the languages on earth. And they’re using my system to. [00:13:00] Somebody types over the subtitles or I don’t know how they produce them, but then they just use the subtitles to create alternate audio tracks for the priests kind of preaching.

There’s an enterprise software company that’s using this thing for all their instructional videos. To basically automatically get an alternate. So if you’re a, if you’re a video content editor, usually what you would have to do with this is either try to record your voice or get somebody to record short clips and then suffer through hours of placing the clip at the right place in the video, where with this thing, you get it almost instantly.

And it saves you hours and hours and hours of time. And if you save somebody hours and hours and hours of time, they’re willing to give you some money for it. Especially if it’s automated, then they can do it at scale. So although this feature is used by like a tiny percentage of my users, it’s probably contributing a decent percentage of the revenue where the most kind of profitable customers we have on the tool are actually using it for that.

[00:14:00] So that’s the value of. Lizard optimization. I would have never guessed this without monitoring for weird file types that people are uploading. And I would not have done it in user research because I would not be doing that kind of research. I would be interviewing people who need something else done.

And I think lizard optimization is a wonderful way to complement customer research and user research and discover the unknown unknowns. You know, you can discover through customer interviews and user research, you can discover known unknowns. You kind of, you know what people want to do, but you don’t know the details and how important something is or what, but this is really helping us deal with the unknown unknowns.

And this is really interesting because it can open up a completely new market segment. It can show you that people want to go in a totally different direction. And maybe you don’t know that. And you need to consider it. And I think that’s why I think this is [00:15:00] such a powerful method to use. 

Alexis: It’s interesting because we can apply that in a lot of different things.

So of course, when you’re building a product, it’s kind of obvious, but my temptation was to say, okay, how can I learn that someone is doing something unexpected? Because as you said, in user research, you’re coming with your own assumptions about what is going on and you’re asking questions, you try to validate your assumption, but there it’s way more powerful because basically you’re trying to be on the lookout on what is going on and what are those things that you can brush saying, Oh, those users are completely idiot or maybe they just have a brilliant thing that I can solve in two days of work.

That’s very interesting. How do you see that? Do you have a, do you have a kind of structure to help people understand how it works? 

Gojko: So I think the process itself, I’ve kind of nailed it down to four steps to use myself. And the four steps are easy to remember because they start with the letters LZRD, like lizard, [00:16:00] The first step is to learn how people are misusing your product.

That’s the L, learn. Then the second step is to zoom in on one behavior change. You can’t change everything. And when you start looking for weird stuff, there’s a range of incredibly weird. We’ll never understand it to this kind of makes sense. And it’s going to be a lot of noise and we need to figure out the signal in that noise.

The zooming in is the second step. The third step is to remove obstacles from users. And the, the software is placing obstacles in front of users and not letting them do something they wanted to do or the product. And that’s why they’re misusing it. Some obstacles need to be removed for them to be able to do that.

And then the last step, the D. Is to detect unintended impacts because these people follow their own logic. They don’t necessarily follow my logic or your logic and our assumptions about how we’re going to fix the problem aren’t necessarily true. Like I said, my first idea was, okay, just [00:17:00] support the file.

That’s okay. But then there was an unintended impact where people were starting to complain and we increased support because we were reading all the timestamps and things like that, lots and lots of times where I thought this is going to be a good idea. didn’t turn out to be spectacularly good. 

Alexis: Can 

Gojko: you 

Alexis: give me an example about that?

Gojko: Yeah, like in European Union, kind of, there’s like VAT numbers. So with VAT numbers, uh, you need to enter a VAT number for the receipt. And with the digital product, If you’re selling things to individuals, you have to charge VAT in the country where the individual is. If you’re selling to companies, you don’t charge VAT.

They have to account for that using reverse charge magic and things like that. Now, without going too much into the accounting details, companies want to put their, or people purchasing for business, want to put their VAT number in. If they put a VAT number in and they’re doing it with domestic transaction, they’ll usually just put the number.

But if they’re doing it in a foreign [00:18:00] context, they’ll put the country prefix. So FR 12345 is for France. And the payment processor I use is done by an American company. They don’t understand all of that. It’s too complicated for them. And they’re trying to validate these numbers. But very often they, even if you selected France and you entered one, two, three, four, five, it’s obviously the French one, two, three, four, five number.

What they’ll tell you is, Oh, this is an invalid VAT number. It’s not, it just, you’re not storing it correctly. And I can’t do too much about their validation. It’s their validation. It’s third party product. But what happens is I had a percentage of a good percentage of people. People that go try to purchase, they enter 4, 5, this thing tells them it’s an invalid number, and they think it’s the card number, not the VAT number.

So then they added the card number, it fails, it fails again, and, and, and, so a ridiculous number of people from European Union end up selecting Russia as their country because Russian VAT numbers don’t have a prefix. It is, it is ridiculous just to enter the thing to, like, [00:19:00] I’m placing an obstacle in front of them trying to pay me.

This is idiotic. So I thought, well, you know, let’s solve this and all that can’t control the validation on, on the form. It’s done by the payment provider. I can remove the field altogether. And then when they pay, I can say, okay, now to get an invoice, give me a VAT number. And then I can say, well, you’re in France, obviously the prefix is FR.

I did that. And then I measured where the people are paying me more. And it turns out people are paying me less. 

Alexis: Uh, 

Gojko: Uh, yeah, so unintended impact. So what had happened is I thought I’m going to solve it, but actually people that wanted to pay for the company, they go to the form where they couldn’t put in a VAT number and then they didn’t pay.

They were confused. They, they expected a place to put a VAT number in, and the number of payments dropped significantly. So I had to kind of go back and, and, and do some other stuff there. So that’s kind of an example of an unintended impact where [00:20:00] something that’s, you know, to me as a maker sounds perfectly logical to a user might not, or to a user of a certain type might not.

And this is where I absolutely love, you said users are not that smart and things like, I absolutely love this book by Kat Holmes called mismatch. Because she rephrased this whole thing. It’s not that the users are stupid or smart or whatever. It’s kind of, there’s a mismatch between the user’s capability and the software.

Now, that mismatch might be something we want to do something about or not, but we need to understand it as a mismatch. There’s, uh, people that, Expect the VAT field to be there and the VAT field is not there. It’s a mismatch of expectations. People that the user interface is very complicated, a developer can use it, but a regular person who’s not a trained developer doesn’t follow that logic.

You can blame the user for being stupid, or you can say there’s a mismatch between what the user is expecting, their experience, the software. [00:21:00] Likewise, there could be a mismatch. Like. Visual capabilities. You might have somebody who’s vision impaired. They can’t read small letters, or you might have somebody who’s sitting on a beach under direct sunlight, and there’s not enough contrast on the screen.

There’s a mismatch between the user situation and the app and the solution. And I think identifying these mismatches allows us to then talk about Do we want to solve it? Do we not want to solve it? Do we care about it or not? I mean, I, maybe I can’t build an app that works fully for blind people, but I can make an app that works well with somebody who’s elderly and has bad vision.

And if I do that, I will also make it so that people on the beach can read it or, or, you know, if they were in a dark environment or something like that. And, and, and Kat Holmes talks about how You don’t necessarily follow each of these really difficult edge cases because that economically doesn’t make sense, but you figure out how to solve that and at the same time improve the product for everybody.

Alexis: [00:22:00] You have a small population of users that could be affected by that if you look at it from one angle, but in reality it will help a large group of your users. 

Gojko: And you just think, yeah, you make a better product. Like, for example, a couple of years ago, we had a bug report for MindMap. MindMap is one of my products.

It’s a collaborative diagramming mind mapping tool, and we had a bug report that it does not work well on a refrigerator. Okay, well, I mean, it doesn’t work well if you put it on a microwave as well. It’s not intended for that. It’s intended for computers, not for kitchen utensils. You have these weird things where people play Doom on a microwave screen or something like that.

How did you get my software to run on fridge? That’s the first question. A woman who stayed home in the mornings to take care of her children, this was before COVID and work from home and things like that. Because our software requires a large screen, it’s kind of a [00:23:00] diagramming thing, uh, running it on a phone is not really an option, but keeping a laptop opening the kitchen when you’re cooking is also not necessarily the safest thing to do.

You can damage quite expensive equipment doing that. So she actually had an Android screen on the fridge that had a browser, but you don’t load it up there, but the software just did not work without the keyboard. It required the keyboard to work. So it didn’t work that the problem is not that it didn’t work on a fridge.

The problem is it was useless without the keyboard, really, because we never really thought about people using it without a keyboard. Or a pointer device or something like that. So instead of making it run on a fridge, which was pointless, one user in 10 years complained about that. We thought about, well, maybe there’s a whole class of people who are not at the keyboard at the moment.

Maybe there’s a whole class of people who just need to observe rather than Participate, because she wanted to observe the collaboration that her colleagues were doing. Maybe [00:24:00] there’s some stuff we can do, like changing it from a floating toolbar with really small buttons to a really large toolbar with big buttons that you can control and things like that.

So we iterated on that. And I think we came up with a much, much better UX design for the app in general, not just making it work a better on a fridge. So it works better, even if you have a laptop and a keyboard and a mouse, it still works better for you because we challenged ourselves to improve the UX.

Alexis: Yeah, it’s, it’s very interesting. So that was one person trying to do something, but as a result, because you observe that very carefully, you realize that could affect and improve the product for basically all the users. It’s very interesting. It’s not only discovering new use cases or probably new personalized or new possibilities of development for the product.

It’s really improving the product overall. So there’s, that’s another class of, uh, 

Gojko: Kat Holmes has this principle in her book talks about solve for one, expand to many. And that’s really important [00:25:00] because especially if you look at kind of lizard behavior, these are like really, really weird things that go on, but solving and doing things for such weird edge cases, it’s never going to be economically justifiable.

I mean, you can look at a product manager, looks at the weird edge cases. Well, this is like, 0. 1 percent of our users. I can’t spend time doing this. I have to spend time doing what 80 percent of the users expect, but it’s not about helping that 0. 1%. It’s about using that as signals that your software is placing obstacles in front of people and then figuring out, well, maybe there are some obstacles in front of other groups of people as well.

Alexis: I love it. How would you translate that into other things than software development or building products? You have a leader or an emerging leader. How would you translate that in the realm of an organization or a team? 

Gojko: Well, that’s an interesting question. You know, I think, uh, quite a related concept from outside of software is those kind of [00:26:00] desire lines, desire lines are from usability research and things that where you try to figure out, I think there was a story about this university where they built a new campus instead of trying to figure out where to put the.

Walk paths and, and the roads, they just planted grass and let students walk around stepping on the grass. Then they figured where the grass was stepped on and built the pathways there instead of trying to predict where the pathways are going to go. I think from an organizational perspective, that’s something that we can figure out.

What do we want? our employees to do? How do we want to support them? How as a leader can I support people in what they want to do, not what necessarily we think they want to do? I remember one kind of really weird case, maybe it fits into this, maybe it doesn’t, when I was working with hedge funds or small investment banks.

Small in this case means about 3000 people. So not [00:27:00] massive international giant, but not a small company as well. And they had a couple of hundred developers and we were trying to help them improve the software process, but whatever we suggested, it wasn’t improving productivity because the bottleneck was somewhere else from the systems thinking perspective, the bottleneck was somewhere else.

And then we’ve done a kind of figuring out where people feel that they’re wasting time. One of the things where lots of people felt they were wasting time was waiting for virtual machines to start. The morning, everybody comes at the same time and they had this recent policy where for business continuity reasons, they were not allowed to keep any data on their physical machines.

Everybody had to use a virtual kind of remote Citrix. So everybody comes in at the same time. They kind of, you know, start logging on to this. They didn’t have enough capacity and they were waiting for something ridiculous, like 40 minutes in average for access to these things because it was new and imposed, people were complaining, but they were just getting shut down because it’s for [00:28:00] whatever, for reasons.

The leadership introduced it and we realized, well, the introducing things like continuous delivery, test driven development, whatever, it doesn’t matter really, because your bottleneck is virtual machines and they were limited by the amount of hardware they had. But developers time in a financial institution in central London is quite expensive if you think about just in salaries.

So we added up the money. We went to the CIO and we said, look. You are spending this amount of money every month on people just waiting for virtual machines to start. With this amount of money, you know how much hardware you can buy. Can we please use some of that money and buy more hardware for virtual machines?

And then he said, of course we can, it’s logical, but why are people waiting for virtual machines to start? Like, why are developers doing that? So, there was a company wide policy, everybody has to use virtual machines, business [00:29:00] continuity. And he said, yes, everybody, like traders and not developers, like developers don’t store data on their machines anyway, it’s in version control.

Okay. So you want to do, I said, well, it’s idiotic. Why are you just killing productivity from people? So there’s like a totally different desire line there. There’s a different path. And I think this is an example of the company misusing its own people. I guess because when they said everybody, they didn’t mean developers.

So I think as a leader, it’s important to kind of figure out Both when misuse is happening in one way or another way, and where if you have people that are trying to treat the system in some way, do we want to actually support that or not support that? How do we figure this thing out? And if we’re placing obstacles in front of people, are those obstacles intentionally there because sometimes they are.

Or those obstacles are [00:30:00] intentionally there and then they should be removed like this policy where basically, yeah, if you have version control, you don’t have to use a virtual machine. Makes total sense. 

Alexis: So lastly, what would be the one advice you would give to your younger self? 

Gojko: One advice I would give to my younger self, I think that would be in terms of just product building, not to trust that things I do actually have value.

And to try to validate it. I think I’ve spent far too long in my career trusting that the things I do are actually good ideas. And very often they’re not. I’m not alone. I love Ron Kojavi’s latest book called Trustworthy Online Controlled Experiments. Here’s data from companies like Microsoft, Google, Slack, Netflix.

The data says that kind of between one 10th and one third of things they do actually [00:31:00] delivers value. 

Alexis: That’s okay. After that, you need to be a little bit more humble. Okay. 

Gojko: That means that these people who are supposed to be industry leaders kind of Between seven out of 10 times, things that they think are good ideas are not necessarily good ideas.

Alexis: Okay. 

Gojko: They don’t, they don’t improve the product in a measurable way. And with something like that, I guess it’s really interesting to think as a leader or as a, as a product manager and executive supporting product managers, what brings value to the market so we can capture some of that value, uh, back because If we’re not delivering value to the market, then we can’t really capture the value back from the users.

And if we can’t figure that out, then we can run circles around the competition because the bad news for most listeners that have never thought about this is that, well, I’m just going to stick the range in half there. So eight out of 10 things you do make no sense. But the good news is that eight out of [00:32:00] things your competitors do.

If you can figure that out faster than the competition, you can create a much better product. And I think that’s why these companies are winning in the market, because they can figure that out and they can understand that they can measure it. They can stop bad ideas from progressing too far. 

Alexis: This is very insightful.

for sharing that. 

Gojko: Trustworthy online control experiments. Wonderful book. Wonderful book. 

Alexis: I will add the references in the companion blog post. Thank you very much for having joined the podcast, Gojko. 

Gojko: Thank you!