Product Agility

Winning with Feedback: Building Products People Love (with Ivett Ördög)

• Ben Maynard & Ördög • Season 2 • Episode 43

Share episode

Send us a text

In this first episode of 2025, the Product Agility Podcast is back with a bang! Ben Maynard welcomes Ivett Ördög, a seasoned engineer, product leader, and creator of the innovative Lean Poker workshop, to explore the transformative power of feedback in building products that people truly love. With over three decades of coding experience and a unique blend of leadership roles, Ivett brings practical insights and strategies to inspire both engineers and product managers to move faster, learn smarter, and collaborate better.

If you’ve ever struggled with aligning your team’s efforts with customer needs or felt stuck in the endless cycle of development without clear outcomes, this episode is a treasure trove of actionable ideas.

Key Takeaways:

  • From Feedback to Impact: How early and frequent feedback can shape better product decisions.
  • Building Trust with Users: The importance of creating a feedback loop that empowers both teams and customers.
  • Adoption as a Metric: Why feature adoption rates are the ultimate indicator of product success.
  • Gamifying Learning: How Lean Poker accelerates team learning through rapid experimentation and iteration.

Practical Tools & Methods:

  • Feedback Loops: Building trust by acting quickly on user feedback.
  • Lean Poker Workshop: An immersive, gamified workshop for mastering incremental delivery and experimentation.
  • Metrics that Matter: Identifying and tracking adoption rates to maximize value.

Links and Resources:

Start the new year with a fresh perspective on feedback and delivery! Whether you’re a product manager, engineer, or leader, this episode provides actionable insights to help you create products that truly resonate with users. The Product Agility Podcast is back, and it’s better than ever! Don’t miss it!

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


Want to come on the podcast?

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

AI is a game changer despite being a fancy auto complete, but the things that it cannot help you with, it's more interesting. The things that it can help you with and the thing that it cannot help you with is understanding your user and understanding what they need. Welcome to the Product Agility Podcast, the missing link between Agile and product. The purpose of this podcast is to share practical tips, strategies and stories from world class thought leaders and practitioners. Why I hear you ask? Well, I want to increase your knowledge and your motivation to experiment so that together we can create ever more successful products. My name is Ben Maynard and I'm your host. What has driven me for the last decade to bridge the gap between agility and product is a deep rooted belief that people and products evolving together can achieve mutual excellence. Hello and welcome to the Product Agility Podcast, The very first episode of a new year 2025 and we are joined by somebody today who has a YouTube channel which is very good and much more popular than my YouTube channel. So be sure to go and check that out. After this episode, we will give you a little plug. The YouTube channel is called Next Increment. Yvette is the creator of Lean Poker, something which hopefully will get the opportunity to delve into a little bit more during this episode. And also someone who's got over 30 years of coding experience as well as having 10 years experienced working leadership positions in the types of organization that I'm sure you and I have all worked in. And so it's a great pleasure to kick off 2025. We're such a strong guest. Yvette, welcome to the podcast. Hello, and Happy New Year to all the listeners and you. Thank you very much. Thank you very much, Yvette. See, I spent so much time practicing it and my 20 or 32nd limit of being able to repeat it as part Erdog. Perfect. Nice. Which is Hungarian for devil, you say? Yeah, Yes, it is. It is the same burden. There must be an interesting story there, but not one for this podcast. Maybe one for a different podcast. In fact. Would you mind telling our listeners a little bit about yourself? I'll give you a little brief overview, but would you mind just adding a bit of colour to it? Yeah. So I care a lot about delivering incrementally and that that might be some boring at first. But the story behind that is that I started programming when I was eight years old. And by the time I was in high school, I started having these freelance gigs. And it was the 90s, right? Everyone needed the website and I learned PHP very early on and I figured out that I couldn't. For some reason I couldn't get my PHP environment up on my computer. And I figured out that if I go and use SSH and go on the server, I can edit the code there. So I don't even need a copy of the code. I can edit directly everything in in production. I wouldn't advise anyone to do that by the way. This is just a genius move, surely. I mean, I think I mean I I definitely did that for a year or so and it got to the point where I kept on messing things up so badly every now and again that control Z stopped working. You know, like at some point I stopped doing that barely. Please carry on Yes, I mean controls that that assumes that you're using some fancy editor. I was using whim. Oh, don't even don't. That's why start talking about that for now. Can I please carry on a bit? Please carry on. OK, OK, so so at that time, yes, that's fairly irresponsible. But at the same time I learned something very important and that was like I was working on a social network that was pre Facebook times, or at least Facebook was really young and I was working on this social network and I had a bunch of the users on my ICQ. That was a messaging platform for those of you who are not as old as I am. And, and what happened was that my users gave me bug reports whenever I screwed anything up, but not just that. They, they immediately noticed when I made a change and it improved their lives. So programming for me in those early years was going in editing a bit of code in PHP and then immediately hearing from the customer, immediately hearing from the user and, and figuring like it was really easy to figure out what they need because they would tell me they, they knew that if they tell me what they need, I would react and within a few hours they would have that have a new feature. And then I moved into corporate, right. And the first proper job I had was at the company where they didn't, didn't just not release for six months. That's, that's an understatement. The code wasn't compiling for six months. Like we had a nice beautiful diagram of the changes that we need to make. And while we were making those changes, the code wasn't compiling. Now imagine the pain that we had to go through to integrate that together and to then publish it only to learn that the user didn't really want that. So for me, that's kind of the the thing that I care about most ever since is this. How do I find out what the user actually needs and from an engineering perspective and and how do I make sure that they get it as soon as possible and that I don't have to go through all the pain of doing a lot of work and then learning that they didn't need what I want, but I built them. It's actually that becomes. Harder to accept, I found when you are working in a small team or on your own and resources are scarce, you haven't got a lot of time or money to be spending on consistently doing the wrong thing. So how can we learn earlier? And I think it's even more disheartening, but maybe financially a little bit more viable when you're not releasing, when you've got a big organization behind you and you're not releasing frequently for a while. Oddly, you know, we can get away with not really satisfying the customers and just plodding along with mediocre stuff or stuff that really doesn't hit the mark. And yeah, when we were warming up for this chat, you did ask me what would be a good adoption rate. And I was thinking, well, yeah, for a new feature. And I thought, well, do you know if good. Good. Hey, what about me? Happy is it 50% of the target users were using the thing that I produced. And then you rightfully said me, that'd be excellent. Just be good. That'd be pretty phenomenal. And I thought that you're right, you know, I am, I'm detrimentally optimistic. And I think the sand truth of the matter is so much of what we put out there doesn't hit the mark. And if I, you know, talk to my and some of my agile friends or yeah, also my product friends who listen to this, who are looking for jobs and out in the market. Actually, when we think about how do we go about securing new positions or how to differentiate ourselves in the market. I think one of the things that we can all begin to do is talk about the money that people are leaving on the table by not delivering things that people actually want to use to get their job done quicker because really, but that's what we're talking about here. So today's conversation, I think at least to begin with, is let's talk about that. Let's talk about the money that's left on the table. Let's do it to different things that aren't useful. And I know you've got some advice and some stories to share with us about how we can better understand whether or not the idea that we've had our hypothesis is going to pay what we need it to pay. Yes. So I think what, what's the most important here is, is this distinction between or the difference between working on something for a long time and not really asking because I think that the, the information is out there. We could potentially build things that every single user wants to use, or at least 80% of the users want to use. Because what happens is like, it's very rare that there is no feature that everyone needs or most users don't need. You just need to figure out what those features are, right? And to, to get there, what you need to do is to build the kind of trust with your users where they want to tell you what they need so that you don't have to go out and gather that data with lots of effort and pain, but the data comes to you. And, and I think first and foremost, what you really need is to create that trust in your users that they, it's, it's worth telling you what they need and to build that trust. I think so there are two main advantages to, to getting out with your product early and often. One is of course that you learn sooner if they need it at all, but also when you make a change and you deploy it early, something that the user just asked like 2 weeks ago. Like imagine being that user, you just thought someone that you need something and within days or weeks you suddenly notice that it's available in the product. How does that make you feel when I experience as a user that as a user I that's build my that be as my trust, right? Yeah. But I think it makes you feel part of something bigger because maybe think about Maslow's hierarchy of needs. And although I can't remember what any of them are, I'm pretty certain there's wrong on there about belonging or something. And I think that, you know, it makes you feel special. It makes you feel like you're part of something more, you know, And also that if you've asked for something that it's like someone saying a pat on the back, you know, it was, it was a good enough thing to share with us. So we've done something about it. And that's really rewarding for us as a human. Yeah. And maybe we can even take a page out of the YouTube playbook here. As mentioned, I'm a YouTube. And one of the things that they teach you, if you go into one of these YouTube accelerator programs or anything like that, where where, where they teach you about YouTube. One of the things that they teach you early on is that when you're a small YouTube, respond to every single comment when you are a bit larger YouTube, then try to respond to your most enthusiastic fans. And here's a here's the thing about that. The reason we do that as Youtubers, it's two reasons, right? One, I want to be a trust again, coming back to this, I want you to trust me. And the other thing is by interacting with people, I have a much better chance of figuring out what they want to hear about on my YouTube channel or what features they want in my product. So avid listeners maybe think of it, this actually sounds similar to the episode Pepper Gordko Adject, where he was talking about his idea of lizard optimization, which is kind of different to what you're saying in a way. Because what Gordko was saying was that he uses the the misuse of his product as a way of having users tell him what they want rather than treating them as like bugs to fix. He was yeah, it's a case of a, or it's a process of looking at saying, well, these are maybe things that I could build, which really embraces the way that people are perceivingly misusing this great thing that I have built. So. Well done, listeners. If you've kind of made that connection, that's fantastic. And what we're saying here is actually it's going out and talking to users and understanding things. Understanding is the thing they thought we're going to build, going to yield to the value that we fought. That's what we're saying here, isn't it? Yeah, absolutely. And I guess when you mentioned Goiku's topic, I just, I just suddenly had these memories of meetings everywhere discussing how the user misuses our product and how do we stop them from it and, and how do we guide them towards the right way. And I think there is this like this difference in mindset. I think that's a whole other world, right? And I think that as engineers, we are even more prone to this kind of thinking because as engineer, we, we like to think logically. We have a model in our mind. And when that model is challenged by the user, we, our instinct isn't to say my model is wrong. No, what we usually say is the user is stupid. And that's the exactly wrong thing to think about. And that's kind of what I find is one of the hardest things to teach engineers. This mindset shift of reality is what I want to pay attention to. And then once I once I learned about reality, I can adjust my model to that reality. And that's like teaching. That is the whole business that I do with Lib Booker. Yeah, that's an interesting one because this is a big challenge. It's the one you are faced with situations where you've got all the enthusiasm and you really believe that this is a good thing to experiment with. Yeah, just go and just just get data from users. Let's try and evolve our mental models that we've created about about the context, about the the domain that we're working, but we think people may need. Let's actually go and talk to some people and get some feedback and see if we can evolve that model when people just don't want to. Yeah, because for whatever reason and how does how do you deal with it then using something like lean poker or other techniques? So how do you take people on that journey? Yes, so and, and I, I completely feel what you are saying there. There is I think Dan N said something about not having an emotional connection to your code and and at the same time, when we when we get this information, it feels like someone is judging our beautiful code. How dare you? And and getting over that mindset. I think So. What would I do with Lynn Poker is this is a gamified workshop And what I realized was that if I try to teach people, like I tell them all the advantages of continuous delivery and dev OPS and all these things, they understand. But often there is like there's a surface level understanding and not a deeper connection with that, with those learnings, right? And what I realized is that arguments or or reasoning doesn't change people's minds, emotions does. So the question is how do I create those emotions that make people realize that finding out early about the outcomes is valuable? And then I basically created a gamified workshop very briefly. We have teams of engineers building poker bots. So we are playing, that's already a strong and emotion fun, but it's not just about fun because what we do is these poker bots are playing even before they started coding. And the goal of the teams isn't to collect like build the best poker bot by the end of the day. No, in eight hours, whatever poker bot you're going to build is going to be terrible. Like it's going to just play poker less horribly than the average, but but but that's the best you can achieve. So your goal isn't to be at the perfect poker poker, but your goal is to stay ahead of your competition. And the way you do that is you make a change, see what effect it had on your numbers. Like here you have very clear and obvious numbers that you see how many of the games did I win? You can actually go in and figure out why you won and why you lost, and then you can form a new hypothesis. Maybe we were too aggressive in this situation, or we've earned enough aggressive at that in that situation. So you have this back and forth. An average team, like real engineering team in a real company, if they deploy once a day, that's good, right? In limp occur, an average team deploys between 30 to 100 times during that single day. Now why is this important? It is important because what they learned there is like one, they have a much shorter feedback loop. So whatever process issues they have as a team will be visible in eight hours instead of six months. Imagine the gain that we have from that. Like we can improve on that team right away, the next day and not in six months. But that's just one side of it. The other more important side of it is that the team suddenly forms this emotional bond where or or emotion emotion of I want to win. So to win, I need to figure out how to how to get as much information as I can and how to act on it. And with that strong emotion, people would just instinctively start to use the practices that we otherwise teach them for weeks and they don't really understand it. Here they are learning it in a day and they figure it out for themselves. So it's a lot more sticky knowledge. So that's kind of my, my trick. I usually start when I work with teams. I start with running a limp poker for them and then asking them, OK, this is what you did. Why don't you do it like this all the time? And then it it just becomes a mostly hands off coaching to to get them to do that in their daily work. Yeah. So winning is what they realise is that winning and people tend to like winning is about being able to act upon the newest and relevant, most relevant information quicker than other people can. And I suppose an element to that of saying with us also being able to identify what that information is and being able to filter out the information that maybe isn't useful. But you're really kind of imbuing in people this idea that if we can get relevant information quickly and we can act on that information quicker than the competition, then we can win. Yes. And basically what I have seen happen time and time again with teams that we have worked with is after, like you said that 50% is excellent when it comes to adoption rate. These teams after playing meme poker and after adopting these practices can regularly reach 70 to 80% adoption rates, which is phenomena like this is something that we would want to strive for, right? And and just imagine the amount of money that we are leaving on the table by not building the things that people need. Because that that converts to customers lost. Yeah. So I mean, it sounds, it all sounds very easy. It isn't. What's been in your experience, what's been the the biggest challenge you've overcome in relation to kind of, I don't know, getting people to really kind of live by this. So I think that making, making people want to live like this or live by these rules is easy. The hard part is when they need to learn how to do it at large scale. Because the big difference between like the play environment of limp poker and reality is that limp poker is a very clear cut environment, right? The metric is super simple and, and, and the complexity isn't that big. Like you have a very set set of rules and you know the rules in real life, you don't know what the customer wants in real life, you don't have one clear metric in real life. It's much harder to figure out what's the smallest things I can see, think I can do that is still valuable. So once we get through this first step of wanting to work like this, and I think this is this is the hardest step and this is the part that I'm making easy. But once you get through that, then you have to learn how to break stories down. Then you have to learn how to tell apart a vanity metric from metric that actually matters. You have to learn how to talk to your customers and how to seek out that feedback. You have to build up the trust towards your customers, right? There is all these things that you still need to do and and scale up this to a larger organization. So I'm not saying that after lean poker overnight things will get much better. No, but it is a trigger. That can help your engineering organization want to move in that direction. And after that you you can start doing the the hard again now hard work of actually learning how to do it in real life and not just in the import. Have you ever come across a challenge that's just been insurmountable, like one which you just couldn't overcome, technical or, or, or or otherwise? OK, so I wouldn't say that it was a challenge that I couldn't work on. It was more like a surprise that I didn't expect. So I once got in trouble with one of my clients because I, I do, I did what I do. I thought my engineers what how to, how to build products with higher debt from rates. And the team started to say no to the to the CCCTO like they were like, no, the data doesn't say that people need this. We understand that the competition is building it, but the competition is wrong. We have the data, we know how what to do. We build all these things that had high adoption rates. Why don't you trust us? And then the CEO was really upset with me because I, I told their engineers to rebel against him. I would say that like that's, that's the biggest, like that can be an insurmountable problem when the leader doesn't understand what they want and, and, and that kind of situation, that can be hard. And honestly, at that point, I just let that let that organizing session go because I don't think I can help them until the leaders mindset changes. But but that's, I think that's the that's the hard part. When when there is, there isn't. Highly influential person in the way that's hard to come fix. Yeah, it is. And I feel you're quite courageous walking away from the situation is, I've always said it's probably one of the best things to do. Because when you got somebody who is very confident in their own ability or very not confident but wants to stick to the thing that they've thought was the right thing to do because they don't want to show any weakness or something, or they've just got all carried away in it. You know, I think as an external person, there's not a huge amount you can do often to influence that because they they, they, they're going to do what they're going to do. So being able to walk away was a reasonably courageous thing. And was that, did you actually then just step away from that quite entirely? Yeah, I I absolutely did simply because it's not it's not worth my time and I don't need the negative review, right or the negative advertisement around it. In that situation, the best you can do is just say, OK, that's maybe I'm not the person you need and maybe you need someone else to work with you. Honestly, I think that in this specific case, the question is, is your goal to build an organization that satisfied the user, or is your goal to be an organization that satisfies your like builds your favorite features or even satisfies the secret like the investors? Because that's also something that can happen, right? Maybe it wasn't that. I'm not sure in this specific case, by the way, I'm not sure if that was that person wanting their favorite features being built or was it the situation that they were facing some kind of investor pressure to build something and they couldn't get out of that. So they, they kind of just decided to direct that need towards the engineering organization that was possible ego driven development. However, it's just because people are stuck on some kind of promise cycle. Like they made a promise to investors or to a board and they need, they feel they just stick by that and they're not willing to break that promise. They just need that promise delivered upon, you know, they're hard situations to to deal with. So yeah, no, I, I really commend your courage to to walk away. No, I mean, it's, it's just I had to leave money on the table for that right. But at the same time, there is money you don't want to leave on the table and there is money that is absolutely worth living on that. Yeah. Nice. Yeah, absolutely. There's some money that we should just leave there. So like, I think one of the things that I've experience of it, if we practice also from teaching things like the lean product canvas, is that the using AI to help with some of our idea generation or exploring different avenues or finding ways to maybe leave some money not on the table when it comes to our products has been quite useful. I wouldn't say it's like a panacea or it gives all the answers. There's definitely been some use in the kind of embracing AI. So what do you see as the future? I mean, you think about leaving money on the table. We talk about getting feedback from our users and direct and product development. And we've got many people out there whose jobs will feel threatened. And I saw some, I saw, I saw some letter, it could have been rubbish, but signed by some of the consultancies saying what their expectations are for the future of their organizations about how it's going to affect. Actually there's sorts of more junior people they're not going to need anymore because AI is coming about. It's going to pick up a lot of a low level work, which historically maybe would have got graduates to do. What are your thoughts on on that given our conversation so far? Yeah, you, you kind of touched on on such a subject for me. So here is an interesting background story. About 10 years ago, I saw a talk by Paul Martin where he was talking about the rate at which the number of developers grow. And at that time, every three to five years, we had twice as many developers, which meant that just 10 years in after the release of iPhone, like most engineers were like started programming after the iPhone, for example, or after multi core processors came around, which is mind blowing, especially for a dinosaur like me. But yeah, well, you mentioned ICQ. We had gentlemen. Oh God, I've his name escapes me, but we had a long chat about ICQ because he was involved in one of the first kind of video chat tools many years ago. Yeah, we went off and then actually spent time after the podcast episode exchanging notes on ICQ and IRQ as well. Yeah. Anyway, Anyway, I don't. Anyway, we're old. Yeah, we're on and there's lots of people that aren't old. We are old people and probably I'm within the like one or two percent oldest engineers out there when it comes to like time since starting to good. Anyway, the point that I want to make is that like there was this huge growth in the number of developers and we estimated that by 20 to 35 every single person will be a developer if that rate continues. Of course, that rate slowed down a bit, especially in the last about two years. But still I think there is something very interesting happening and that is that over time, if we think about like the history of software engineering from the very beginning until today, at the very beginning, being a software engineer meant being reversed in algorithms. It meant being able to punch cards and and and write really low level machine code. And then as we progressed, we got to like a bit higher level compiled languages like C++. And then we got to this whole world of web development where you had scripts that were instantly running. And as we are going through all these phases, the level of abstraction rises and rises and rises, right. And then the latest advancements were were no code and low code solutions. They're very suddenly you have like a much shorter period of time between starting to learn how to build a software to the point where you actually have the product. And then comes AI and this whole thing gets even more accelerated. And here's the thing that's really interesting. I hear a lot of like people like product people, for example, saying that we don't need that many engineers anymore because I can build the prototype. I'm a product person, I'm not a cooler and I can build the prototype. And that's true. My bad news is that that doesn't mean that you didn't don't need an engineer. It means that you are becoming the engineer. And and that's, that also means that over time, more and more people will have that power of building software. For me, building software is including building software is thinking up what I like, what I need to, how would I want my product to look like, and then building it. And yes, there is a despecialization happening. Engineers will need to become a bit more of a product person, and product people need to become a bit more of an engineer. But I don't think that this is the end of engineering. So much so that I also don't think that we don't need junior engineers anymore. What I see is that junior engineers can now actually deliver more value than a senior engineer could deliver about five years ago. Right? Because now these junior engineers don't need to know every single library by heart to be able to code quickly. Most of the time that was saved, including time, was not having to go to Stack Overflow and looking it up. The API and the whole art of software development became even more about understanding the user and the needs and designing the product. And basically like the actual typing of the code is kind of becoming a tiny, tiny and irrelevant part of the process. It was a small part to begin with. Now it's a tiny part. But I don't think that it's replaced either junior or senior engineers. No, if you look at the the size of the world, right, and how much code is out there, you know, I wonder proportionally how much of it is new and modern and can really embrace things like it can really embrace AI and really help people be more effective. And how much of it is actually old, crummy, fragile code which needs to be maintained or evolved or, you know, extended in some way. But yeah, and that still needs people with a certain degree of expertise. And yeah, I wonder what the proportion is, you know, because are we actually staring down the Baron having a, a skills shortage in the future because the code bases aren't retired, but everyone else is? Yeah, I, I, yeah, I definitely think that this whole laying of software engineers to save money is a face. And it will be over the minute the investors figure out that their investment is worth less because these engineers are not there. This is right now a high driven situation and I I definitely think that is going to turn around. But going back to your point of how much of the code is something that needs to be maintained and extended. And yes, like AI is not great at that, but it does open up an interesting opportunity. But I about which I talk in one of my talks, it's called how to convince business of a big refactor or right. I did that talk a bunch of places, look for it in YouTube. And in that talk, what I talk about is like the conclusion that I make is when it comes to rewriting software, it's, it's a risky business for several reasons. But if you do it right and you learn how to do it incrementally while delivering value to the user by that rewrite, then you can actually put it off safely. And AI can be a really good friend for that process, because what AI is really good at is translation, Translating old crummy code to the new shiny React app that you want to build. It's amazing for that. I actually did that. Lean Poker used to have vanilla JavaScript front end. That was a complete mess. I wrote it over a weekend because I had my first event coming up and I didn't have a front end yet. So I kind of hacked it all together and then hack up on hack for 10 years, and then at some point last year I decided to rewrite it in in React. It took me about two to three weeks. With the half of AI and the result was amazing and it delivered new features to the user that that was a very important aspect for me. So point that I want to make is in the end, I think that AI is a game changer despite being a fancy auto complete. But the things that it cannot help you with, it's more interesting the things that it can help you with. And the thing that it cannot help you with is understanding your user and understanding what they need. It cannot help you with understanding complex systems and and optimizing them. For that you still need personal loop and for quite some time we will still need it because we already have like the the top people in AI telling us that scaling the data and scaling the GPUs isn't helping anymore. So so I guess we got what we got and now we need to learn how to create amazing products on top of this amazing research. I think it's a really nice point there out there when you look at the amount of information that's now available to us. I mean, if you put AI to one side, just a number of YouTube channels and still many conferences and some great people speaking at conferences as well. I think there's still so many ways in which we can learn. Obviously loads of great podcasts out there, but as an aside, if people did want to see you talk, are you doing any conferences this year? Yeah, I already have a bunch lined up. I will be in London for international JS Conf. I will be in Norfolk this year. I will present at Bob Conf in Berlin and then another conference in Barshaw. Ah, they might. Don't remember the name of the conference, but I can check it and then you can put it in the show notes. Absolutely. I mean, yeah, people did want to find out, like, because it's more like more information about you. Obviously you've got your YouTube channel next increment. I mean, that's going to be very easy for people to find. But what types of things do you generally talk about on there? Yeah, it's kind of, I'm still finding the niche there. So the originally it was a different channel. It was first called Morning Commute where I was sitting in cars with engineers and talking with them. I already removed those videos because they were bad quality and early experiments, but then I it became a cup of code and then leaders workshop and then next increment. And the interesting choice there is in next increment because I was thinking, OK, I can't come up with the right name for this channel. Why can't I come up with it? And I realized that my whole career is built on learning how to build things in small increments and learning along the way. And what I forget about the like, I forgot that when we I was building my YouTube channel, I tried to come up with the perfect niche and how to try to come up with the perfect format, a prompt instead of experimenting and and incrementally improving it. And then when I had that realization, I thought, OK, this is the name of the channel next increment. And this is the place where I'm learning what I want to really talk about and how I want to talk about it. But it's definitely about software engineering. It's about the connection between software engineering and product and incremental delivery. These are the topics that I mostly focus on. Basically the same topics that I would be talking about at conferences and the same topics that I would be sharing at lean pokers. Excellent. And you're lean, the lean Poker people want to. I mean, it does sound quite intriguing. How can people experience this? Do you do public sessions for this or is it only for like private and clients? Yeah, So clients definitely are welcome to reach out. But I do have a public event coming up. I always have one coming up. I usually when 1 feels up, I just immediately advertise the next one. Right now there is one for April and the way you can find is you go to limppoker.org/event and that's where you will have the opportunity to sign up for one of the limp poker events. Excellent. Well, we'll make sure that that makes it into the show notes as well. Yeah, Yeah. I think people should check it out. It sounds really interesting. I'd like to give it a go. Is it all remote? Yes, it is. It is remote. Actually, if any conferences want to include a limp book ribbon in their agenda, I do that too. But right now I don't have any conferences coming up with, with limp book ribbons. But I do have this online event and actually like I, I this, this is 2 half days. You usually do it as a single day for on site, but for online I do it just two half days And there are two time zones. So people can choose the Eastern Time zones version or the western time zones. So I'm actually running the events on the same day so that everyone can choose if they if they want to join in their morning or their evening, depending on where they aren't from. How accommodating of you. Very kind. Yvette, thank you so much for coming on. And you know, goes about saying thanks to Daniel and Daniel North as well because he was the person that introduced us. So, yeah, big up, big up. Dan, thank you very much for the introduction. And Yvette, thank you very much for agreeing to. Come on. Yeah, obviously Lean poker.org is the name of your the website for that. You've got your YouTube channel as well. And we'll make sure of a link to that goes in the show notes and I suppose LinkedIn as well. People can find you. Yeah. LinkedIn is also where people can't find me. Yes. Brilliant. And so is there anything else you wanted to share with our listeners before we wrap up this episode? Oh, no, I think we have shared everything and it's been a pleasure to be on your podcast. I'm happy to come again later, maybe near it from now. And yeah, thank you for having me. It's been an absolute pleasure. You've really got me thinking and inspired me as well. I've been I've been mean to do something about my YouTube channel for a long time and just haven't. So yeah, I'm yeah, I'm going to do something about you've inspired me and there's such great content. Thank you so much for coming on with that. And everyone, thank you so much for listening. This has been the first episode of 2025 starting off strong and we've got many more people coming up. So do be mindful and make sure that you subscribe to us on your podcast platform of choice because every Thursday will be coming at you with a brand new episode. So again, thank you, Yvette for coming on. Everyone, thank you for listening. This has been the Product Agility Podcast.

People on this episode

Head Shot

Ben Maynard

Host