Podcasts about Gojko Adzic

What do Spotify, Google Meet, and your expense report tool have in common? They could all delight your users—if you design for more than just function. In this episode, Dr. Nesrine Changuel breaks down the emotional motivators that transform average products into unforgettable ones. Overview What separates a good product from a great one? According to Dr. Nesrine Changuel, it's not just meeting functional needs—it's creating emotional delight. In this episode of the Agile Mentors Podcast, Brian Milner sits down with Nesrine, a former product leader at Google, Spotify, and Microsoft, to explore how emotional connection is the secret sauce behind the world’s most beloved products. They dive into Nesrine’s “Delight Framework,” reveal how seemingly mundane tools (like time-tracking software or toothbrush apps!) can create joy, and explain why delight isn’t a nice-to-have—it’s a competitive edge. Whether you're a product owner, product manager, or just want to build better user experiences, this episode will change how you think about your backlog forever. References and resources mentioned in the show: Dr. Nesrine Changuel Product Delight by Dr. Nesrine Changuel Blog: What is a Product? by Mike Cohn #116: Turning Weird User Actions into Big Wins with Gojko Adzic #124: How to Avoid Common Product Team Pitfalls with David Pereira Join the Agile Mentors Community Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Dr. Nesrine Changuel is a product coach, advisor, and speaker with over a decade of senior product management experience at Google, Spotify, and Microsoft, where she led major consumer products like Chrome, Meet, Spotify, and Skype. She holds a Master’s in Electrical Engineering and a PhD in Media Processing and Telecommunications and is based in Paris. Auto-generated Transcript: Brian Milner (00:00) Welcome back Agile Mentors. We're back for another episode of the Agile Mentors podcast. I'm with you as always Brian Milner and today I have a very special guest with me. I have Dr. Nesrine Changuel with me. Welcome in Nesrine. Nesrine (00:14) Hi, Brian. Thanks for having me. Brian Milner (00:16) I'm very excited to have Nesreen with us. I think this is going to be a really, really great episode for all of you product owners out there or product specialists, anybody who works in the product area. I think you're going to find this really interesting and you're going to want to bookmark this one. Maybe even come back to this a little bit. Nesreen is a coach, a speaker, particularly in the product area. She has previously worked at Google. She's worked at Spotify, at Microsoft, so no stranger to large enterprise, very high profile products that she's worked on in the past. She has a book coming out in May, so look for this book. It's called Product Delight. And that's really what we're going to be focusing on here is the concept of eliciting or generating kind of an emotional response to our product. I guess I'll start by, did you stumble upon this? What drew your interest to people's emotional response to products? Nesrine (01:19) Yes, so maybe I can share the story how I came to this topic and how I became so vocal about it. So in addition to being a product manager and leader over the last decade, I was always and I always enjoyed being a speaker. So I always wanted to go on stage and share insight. This is probably coming from my research background, because when I used to be a researcher, I traveled the world to go and present my research work and When I became a product manager, I kept this habit with me. So I always been on stage and I spoke about different topics like product discovery, product operation, different topics. Until one day I got reached out by a conference organizer and he said, Hey, Nisri, we want you on stage, but we have an idea for a topic for you. I'm not that used. Usually I come up with idea myself, but I said, okay, what do want me to talk about? And he said, Hey, Nusreen, you have been working for Spotify, for Microsoft, for Google Chrome and Google Meet, and we all admire those products and we consider them very successful products. What if you come and tell us what's the common thing that probably is there any common thing that made those products successful? Being an insider, being within those company, could you share with us something that you consider in common between those products? To be honest with you, I found it challenging at the same time interesting as an exercise. I was not, by the way, able at that time to answer the question, what's in common? So I sat down and I did the exercise myself and I started to think what was really in common? What made Skype Skype? What made Spotify Spotify and those Google products so successful? And I came to the following conclusion. I found that what made those products so successful is that they don't only solve for functional needs, but they also solve for emotional needs. So when we use a particular product, we use it for a certain functional need, but we also use it for an emotional need. And without even knowing that I have been doing it for more than 12 years, I came to the conclusion that, my God, during all those years, I have been focusing so much into users need from both angle, functional and emotional. So I came on stage and I spoke about that topic and from that day, I started to give it a name. I'm calling it emotional connection. I'm calling it product delight. And I'm here to share more about it as well. Brian Milner (03:50) That's awesome, yeah. I mean, I think we do hear a lot and we focus a lot on that functional kind of need, the way you differentiate there. think that's a good differentiation, functional and emotional kind of needs or motivators there. yeah, I mean, I've always heard, know, kind of that kind of general product advice is, you know, find the things that... people really, really have as huge needs, the things they would pay someone to do for them. And that's the key to success is finding those huge needs. But we're actually going beyond that to say, yeah, those are important. It's not to say that we should skip that, but it's when there's the emotional connection to a feature or to something that we do that really the light bulb kind of comes on for our customers. Is that kind of what your research is leading to? Nesrine (04:40) you're getting it right. Don't get me wrong. Of course you have to honor the functional needs and serve the functional feature, but the delight or the emotional connection happens when you go beyond exactly how you said it. Let me explain. If you serve only functional needs, you know what you get? You get satisfied users because they are asking for something and they are satisfied about what they are receiving. Now, Brian Milner (04:41) Okay, okay. Haha. Nesrine (05:05) If you surprise them by going beyond, by anticipating their need, by exceeding their expectation, you're not only satisfying them, you're surprising them in a positive way and delight is the combination of surprise and joy. Actually, the theoretical definition of delight is a combination of two emotions, surprise and joy. So going beyond, anticipate need and exceed expectation. is what we should aim for in addition to the functional needs. Brian Milner (05:35) That's awesome. Yeah, I use this example sometimes in, we use this example in the agile world to talk about, you know, the part of the agile manifesto that says customer collaboration over contract negotiation. And, you know, there's an example I use from my past where I used to work at a company that was very contract driven. And, you know, the thing that I always used to kind of take away from that was the very best we could ever do or hope to do. was to meet our customers' expectations. We could never, ever exceed it because we were only doing exactly what they told us to do. So I think this is a really important distinction here to make that just meeting the customer's needs, just meeting the minimal customer satisfaction bar, that's not going to keep you with loyal customers. That's not going to have repeat customers, or they're not going to tell their friends about, you know. That product did exactly what I hoped it would do. But it didn't really surprise me. It didn't really go beyond that. I know you talked about, because I've read your blog and a little bit of the discussion about this. So I know you talk about in the blog kind of the connection to Kano analysis. And I've always thought that's a really great way to try to determine things to target and go after. So talk to us a little bit about that, about Kano analysis and kind of what that uncovers and how that connects to what your research has shown. Nesrine (06:51) Yes. I love Kano by the way. I, I mean, that's one of the framework I have been considering throughout most of my product career. But this framework comes with a limitation and let me explain. So first of all, for those who are not very familiar with Kano, Kano is a visualization or categorization, let's call it. It's a categorization framework that allows to categorize features among different categories. One of them is must have. So these are the things that absolutely have to be in the product. Other that are performances, which are the more you have, the more satisfied users are, the less they less satisfied they are. And of course there are the delighters and delighters are those feature that when they are in the product, users are surprisingly happy. And when they are not, are not even the satisfaction is not even impacted. So the limitation of Kano is that it doesn't tell you how to achieve delight. Let me explain. I think we live in a world that everyone agree that we should delight our users. I mean, this, this concept is now globalized and everyone is talking about delighting users. The issue is that we don't know how to delight them. So we know category, there's a category that called delight, but we don't know how to. So the, the framework that I'm introducing and I'm calling it the delight framework is the framework that allows to first identify. So it's usually, represented into three steps. The first step is to start by identifying the emotional and functional motivators. So let me give you an example. I've been working at Spotify for about four years and as a Spotify user, imagine yourself, you are a Spotify user. You do have, of course, functional motivators. What could be the functional motivators? Listening to music, listening to podcasts, maybe listening to an audiobook. So all those are functional motivators. Now, what could be the emotional motivators as a Spotify user? It could be feeling less lonely. It could be feeling more productive because when you're working you need to listen to something. It could be about changing your mood. It could be about feeling connected. So all those are emotional motivators that drive users to use a product like Spotify. So what I encourage every product manager or every product team to do at first is to dig into identifying, of course, the functional need. And everyone is good, by the way, in identifying the functional needs. But also, while doing that exercise, pay attention to what could be the emotional motivators. So that's step number one is about listing the functional and the emotional motivators. Once you have those, Now we get to the second part of the framework, which is look at your backlog. And I guess you have a very busy backlog and take those features one by one and see for this particular feature, which motivator am I solving for among the functional ones and among the emotional ones as well. So the delight grid, for example, is a visualization tool that I came and created in order to allow product teams to visualize their backlog and see how many of my features are only solving for functional motivators. In that case, we call that category low delight. How many of my features are only solving for emotional motivators? These are very rare, but the best example I would call is, for example, I'm having an Apple watch and one month ago it was New Year Eve and at midnight I get fireworks popping out of my Brian Milner (10:35) Ha Nesrine (10:36) Apple watch and it was a happy new year there's nothing functional in there but it's all about creating some smile I call this surface delight and then how many of your features are solving for both functional and emotional motivators and I call this deep delight so maybe I deviated a bit from your question compared to canoe but it's actually about adding this dimension of connecting features to the real motivators of the users. Brian Milner (11:07) No, maybe a little bit, but you connected it to where we end up going anyway. So I think that's a great connection there. And by the way, for anyone listening, we'll link to all of this so that you can find this and follow up. But I like that differentiation between surface delight and deep delight. I know some of the examples that I've heard used kind of frequently in looking at Kano analysis and kind of trying to find those delighters. And that is kind of the area that it specifies there in Canoe, right? You're trying to find those things that are not expected, but when people find that they're there, they like that it's there, but they don't expect it's there. So if it's not there, there's no negative response that it's not there, but there's a positive response if it's there because they like seeing it. And my boss, Mike Cohn, tells this story about this Nesrine (11:59) Yes. Brian Milner (12:03) There's a hotel in California that became famous because at the pool, they have a phone that's by the pool that's the Popsicle Hotline. And you can pick up the phone and you can order a Popsicle to be brought to the pool. And it's the kind of thing where you're not going to go search for a hotel. Does this hotel have a Popsicle Hotline? I'm only going to stay at hotels with Popsicle Hotlines. It's not that kind of a normal feature. It's a delight feature because when you see it and you find out it's there, it's like, that's really cool. And it can be the kind of thing that says, yeah, I want to search that hotel out again next time I'm in this area because I really thought that was a nice little attention to detail and it was fun. But I think what I'm hearing from you is that might be more of what we would classify as a surface delight. It's not really meeting a deep need. Nesrine (12:35) Yes. Brian Milner (12:56) But it's fun, it's exciting, it's not expected, but it doesn't really cross that threshold into, but it also meets kind of functional delights. Is that kind of what you're saying there? Okay. Okay. Nesrine (13:08) Yes, actually I heard about that hotel story just to tell you how much viral it went. It came to me. So actually you get it correct that I consider that as surface delight and I have nothing against by the way, surface delight. You can add surface delight. The issue is you can end up doing only surface delight and that's not enough. So the idea is to do a combination and I do have two stories to share with you just to compliment on this hotel story. One is personal and one is professional. Brian Milner (13:21) Yeah. Okay. Nesrine (13:37) The personal one just happened to me a month ago. I went to Sweden and I went to Stockholm. That's where I worked for eight years. And I went there for business and I decided to meet some friends and some ex-colleagues. So we all gathered and went to a restaurant, a very nice restaurant in Sweden. And came the time where we had to say goodbye and to pay. And I guess you can feel it immediately when it's about paying and we are a large group and you start to get that anxiety about who's paying what and what did I order? What did I drink? What? I mean, I honestly hate that moment, especially in a large group where you don't necessarily have a lot of affinity with us. Like, should we split in 10? Should we pay each one paying its piece anyway? So that was a moment of frustration, of anxiety. Brian Milner (14:09) right. Yeah. Nesrine (14:28) And I loved how the restaurant solved it for it. You know how they solve for it? I mean, maybe it exists in the U.S., but for me, that's something I never seen before. The waiter came with a QR code on a piece of paper and you scan the QR code. And when you scan your QR code, you get the list of items that got purchased by the table. And all you have is to pick, and that happens automatically real time. Everyone is picking at the same time. You pick the things from the list and you pay. for the things that you order. You can even tip on the bottom. You can give feedback. Everything happened on that QR code. And you can guess how much that anxiety could be removed. So that's the personal story I wanted to share. The second story, which is more professional, I want to share how we try to improve experience at Google Chrome. So I've been the product manager at Google Chrome. Brian Milner (15:13) Yeah. Nesrine (15:25) And we started from the observation that people do have plenty of open tabs. I guess you are one of them, especially on mobile. Like on mobile, you go and check how many open tabs you do have on Chrome and you realize that they are have, we realized at least out of numbers, out of data that people do have plenty of open tabs. So it started as Brian Milner (15:32) You Nesrine (15:47) technical issue. Of course, the more tab you have, the heavier the app is, the slower the app could be, et cetera. So we wanted to reduce the number of unnecessary open tabs in Chrome. So we interviewed users and we started to check with them, why do they even leave their tabs open? So some of them leave tabs because they consider them as a reminder. I mean, if tab is open, it means that you need to finish a task there. Some people really leave tabs just for ignorance. mean, they moved from a tab to another and they completely forget about them. Actually, we realized that the fact of leaving tab open, the reason for leaving tab could be completely different from a person to another. And the other interesting observation, and when I say identify emotional motivators, you will realize that people feel a bit ashamed when they show to us that they do have plenty of open tabs. Some of them would say, sorry, I usually don't even have so many open tabs. It's only now. And I'm like, it's okay. But the point is, if you have this mindset of trying to track the emotional insight from your users, you will take note. And the note was anxiety, feeling ashamed, blah, blah, blah, blah, blah. And that was in introduction for in... Brian Milner (16:42) You Yeah, right. Nesrine (17:04) improving the tab management experience later on in Chrome. Brian Milner (17:07) That's actually a really good parallel, though. I think that's a good example because it reminds me, too, even going back, I remember one of the things, and I'm going way back here, but I remember one of the things about Gmail that was kind of a selling point initially was the concept there of you don't have to worry about maintaining an inbox. keep all your mails and search. And you can search through your mails and find whatever it is. And I remember prior to that, most people would use something like Outlook or something like that to have their mail, there was always this constant struggle of, I've got to keep it down. I've got to delete things. I've got to categorize things. And Google had this different approach of, don't worry about it. Just leave it. And that's a good, I think, example as well of kind of that emotional response of, Nesrine (17:48) Yes. Brian Milner (17:56) Gosh, I'm kind of anxious. I feel bad that my inbox is so big. And I know that's bad, but Google comes along and says, don't worry about it. You're not bad. It's OK. Yeah. Nesrine (18:05) Yeah, yeah. And by the way, I think Gmail is filled with plenty of deep delight features. One of them I can quickly highlight is, you know, when you send an email, we're saying attached file and the file is not there. And when you try to hit send, you get that pop up like a be careful or like a mind, there is no attached file inside. These are for me like very attached to the fact that You don't want to feel ashamed. You don't want to look stupid later on saying, Hey, sorry, I forgot the file. Here's the file. That's, that's a great example. And the other example that come to mind again in Gmail, you know, that smart compose when you're trying to answer an email and you can just hit tab, tab, tab to complete the sentence. I mean, the functional need is to write an email. The emotional need is to get it in a relaxed way. And the combination would allow for something like. Brian Milner (18:49) Yeah. Nesrine (19:00) Smart Compose. Brian Milner (19:01) That's awesome. Yeah, so I guess that leads to the question though, when we're talking about something like Spotify, mean, music intrinsically is emotional anyway, right? It's something that you have an emotional connection to and you feel a certain way when you hear music. But if my product is a, I don't know, expense reporting software, right? Nesrine (19:23) Mm-hmm. Brian Milner (19:25) I can just hear people out there kind of asking, know, and kind of thinking to themselves, yeah, but my product, right, my product is not that kind of, it doesn't elicit that kind of emotional response in people the same way music would. So does this apply to me as well? So how would you answer those people who feel like my products might be a little bit more bland or boring and don't really intrinsically have an emotional connection to them? Nesrine (19:47) Mm-hmm. So my answer is that if your product is boring, then it's even more priority now to focus on emotional connection. But let me elaborate. So that's one of the reflections that came to my mind while writing the book. So while writing the book, I wanted the book to be a storytelling book. So I was writing a lot of my stories, stories from Skype at the time, Spotify and all the Google product. But at some point I said, hey, hey, Nisreen, you need to get more insight from other people and other experiences. So I get to interview product leaders from completely different industries and completely different domain. I interviewed leaders from B2B like Atlassian or Intuit and so many other companies that I don't have so much insight from. I even interviewed people from hardware, like I interviewed someone from Dyson and I was, hey, what makes Dyson so emotionally attractive for me? Cause I love my Dyson vacuum cleaner. But let me get to your point because when I interviewed someone from Intuit, that person told me something super interesting. She told me that at some point she was working at a tool called Tsheet. And Tsheet is a tool that allows you to enter your time report. There is nothing more boring than that. I think I'm picking the one that you're looking for here because it's, it's as a user. The only reason I would use this tool is to report my time so I can get paid. Brian Milner (21:06) Hmm. Right. Yeah. Nesrine (21:19) There is nothing exciting, nothing emotional. And what I got out of that product leader who used to be the head of product at the time, she told me that they were completely aware about the fact that the product is not that attractive. And instead of living with that observation, they did all what they could do to make it even more attractive. So they added some fun. They made the messaging less aggressive and less about enter your time. report but rather into more playful and even the images are more playful. When you press the enter time report you get the congratulation and some confetti if needed. So they explicitly turned and that's a strategy. They turned that boring moment into something even more attractive and they had to do that otherwise the experience will keep on becoming more more boring and the perception of users toward the product will be even less, more and more gray, I would say. Brian Milner (22:22) Yeah, yeah, just that little dopamine kind of kick, right? Just that little bit of chemical reaction in your brain can make a huge difference. That's awesome. That's a great story and a great answer to that question. So I'm curious, we're talking about trying to find these things and trying to see, your matrix here, it thinks about the emotional motivators, the functional motivators, and trying to find those things that kind of cross both planes. Nesrine (22:24) Yep. Brian Milner (22:52) How do you verify at the end? Because if you're lining your features up and think, I think this solves this emotional thing. I think this solves this functional thing. Is there a way to follow up to ensure that it actually is doing that? How do you follow up to make sure it's really doing what you thought it would do? Nesrine (23:09) Yes, so let's imagine you did the exercise well, you filled in the delight grade and you observed that you do have plenty of low delights, which is most of the cases by the way. The very first thing I recommend is to see opportunities for moving or transforming these features into deep delight. And in the book, for example, I talk about the nine delighters. Nine delighters are ways that could be sometimes cheap even to introduce. in order to make those low delight features into more deep delight. This could be, for example, through personalization. We love when the features are personalized, and that's one of the reasons, for example, why Spotify is so successful, is through features like Discover Weekly or RAPT or these kinds of super personalization related features. It could be through seasonality. That's, for me, the cheapest and the most delightful feature you can or aspect of feature you can add to your product. So for example, when I worked at Google Meet, I've been working at the background replace features. So we have been, of course, introducing static image. We have been introducing video backgrounds as well. But from time to time, we always use seasonality to introduce what we call seasonal background. So when it's Easter, we introduce Easter background. When it's Christmas, we introduce Christmas background. Guess what? Even like for Olympic game, we introduce Olympic game background. When it's the Earth Day, we introduced Earth Day background. So there is always an opportunity to introduce some seasonality to the product. And guess what? We relate to those, especially if the product is global. We relate like last, when was it? Like last Wednesday. It was the new year, the Chinese new year. And I was checking when is exactly the exact date for the new year, the Chinese new day. And I put that and you know what happened in Chrome? It got these dragons and those like the celebration within the product, like within Chrome. These of course are surface delight, but you know what? Why not? You see? So there are some tools. Some of them are not that... Brian Milner (25:17) Right. Nesrine (25:22) expensive to introduce to the product. Some would require a bit more thoughtful and thought into it, but there are ways that I detail in the book in order to introduce more delight. And then if you want to validate through metrics, and I guess that's your question where it's heading to, then the good news, and that's something that I discovered recently because there's been a study that was conducted by McKinsey. And you know what they studied? They studied the impact of emotional connection on product adoption. So they actually studied over, I don't know how many industries die, like tourism, IT, energy, whatever. And they interviewed more than 100,000 users or whatever. So the conclusion that they found out of that very interesting study is that emotionally connected users will get you more twice as more revenue, twice as more referral, and twice as more retention compared to satisfied users. I'm not talking about the non-satisfied. So if you take two groups of users, those that you satisfy their needs and those that you go beyond and they are emotionally connected, those that are emotionally connected get you twice revenue, referral and retention. Brian Milner (26:19) Hmm. Nesrine (26:43) So this is just to highlight that for people who say, no, but this is the cherry on the top. This is just like the extra. It's not the extra, it's the way to stand out. I don't know any company that is standing out nowadays without investing into emotional connection, none. Brian Milner (26:54) Yeah. That's a really good point. Yeah, I mean, the example that comes to my mind when you talked about seasonality and other things like that, know, I love my, you know, they're not a sponsor, Oral-B toothbrush, you know, the electronic toothbrush, and you know, there's an app with it and it keeps track of, you know, did you get all the areas of your teeth and did you hold it there long enough and... One of the things I always love about it is when it gets to December, the opening screen when you open up the app starts having snowfall. It's kind of a funny little emotional response, but you look at that and you think, that's cool. Yeah, it is kind of that season where now it's time to get ready for Christmas and it's that special. It's only this month that it's going to be like that. It's going to go away at the end of the month. Nesrine (27:45) Yes. Brian Milner (27:49) feel little sad when it's gone, it's back to normal. But it's such a silly little thing. Does that make any difference in really brushing my teeth at all? Does it change how well I brush my Not really. It's just a fun little thing that when it pops up there. And think how little that took from someone to do that. It's a little animation that they just pop up on a loading screen. But that little tiny bit, think, again, maybe a little bit surface. Nesrine (28:10) Yes. Brian Milner (28:16) but it takes something that would have been routine. It takes something that would have been kind of boring otherwise, and it just added a little bit of fun to it, you know? And I think you're right, that emotional connection is really, really important in situations like that, yeah. Nesrine (28:21) Yes. Yes. Yes, yeah. And the thing that I'm very vocal about nowadays is the fact that this emotional connection is actually not a new topic. It's something that has been extremely popular among marketers. For example, if you think about the best marketing campaign, they are all very emotional. The most successful marketing campaign are. If you think about designers, there are plenty of resources about emotional design. There is a great book by Don Norman. It was called emotional design. Aaron Walter as well wrote something called Designing for Emotion. But you know, the problem is that among engineers and among product manager, we don't talk that much about that. And you know what happened when we are not informed about this topic? There is a gap between the language of marketers, designers, and the engineers and product manager. And that gap doesn't allow things to succeed. I'm trying to educate the engineers and the product world towards this well-known domain outside of the product in order to have this consistency and start making real impactful products. Brian Milner (29:40) Yeah, yeah, this is such a really deep topic and it just encourages me, think, even more to recommend the book there. It's not out yet, time of this recording it's not out, but it's going to be in May of 2025. That's when this book is coming out. And I know it's gonna have a lot of really good information in it. Again, the book is gonna be called Product Delight. by Nesrine Changuel, Dr. Nesrine Changuel. I should make sure I say that. But I really appreciate you coming on because this is fascinating stuff. And I think the product managers, the product owners that are listening here are going to find this really fascinating. So I appreciate you sharing your time and your insights with us, Nesrine. Nesrine (30:26) Thank you, it's my pleasure. I love talking about this topic. Brian Milner (30:29) Ha

Als Product Owner ist es essenziell, sich kontinuierlich weiterzuentwickeln und die richtigen Werkzeuge für die tägliche Arbeit zu nutzen. In der neuesten Episode der Produktwerker geht es genau darum: Welche Methoden für Product Owner sind wirklich relevant? Eine der wichtigsten Grundlagen ist die Produktvision. Hier hilft das Product Vision Canvas bzw. das Product Vision Board (von Roman Pichler), um ein gemeinsames Verständnis im Team und mit Stakeholdern zu schaffen. Ob mit dem Framework von Roman Pichler oder dem Positioning Statement von Geoffrey Moore – entscheidend ist, dass die Produktvision klar und lebendig bleibt. Eng verknüpft mit der Produktvision ist das Thema Roadmapping. Klassische, feature-getriebene Roadmaps sind längst überholt. Stattdessen setzen erfahrene Product Owner auf Outcome-orientierte Roadmaps, etwa in Form der Now-Next-Later-Roadmap. Dabei geht es nicht darum, starre Zeitpläne einzuhalten, sondern den Fokus auf die gewünschten Wirkungen zu legen. Für eine sinnvolle Planung ist außerdem Story Mapping unverzichtbar. Diese Methode hilft, eine holistische Sicht auf das Produkt zu behalten, Features sinnvoll zu priorisieren und das Team in die richtige Richtung zu steuern. Jeff Patton hat mit dem User Story Mapping eine Praxis entwickelt, die das Verständnis für Wirkungsschnitte und Priorisierung stärkt. Ein weiteres wertvolles Tool im Werkzeugkasten eines Product Owners ist der Opportunity Solution Tree (OST), bekannt aus Teresa Torres' Buch Continuous Discovery Habits. Der OST ermöglicht es, Business-Ziele mit Kundenbedürfnissen zu verknüpfen und den besten Weg zur Lösung abzuleiten. Etwas älter, aber genauso wirksam ist das Impact Mapping von Gojko Adzic – ein strukturierter Ansatz, um zu visualisieren, welche Akteure ihr Verhalten ändern müssen, damit das Produkt erfolgreich wird. In der täglichen Arbeit von Product Ownern spielen Annahmen eine große Rolle. Doch oft sind diese weder hinterfragt noch belegt. Hier kommt das Assumption Mapping ins Spiel. Mit dieser Methode von David J. Bland lassen sich Annahmen systematisch priorisieren und durch gezielte Experimente validieren. Auch das Arbeiten mit User-Feedback gehört zu den essenziellen Methoden für Product Owner. Hier hilft der Interview-Snapshot aus Teresa Torres' Discovery-Ansatz, um strukturierte Erkenntnisse aus Nutzerinterviews zu ziehen. In Kombination mit dem Value Proposition Canvas von Alexander Osterwalder lassen sich die relevanten Pain Points und Gains der Nutzer noch klarer herausarbeiten. Natürlich darf auch das Thema User Stories nicht fehlen. Diese Technik ermöglicht eine nutzerzentrierte Formulierung von Anforderungen. Doch User Stories sind nur so gut wie ihre Akzeptanzkriterien und die Fähigkeit, sie sinnvoll zu schneiden. Deshalb ist es entscheidend, nicht nur das Schreiben, sondern auch das Splitting von User Stories zu beherrschen. Ein weiterer Bereich, der oft unterschätzt wird, ist das Stakeholder-Management. Ohne eine gezielte Strategie kann die Vielzahl an Stakeholdern schnell zur Herausforderung werden. Das Power-Interest-Grid hilft dabei, die richtigen Prioritäten zu setzen und Stakeholder effektiv einzubinden. Daneben sehen wir noch eine elfte Methode, quasi als "Bonus-Thema", das in den letzten Jahren immer wichtiger wird: AI-Prompting. Die Fähigkeit, mit Tools wie ChatGPT oder Perplexity effizient zu arbeiten, kann für Product Owner einen enormen Vorteil bringen – sei es für die Generierung von Ideen, die Analyse von Feedback oder die Strukturierung von Informationen. AI wird zunehmend zum Wingman für Product Owner und sollte daher als fester Bestandteil des Methodensets verstanden werden. Diese zehn Methoden für Product Owner sind nicht nur theoretische Konzepte, sondern praxisbewährte Werkzeuge, die den Alltag eines POs erleichtern und das Produktmanagement auf ein neues Level heben. Welche dieser Methoden setzt du bereits ein? Und welche fehlt deiner Meinung nach in dieser Liste?

BONUS: Gojko Adzic on Optimizing Products for Long-Tail Users (Agile Online Summit 2024 Replay) In this BONUS episode, we revisit Gojko Adzic's insightful interview at the Agile Online Summit 2024. Gojko, an award-winning author and software expert, unpacks the principles behind his latest book, Lizard Optimization, offering a fresh perspective on improving product usability by addressing the needs of long-tail users. From learning from unexpected user behaviors to refining products with a systematic approach, this episode is filled with practical tips for product teams and Agile practitioners. What is Lizard Optimization? Drawing from his experiences as a product developer, Gojko introduces the idea of Lizard Optimization. He discusses how observing unexpected user behaviors led him to refine his SaaS tools like Narakeet and MindMup. By focusing on usability challenges and unusual patterns, he has turned serendipity into actionable insights. “Users aren't stupid—they're just finding creative ways to get value from your product. Listen to them.” Gojko explains the inspiration behind the metaphor of the “Lizardman constant,” a concept from a Scott Alexander blog post. He describes how this principle applies to product optimization: understanding and addressing the 4% of surprising, unexplainable behaviors can uncover opportunities for innovation. “The job isn't to judge users—it's to explore why they're doing what they're doing and how we can help them succeed.” The High-Level Process of Lizard Optimization Gojko outlines the systematic process described in his book to leverage unexpected user behavior: Observe Misuse: Identify how users deviate from expected patterns. Extract Insights: Focus on one unexpected behavior as a signal. Remove Obstacles: Help users achieve their goals more easily. Monitor Impacts: Detect and adjust for unintended consequences. “Start monitoring for the predictable but unexpected—those hidden gems can unlock your next big feature.” Practical Advice for Product Teams For teams ready to apply these concepts, Gojko emphasizes the importance of expanding observability tools to include product metrics and not just technical ones. He shares how tracking unpredictable user actions can inspire impactful changes. “About a third of what we do delivers value—focus on finding where unexpected value lies.” Recommended Resources To dive deeper into these ideas, Gojko recommends: Trustworthy Online Controlled Experiments by Ron Kohavi Evidence Guided by Tim Herbig LizardOptimization.org “Experimentation and evidence-based decision-making are the keys to building better products.” Closing Thoughts: “Look for the Unexpected” Gojko's parting advice for Agile practitioners is simple yet powerful: Look for the unexpected. By embracing surprises in user behavior, teams can transform minor inconveniences into major opportunities for growth. “The unexpected is where innovation begins.” About Gojko Adzic Gojko Adzic is an award-winning author, speaker, and product creator. His books, including Lizard Optimization, Impact Mapping, and Specification by Example, have become essential reads for Agile practitioners and product teams worldwide. Gojko is a 2019 AWS Serverless Hero, the winner of the 2016 European Software Testing Outstanding Achievement Award, and the 2011 Most Influential Agile Testing Professional Award. He has also co-founded several successful SaaS tools, including Narakeet, MindMup, and Votito. You can link with Gojko Adzic on LinkedIn.

In this special episode, Vasco Duarte announces the first-ever Global Agile Summit 2025, scheduled for May 18-20 in Tallinn, Estonia. After seven years of organizing virtual Agile summits, the team is taking the next big step with an in-person event bringing together practitioners, leaders, and innovators from across the Agile community. The summit will feature three packed days: Day 1: Hands-on workshops with thought leaders Days 2-3: Parallel tracks focused on Business, Product, and Development This practitioner-focused event emphasizes real-life success stories and practical implementations of Agile methodologies. Past summits have featured renowned speakers like Marshall Goldsmith and Gojko Adzic. Super early-bird tickets are available now at 75% off the full price (just 249€), exclusively for past summit attendees and paid subscribers. Perfect for: CTOs and CPOs Engineering and Product Leaders Tech Leads and Product Managers Consulting Companies Agile Teams Learn more and secure your spot at GlobalAgileSummit.com

Gojko Adzic - Lizard OptimizationLook who's back! Gojko Adzic will present us his new book Lizard Optimization: Unlock product growth by engaging long-tail users.As we read on the back cover: "Lizard Optimization is a technique for designing product development experiments by engaging long-tail users that seem to follow some unexplainable "lizard" logic. It can help you understand your audience better and improve your products. The method is based on the author's experience managing an online software product that grew explosively from November 2021 to November 2022. The key user metric, tracking when people are getting value from the product, increased by more than 500 times in those 12 months (times, not percent). This happened after a period of unremarkable growth and a slow decline. Looking back, the key factor in reversing the decline and unlocking exponential growth was a counter-intuitive approach to engaging users. This book is a summary of the key lessons from that crazy growth phase, synthesized into a simple process that you can apply to improve your products, and help you unlock growth, reduce churn and increase revenue."And as usual - plenty of space for your questions! 

Gojko Adzic - Lizard OptimizationLook who's back! Gojko Adzic will present us his new book Lizard Optimization: Unlock product growth by engaging long-tail users.As we read on the back cover: "Lizard Optimization is a technique for designing product development experiments by engaging long-tail users that seem to follow some unexplainable "lizard" logic. It can help you understand your audience better and improve your products. The method is based on the author's experience managing an online software product that grew explosively from November 2021 to November 2022. The key user metric, tracking when people are getting value from the product, increased by more than 500 times in those 12 months (times, not percent). This happened after a period of unremarkable growth and a slow decline. Looking back, the key factor in reversing the decline and unlocking exponential growth was a counter-intuitive approach to engaging users. This book is a summary of the key lessons from that crazy growth phase, synthesized into a simple process that you can apply to improve your products, and help you unlock growth, reduce churn and increase revenue."And as usual - plenty of space for your questions! 

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." Find the key learnings, the transcript and more in the companion blog post: https://alexis.monville.com/en/2024/10/29/optimizing-for-the-unexpected-insights-from-gojko-adzic-on-lizard-optimization/

This is the Engineering Culture Podcast, from the people behind InfoQ.com and the QCon conferences. In this podcast Shane Hastie, Lead Editor for Culture & Methods, spoke to Gojko Adzic about his work in software development, product management, and value creation. Gojko discusses his experiences in building and improving products, the importance of measuring user behavior changes, and the concept of "lizard optimization" - improving products by addressing unexpected user behaviors. Read a transcript of this interview: https://bit.ly/485EukY Subscribe to the Software Architects' Newsletter for your monthly guide to the essential news and experience from industry peers on emerging patterns and technologies: https://www.infoq.com/software-architects-newsletter Upcoming Events: QCon San Francisco (November 18-22, 2024) Get practical inspiration and best practices on emerging software trends directly from senior software developers at early adopter companies. https://qconsf.com/ QCon London (April 7-9, 2025) Discover new ideas and insights from senior practitioners driving change and innovation in software development. https://qconlondon.com/ Save the date: InfoQ Dev Summit Boston (June 9-10, 2025) Actionable insights on today's critical dev priorities. The InfoQ Podcasts: Weekly inspiration to drive innovation and build great teams from senior software leaders. Listen to all our podcasts and read interview transcripts: - The InfoQ Podcast https://www.infoq.com/podcasts/ - Engineering Culture Podcast by InfoQ https://www.infoq.com/podcasts/#engineering_culture - Generally AI: https://www.infoq.com/generally-ai-podcast/ Follow InfoQ: - Mastodon: https://techhub.social/@infoq - Twitter: twitter.com/InfoQ - LinkedIn: www.linkedin.com/company/infoq - Facebook: bit.ly/2jmlyG8 - Instagram: @infoqdotcom - Youtube: www.youtube.com/infoq Write for InfoQ: Learn and share the changes and innovations in professional software development. - Join a community of experts. - Increase your visibility. - Grow your career. https://www.infoq.com/write-for-infoq

This interview was recorded for the GOTO Book Club.http://gotopia.tech/bookclubRead the full transcription of the interview hereGojko Adzic - Software Delivery Consultant & Author of "Lizard Optimization" and many more BooksDave Farley - Continuous Delivery & DevOps Pioneer, Award-winning Author, Founder & Director of Continuous Delivery Ltd.RESOURCESGojkohttps://twitter.com/gojkoadzichttps://www.linkedin.com/in/gojkohttps://github.com/gojkohttps://gojko.netDavehttps://twitter.com/davefarley77https://linkedin.com/in/dave-farley-a67927http://www.continuous-delivery.co.ukhttp://www.davefarley.netDESCRIPTIONDave Farley and Gojko Adzic discuss Gojko's latest book “Llizard Optimization”, which involves identifying and leveraging unconventional uses and misuses of products to improve them for all users. Gojko shares insights and examples from his experiences with Narakeet and MindMup, highlighting how addressing the needs of outlier users led to significant product enhancements and growth.They also touch on broader themes of user retention, the joy of building and solving problems, and the balance between solo work and collaborative efforts in software development and writing.RECOMMENDED BOOKSGojko Adzic • Lizard OptimizationGojko Adzic • Impact MappingAdzic, Evans & Roden • Fifty Quick Ideas To Improve Your TestsAdzic, Evans & Korac • Fifty Quick Ideas to Improve Your User StoriesAdzic & Korac • Humans vs ComputersGojko Adzic • Specification by ExampleAdzic, Marcetic & Bisset • Bridging the Communication GapAdzic & Korac • Running ServerlessKat Holmes • MismatchDavid Farley • Modern Software EngineeringDave Farley • Continuous Delivery PipelinesDave Farley & Jez Humble • Continuous DeliveryTwitterInstagramLinkedInFacebookLooking for a unique learning experience?Attend the next GOTO conference near you! Get your ticket: gotopia.techSUBSCRIBE TO OUR YOUTUBE CHANNEL - new videos posted daily!

What do lizards have to do with product growth? In this episode, Gojko Adzic reveals how unusual user behaviors can unlock massive opportunities for product innovation. Discover the four steps to mastering "Lizard Optimization" and learn how you can turn strange user actions into game-changing insights. Overview In this episode of the Agile Mentors Podcast, host Brian Milner chats with Gojko Adzic about his new book, Lizard Optimization. Gojko explains the concept of finding product growth signals in strange user behaviors, sharing examples where unexpected user actions led to product breakthroughs. He outlines a four-step process for optimizing products by learning, zeroing in, removing obstacles, and double-checking. Gojko also discusses helpful tools like session recorders and observability tools that can enhance product development by uncovering and addressing unique user behaviors. References and resources mentioned in the show: Gojko Adzic 50% OFF Lizard Optimization by Gojko Adzic Mismatch: How Inclusion Shapes Design by Kat Holmes Trustworthy Online Experiments by Ron Kohavi Advanced Certified Scrum Product Owner® Subscribe to the Agile Mentors Podcast Join the Agile Mentors Community Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Gojko Adzic is an award-winning software consultant and author, specializing in agile and lean quality improvement, with expertise in impact mapping, agile testing, and behavior-driven development. A frequent speaker at global software conferences, Gojko is also a co-creator of MindMup and Narakeet, and has helped companies worldwide enhance their software delivery, from large financial institutions to innovative startups. Auto-generated Transcript: Brian (00:00) Welcome in Agile Mentors. We're back for another episode of the Agile Mentors podcast. I'm with you as always, Brian Milner. And today, very special guest we have with us. have Mr. Goiko Atshich with us. I hope I said that correctly. Did I say it correctly? Close enough. Okay. Well, welcome in, Goiko. Glad to have you here. Gojko (00:15) Close enough, close enough. Brian (00:21) Very, very, very happy to have Goiko with us. If you're not familiar with Goiko's name, you probably are familiar with some of his work. One of the things I was telling him that we teach in our advanced product owner class every time is impact mapping, which is a tool that Goiko has written about and kind of come up with on his own as well. Gojko (00:21) Thank you very much for inviting me. Brian (00:47) But today we're having him on because he has a new book coming out called Lizard Optimization, Unlock Product Growth by Engaging Long Tail Users. And I really wanted to talk to him about that and help him explain, have him explain to us a little bit about this idea, this new concept that his new book is about. So, Goiko, let's talk about it. Lizard Optimization, in a nutshell, what do you mean by that? What is it? Gojko (01:14) We're going to jump into that, but I just need to correct one of the things you said. I think it's very, very important. You said I came up with impact mapping and I didn't. I just wrote a popular book about that. And it's very important to credit people who actually came up with that. It's kind of the in -use design agency in Sweden. And I think, you know, they should get the credit for it. I literally just wrote a popular book. Brian (01:19) Okay. Gotcha. Gotcha, gotcha. Apologies for that incorrect. Thank you for making that correction. So lizard optimization. Gojko (01:44) So, lizard optimization. Good. So, lizard optimization is an idea to find signals for product ideas and product development ideas in strange user behaviors. When you meet somebody who does something you completely do not understand, why on earth somebody would do something like that? Brian (02:03) Okay. Gojko (02:11) and it looks like it's not done by humans, it looks like it's done by somebody who follows their own lizard logic, using stuff like that as signals to improve our products. Not just for lizards, but for everybody. So the idea came from a very explosive growth phase for one of the products I'm working on, where it... had lots of people doing crazy things I could never figure out why they were doing it. For example, one of the things the tool does is it helps people create videos from PowerPoints. You put some kind of your voiceover in the speaker notes, the tool creates a video by using text to speech engines to create voiceover from the speaker notes, aligns everything and it's all kind of for you. People kept creating blank videos and paying me for this. I was thinking about why on earth would somebody be creating blank videos and it must be a bug and if it's a bug then they want their money back and they'll complain. So I chased up a few of these people and I tried to kind of understand what's going on because I originally thought we have a bug in the development pipeline for the videos. So... I started asking like, you know, I'm using some, I don't know, Google slides or, you know, keynote or whatever to produce PowerPoints. Maybe there's a bug how we read that. And the person, no, no, we, know, official Microsoft PowerPoint. They said, well, can you please open the PowerPoint you uploaded? Do you see anything on the slides when you open it? And the person, no, it's blank. Right? Okay, so it's blank for you as well. I said, yeah. So. Brian (03:48) Yeah. Gojko (03:54) What's going on? so what I've done is through UX interviews and iterating with users and research, we've made it very, very easy to do advanced configuration on text -to -speech. And it was so much easier than the alternative things that people were creating blank PowerPoints just to use the text -to -speech engines so they can then extract the audio track from it. Brian (03:54) Yeah, why? Gojko (04:23) and then use that and it was this whole mess of obstacles I was putting in front of people to get the good audio. It wasn't the original intention of the tool. It wasn't the original value, but people were getting unintended value from it. And then I ended up building just a very simple screen for people to upload the Word document instead of PowerPoints. And it was much faster for users to do that. A month later, there was many audio files being built as videos. Two months later, audio... production overtook video production. then at the moment, people are building many, many more audio files than video files on the platform. So it was an incredible growth because of this kind of crazy insight of what people were doing. kind of usually, at least kind of in the products I worked on before, when you have somebody abusing the product, product management fight against it. There's a wonderful story about this in... Founders at work a book by Jessica Livingston and she talks about this kind of group of super smart people in late 90s who Came up with a very very efficient Cryptography algorithm and a way to compute the cryptography so they can run it on low -power devices like Paul pilots Paul pilots were you know like mobile phones, but in late 90s and Then they had to figure out, how do we monetize this? Why would anybody want to do this? So they came up with the idea to do money transfer pumping, Palm pilots, you know, why not? And kind of the built a website. This was the late nineties as a way of just demoing this software to people who didn't have a Palm pilot device next to them. The idea was that you'd kind of see it on the website, learn about it, then maybe download the Palm pilot app and use it in anger. People kept just using the website, they're not downloading the Palm Pilot app. So the product management really wasn't happy. And they were trying to push people from the website to the Palm Pilot app. were trying to, they were fighting against people using this for money transfer on the web and even prohibiting them from using the logo and advertising it. They had this whole thing where nobody could explain why users were using the website because it was a demo thing. It was not finished. It was not sexy. It was just silly. And Jessica kind of talks to one of these people who insists that it was totally inexplicable. Nobody could understand it. But then a bit later, they realized that the website had one and half million users and that the Pongpilot app had 12 ,000 users. So they kind of decided, well, that's where the product is really. And that's like today, people know them as PayPal. They're one of the biggest payment processes in the world because kind of, you know, they realized this is where the product is going. And I think in many, many companies, people Brian (07:03) Ha ha. Gojko (07:18) stumble upon these things as happy accidents. And I think there's a lot more to it. We can deliberately optimize products by looking for unintended usage and not fighting it, just not fighting it. just understand this is what people are getting as value. And I think for me as a solo product founder and developer and product manager on it, One of the really interesting things is when you have somebody engaging with your product in an unexpected way, most of the difficult work for that user is already done. That person knows about you, they're on your website or they're using your product, the marketing and acquisition work is done. But something's preventing them from achieving their goals or they're achieving some value that you did not really know that they're going to achieve. you know, that's something the product can do to help them and remove these obstacles to success. So that's kind of what lizard optimization is making this process more systematic rather than relying on happy accidents. And by making it more systematic, then we can help product management not fight it and skip this whole phase of trying to fight against our users and claim that users are stupid or non -technical or... They don't understand the product, but they're trying to figure out, well, that's what the real goals are. And then following that. Brian (08:47) That's awesome. So the pivot, right? The pivot from here's what we thought our problem was we were solving to now here's what we're actually solving and we should organize around this actual problem, right? Gojko (09:02) or here's what we're going to solve additionally. This is the problem we've solved, but hey, there's this problem as well. And then the product can grow by solving multiple problems for people and solving related problems and solving it for different groups of people, for example. And that's the really interesting thing because I think if you have a product that's already doing something well for your users and a subset of them are misusing it in some way, then kind of... Brian (09:04) Yeah. Gojko (09:30) The product might already be optimized for the majority of users, but there might be a new market somewhere else. So there might be a different market where we can help kind of a different group of users and then the product can grow. Brian (09:43) Yeah, I like to focus on the user. There's an exercise that we'll do in one of our product owner classes where we have a fake product that is a smart refrigerator. And one of the exercises we try to get them to brainstorm the different kinds of users that they might have for it. And one of the things that always comes out in that class is as they're going through and trying to describe the types of users, they inevitably hit to this crossroads where they start to decide Well, yes, we're thinking of this as a home product, something for people to use in their homes. But then the idea crosses their mind, well, what about commercial kitchens? What about people who might use this in another setting? And it's always an interesting conversation to say, well, now you've got a strategic choice to make, because you can target both. You can target one. You can say, we're ignoring the other and we're only going in this direction. So to me, I think that's kind of one of the interesting crossroad points is to say, how do I know when it's time to not just say, great, we have this other customer segment that we didn't know about, but actually we should start to pivot towards that customer segment and start to really target them. Gojko (11:03) Yeah, think that's a fundamental question of product development, isn't it? Do you keep true to your vision even if it's not coming out or if something else is there that's kind more important than I think? For me, there's a couple of aspects to that. One is, laser focus is really important to launch a product. You can't launch a product by targeting... the whole market and targeting a niche type, figuring out, you know, user personas, figuring out like really, really, this is the product who we think the product, this is the group who we think the product is for and giving them a hundred percent of what they need is much better than giving 2 % to everybody because then the product is irrelevant. But then to grow the product, we need to kind of grow the user base as well. And I think one of the things that... is interesting to look at and this comes from a book called Lean Analytics. It's one of my kind of favorite product management books is to look at the frequency and urgency of usage. If you have a group that's kind of using your product, a subgroup that's using your product very frequently compared to everybody else, that might be kind of the place where you want to go. The more frequently, the more urgently people reach for your product when they have this problem. the more likely they are going to be a good market for it. with kind of another product that I've launched in 2013, we originally thought it's going to be a product for professional users. And we aimed at the professional users. And then we found that a subcategory that we didn't really expect, were kind of teachers and children in schools. we're using it a lot more frequently than professional users. And then we started simplifying the user interface significantly so that it can be used by children. And it's a very, very popular tool in schools now. We are not fighting against other professional tools. We were kind of really one of the first in the education market there. And it's still a very popular tool in the education market because we figured a subgroup that's using it very frequently. Brian (13:14) Hmm. Yeah, that's awesome. How do you know when, you know, what kind of threshold do you look for to determine that, this is, because, you know, in your book, you're talking about, you know, behaviors that are not normal, right? People using your product in a way that you didn't anticipate. And what kind of threshold do you look for to that says, hey, it's worth investigating this? You know, I've got this percentage or this number of people who are using it in this strange way. At what point do you chase that down? Gojko (13:49) I think it's wrong to look at the percentages there. I think it's wrong to look at the percentages because then you get into the game of trying to justify economically helping 0 .1 % of the users. And that's never going to happen because what I like about this is an idea from Microsoft's Inclusive Design and the work of Kat Holmes who wrote a book called Mismatch on Brian (13:52) Okay. Gojko (14:17) assistive technologies and inclusive design for disabled people. And she talks about how it's never ever ever going to be economically justified to optimize a product to help certain disabilities because there's just not enough of them. And there's a lovely example from Microsoft where, Microsoft Inclusive Design Handbook where they talk about three types of, Brian (14:34) Yeah. Gojko (14:44) disabilities, one are permanent. So you have like people without an arm or something like that. And I'm going to kind of throw some numbers out now, order of magnitude stuff. I have these details in the book and there's kind of the micro -inclusive design handbook. Let's say at the moment, the 16 ,000 people in the U .S. without one arm or with a disabled arm. And then you have these kind of situational disabilities where because of an occupation like you have a bartender who needs to carry something all the time or a worker who does it, one arm is not available and they only have one arm to work on and this temporary like a mother carrying a child or something like that. So the other two groups are order of magnitude 20 -30 million. We're not, by making the software work well with one hand, we're not helping 16 ,000 people, we are helping 50 million people. But you don't know that you're helping 50 million people if you're just thinking about like 16 ,000. I think they have this kind of, one of the key ideas of inclusive design is solve for one, kind of help, design for one, but solve for many. So we are actually helping many, many people there. So think when you figure out that somebody is doing something really strange with your product, you're not helping just that one person. Brian (15:45) Right, right. Hmm. Gojko (16:13) you're helping a whole class of your users by making the software better, removing the obstacles to success. this is where I, you know, going back to the PowerPoint thing I mentioned, once we started removing obstacles for people to build the audios quickly, lots of other people started using the product and people started using the product in a different way. And I think this is a lovely example of what Bruce Torazzini talks about is the complexity paradox because He's a famous UX designer and he talks about how once you give people a product, their behavior changes as a result of having the product. So the UX research we've done before there is a product or there is a feature is not completely relevant, but it's a changed context because he talks about people have a certain amount of time to do a task. And then when they have a tool to complete the task faster, they can take on a more complicated task or they can take on an additional task or do something else. I think removing obstacles to use a success is really important. Not because we're helping 0 .1 % of people who we don't understand, but because we can then improve the product for everybody. And I think that's kind of the magic of lizard optimization in a sense, where if we find these things where somebody's really getting stuck. but if we help them not get stuck, then other people will use the product in a much better way. And I think this is, know, the name lizard optimization comes from this article by Scott Alexander, who talks about the lizard man's constant in research. And the article talks about his experiences with a survey that combined some demographic and psychological data. So they were looking at where you live and what your nationality is and what gender you are and then how you respond to certain psychological questions. he said, like there's about 4 % of the answers they could not account for. And one person wrote American is gender. Several people listed Martian as nationality and things like that. some of these, he says some of these things will be people who didn't really understand the question. they were distracted, they were doing something else, or they understood the question but they filled in the wrong box because, know, the thick thumbs and small screens, or they were kind of malicious and just, you know, wanted to see what happens. when you kind of add these people together, they're not an insignificant group. kind of, he says 4%. And if... we can help these people, at least some of these people, and say reduce churn by 1%. That can compound growth. Reducing churn, keeping people around for longer is an incredible way to kind of unlock growth. going back to what we were talking about, some people might be getting stuck because they don't understand the instructions. Some people might be getting stuck because they're using the product in a way you didn't expect. And some people might just like not have the mental capacity to use it the way you expected them to be used. But if we can help these people along, then normal users can use it much, easier. And you mentioned a smart fridge. I still remember there was this one wonderful bug report we had for my other product, which is a collaboration tool. we had a bug report a while ago. that the software doesn't work when it's loaded on a fridge. And it's like, well, it was never intended to be loaded on a fridge. I have no idea how you loaded it on a fridge. It's a mind mapping diagramming tool. It's intended to be used on large screens. Where does a fridge come in? And then we started talking to this person. This was before the whole kind of COVID and work from home disaster. The user was a busy mother and she was kind of trying to collaborate with her colleagues while making breakfast. breakfast for kids and kind of running around the kitchen she wasn't able to kind of pay attention to the laptop or a phone but her fridge had a screen so she loaded the software on the fridge and was able to kind of pay attention to collaboration there and you know we of course didn't optimize the software to run on fridges that's ridiculous but we realized that some people will be using it without a keyboard and without a mouse and then we kind of restructured the toolbar, we made it so that you can use it on devices that don't have a keyboard and then the whole tablet thing exploded and now you get completely different users that don't have keyboards and things like that. I think that's where I think is looking at percentages is a losing game because then you start saying, but 0 .1 % of people use this. But yeah, I think lizard optimization is about using these signals to improve the products for everybody. Brian (21:30) That's a great example. I love that example because you're absolutely right. You're not trying to necessarily solve that one problem because you don't anticipate there's going to be a lot of people who are going to want to run that software on a fridge. However, the takeaway you had from that of, we can do this for people who don't have a keyboard or a mouse. There's another way that they might operate this that could apply to lots of different devices and lots of different scenarios. Now we're talking about a much bigger audience. Now we're talking about opening this up to larger segments of the population. I love that. I think that's a great example. I know you talk about that there's kind of a process for this. Help us understand. You don't have to give away the whole candy story here from the book, but help us kind of understand in broad, terms what kind of process people follow to try to chase these things down. Gojko (22:26) So there's like a four step process that's crystallized for me. And the book is kind of more as a, like a proposal or a process. It's something that works for me and I'm hoping that other people will try it out like that. So it might not necessarily stay like that in a few years if we talk again. And I've narrowed it down to four steps and kind of the four steps start with letters L, Z, R and D. Lizard. And it's kind of so learn how people are misusing your products, zero in on one area, on one behavior change you want to improve, then remove obstacles to use a success and then double check that what you've done actually created the impact you expected to make. I think kind of when we look at people who follow their own logic or people who follow some lizard logic you don't really understand, by definition they're doing something strange. your idea of helping them might not necessarily be effective or it might not go all the way or it might. So double checking at the end that people are actually now doing what you expect them to do or doing something better is really, really, really important. And then using signals from that to improve the kind of feedback loop is critical. I had this one case where people were getting stuck on a payment format entering tax details and The form was reasonably well explained. There was an example in the forum how to enter your tax ID and people were constantly getting stuck. A small percentage of people was getting stuck on it. However, I don't want to lose a small percentage of people that want to pay me on the payment form. So I thought, well, how about if I remove that field from there? I speed it up for everybody and then I can guide them later into entering the tax details to generate an invoice. I thought that was a brilliant idea. tested it with a few users. Everybody loved it, so I released it. And then a week later, I realized that, yes, I've sold it for the people that were getting confused, but I've ended up confusing a totally different group of people that expects the tax fields there. So the net effect was negative. then I went back to the original form. so there's lots of these things where people don't necessarily behave the way you think they will. Brian (24:38) Hahaha. Gojko (24:48) Ron Kohavi has a wonderful book about that called Trustworthy Online Experiments. And he has data from Slack, from Microsoft, from Booking .com and... The numbers are depressive. on one hand, the numbers range from 10 to 30, 40 % success rate for people's ideas. And if leading companies like that do things that don't pan out two thirds of the time, then we have to be honest building our products and say, well, maybe this idea is going to work out, maybe not. Brian (25:03) Hahaha. Wow. Gojko (25:30) the more experimental the population is, the more risky that is. think monitoring and capturing weird user behaviors, capturing errors helps you understand that people are getting stuck. as you said, you don't want to follow everybody. There's going to be a lot of noise there. We need to extract signals from the noise. That's what the second step is about, focusing on one specific thing we want to improve. Then, try to remove obstacles and then double -checking that we've actually removed them. That's the four steps. And there's like a shorter version of all the four steps. It's easier to remember. It's listen alert, zooming, rescue them, and then double check at the end. that's again, LZRD. Brian (26:13) That's awesome. Yeah, I love the process and I love the kind of steps there. Are there tools that you recommend for this that are easier to try to determine these things or chase them down or are there tools that you find are more helpful? Gojko (26:32) So there's lots of tools today for things like A -B testing and looking at experiments and things that are very helpful to do this scale. And it's kind of especially useful for the last step. In terms of kind of focusing and things like that, the five stages of growth from the linear analytics are a good tool. Impact mapping is a good tool. Kind of any focusing product management technique that says, well, these are the business goals we're working on now, or these are the kind of user goals we're working on now. out of, know, 50 lizards we found last week, these three lizards seem to be kind of in that area. And for the first step, spotting when people are getting stuck, there's a bunch of tools that are interesting, like session recorders for web products. There's one from Microsoft called Clarity that's free. There's another called Full Story that's quite expensive. There's a couple of open source one, one is packaged within Matomo analytics application. There's a bunch of these other things. Any kind of observability or monitoring tool is also very useful for this because we can spot when people are getting stuck. One of the things I found particularly helpful is logging all user errors. When a user does something to cause an error condition in a product, the product of course tells them like, know, an error happened. But then... logging it and analyzing that information in the back is really critical. for something like that, people sometimes use web analytics tools or any kind of product analytics. I think what's going to be interesting in the next couple of years, and I think if people start doing this more, is we'll see. more like these technical exception analytics tracking tools mixed with this because most of the product analytics are showing people what they expect to see, not what they don't expect to see. And I'll just give you an example of this way. was really helpful. So I've mentioned the screen where people can upload the Word documents. Occasionally people would select weird file types. So they'll select images, they'll select, I don't know, what else. Brian (28:31) Yeah. Gojko (28:49) Sometimes I guess that's a result of, know, a fat finger press or somebody not selecting the right thing. I have a not insignificant percentage of users every day that try to upload Android package files into a text -to -speech reader. Android package files and application files, I don't know what the right way is to read out an Android application. My best guess is people are doing that. as a, you know, these things where you drop a USB in front of an office and somebody kind of mistakenly plugs it in. So maybe they're hoping that I'll know the Android application on my phone just because they've uploaded it. I don't know, but a small percentage of users was trying to upload files that had SRT and VTT extensions, which are subtitle files. And they were not supported, but Brian (29:31) Yeah. Gojko (29:45) I kept getting information that people are uploading those types of files. And then I said, well, this is interesting because it's a text to speech system. People are uploading subtitle files, there's text in, so why don't I just ignore the timestamps and read the text? I can do that. And I started supporting that. And then some people started complaining that, well, the voice is reading it slower than the subtitles. I said, well, yes, because... Brian (30:11) Ha Gojko (30:12) You know, you're uploading subtitles that were read by an actor in a movie. This is a voice that's reading it at their speed. And then we started talking and it turns out that these people were doing it for corporate educational videos where they have a video in English, they need it in French, German, Spanish and all the else, but they don't want to kind of re -edit the video. They just want an alternate audio track. Okay, I mean, I have the timestamps, we can speed up or slow down the audio, it's not a big deal. And we've done that and this was one of the most profitable features ever. Like a very small percentage of the users need it, but those that need it produce hundreds of thousands of audio files because they translate the corporate training videos. And now, you know, we're getting into that numbers game. If I said, you know, there's like 0 .1 % of people are uploading subtitle files. Brian (30:58) Yeah. Gojko (31:07) then it doesn't matter. if we start thinking about, this is potentially interesting use case, it creates growth on its own because then people find you. And I think my product was the first that was actually doing synchronous subtitles. Competitors are doing it now as well. But it opened the massive, massive market for us. And people, you know, I got there by monitoring user errors, by, you know, the fact that somebody uploaded a file that had an unsupported extension. That was our insight. Brian (31:38) Wow, that's really cool. That's a great story. This is fascinating stuff. And it makes me want to dive deeper into the book and read through it again. But I really appreciate you coming on and sharing this with us, Goiko. This is good stuff. Again, the book is called, Lizard Optimization, Unlock Product Growth by Engaging Long Tail Users. And if I'm right, we talked about this a little bit before. We're going to offer a discount to to the listeners, Gojko (32:07) Yes, we will give you a listen as a 50 % discount on the ebook. the ebook is available from Lean Pub. If you get it from the discount URL that I'll give you, then you'll get a 50 % discount immediately. Brian (32:24) Awesome. So we'll put that in our show notes. If you're interested in that, you can find the show notes. That's a great deal, 50 % off the book and it's good stuff. well, I just, I can't thank you enough. Thanks for making time and coming on and talking this through your book. Gojko (32:40) Thank you, it was lovely to chat to you.

Create, nurture, and increase empathy with all your customers, even the ones you didn't know you had! Inspired by Gojko Adzic and his new book Lizard Optimisation, Squirrel and Jeffrey discuss how you can do just that, on this episode of Troubleshooting Agile. Links: - Gojko's book, Lizard Optimisation: https://www.amazon.com/Lizard-Optimization-Product-Engaging-Long-Tail/dp/0993088171 - Kahneman Thinking, Fast and Slow: https://en.wikipedia.org/wiki/Thinking,_Fast_and_Slow -------------------------------------------------- You'll find free videos and practice material, plus our book Agile Conversations, at agileconversations.com And we'd love to hear any thoughts, ideas, or feedback you have about the show: email us at info@agileconversations.com -------------------------------------------------- About Your Hosts Douglas Squirrel and Jeffrey Fredrick joined forces at TIM Group in 2013, where they studied and practised the art of management through difficult conversations. Over a decade later, they remain united in their passion for growing profitable organisations through better communication. Squirrel is an advisor, author, keynote speaker, coach, and consultant, and he's helped over 300 companies of all sizes make huge, profitable improvements in their culture, skills, and processes. You can find out more about his work here: douglassquirrel.com/index.html Jeffrey is Vice President of Engineering at ION Analytics, Organiser at CITCON, the Continuous Integration and Testing Conference, and is an accomplished author and speaker. You can connect with him here: www.linkedin.com/in/jfredrick/

The products you have today could be 5x more profitable if you found out how customers really use them and tuned accordingly, says Gojko Adzic - and we're inclined to agree! Find out how to do it on this episode ofTroubleshooting Agile your hosts, Squirrel and Jeffrey. Links: - Gojko's book, Lizard Optimisation: https://www.amazon.com/Lizard-Optimization-Product-Engaging-Long-Tail/dp/0993088171 - Gojko Adzic on LinkedIn https://www.linkedin.com/in/gojko/ - Long tail: https://en.wikipedia.org/wiki/Long_tail - Nassim Taleb: https://en.wikipedia.org/wiki/Nassim_Nicholas_Taleb -------------------------------------------------- You'll find free videos and practice material, plus our book Agile Conversations, at agileconversations.com And we'd love to hear any thoughts, ideas, or feedback you have about the show: email us at info@agileconversations.com -------------------------------------------------- About Your Hosts Douglas Squirrel and Jeffrey Fredrick joined forces at TIM Group in 2013, where they studied and practised the art of management through difficult conversations. Over a decade later, they remain united in their passion for growing profitable organisations through better communication. Squirrel is an advisor, author, keynote speaker, coach, and consultant, and he's helped over 300 companies of all sizes make huge, profitable improvements in their culture, skills, and processes. You can find out more about his work here: douglassquirrel.com/index.html Jeffrey is Vice President of Engineering at ION Analytics, Organiser at CITCON, the Continuous Integration and Testing Conference, and is an accomplished author and speaker. You can connect with him here: www.linkedin.com/in/jfredrick/

What must attend free online testing events is just a few weeks away? Why making testing mistakes is important and what you can learn from them Have you seen this news open source tool that helps you to gain immediate insights into your Playwright and Cypress automation project? Find out in this episode of the Test Guild New Shows for the week of Aug 11  So, grab your favorite cup of coffee or tea, and let's do this. Time Title Link 0:25 Testμ Conference https://testguild.me/testmu  1:40 Making Mistakes https://testguild.me/niq14y 2:31 Gojko Adzic https://testguild.me/r49mdf 2:58 Playwright https://testguild.me/4uixuf 3:39 Test Complex Multi-Systems https://testguild.me/5wk1ij 4:36 Open Source  test results https://testguild.me/4vccyt 5:48 Amiko AI https://testguild.me/ja8q0w 6:33 Autonomous 2.0 https://testguild.me/p343ey 7:23 AudioEye Accessibility Testing  https://testguild.me/dg91mw 8:23 Performance SHIFT https://bit.ly/3YANEU2 9:10 AttackIQ's Flex  2.0 https://testguild.me/3wnw5p

Today, we have a special guest, Gojko Adzic, who introduces his new book "Lizard Optimization." Check out BrowserStack Test Management testguild.me/browserstack Join us as Gojko walks us through the significant value testers can bring to organizations beyond merely reporting bugs and evaluating product readiness. We'll delve into his rich experiences with user behavior at scale and the formidable challenges he's faced while offering practical strategies to unlock remarkable product growth. In this episode, we discuss Gojko's innovative four-step lizard optimization method and the hidden power of edge cases. Gojko emphasizes testers' fundamental role in product innovation, mainly through experimentation and user behavior analysis. We'll also touch on the balance between addressing accessibility needs and identifying obstacles in user workflows to enhance usability for everyone. Listen in as Joe and Gojko explore the insightful intersection of user expectations and software design, leveraging customer support data for product improvements and the transformative potential of monitoring production environments. Whether you're a software tester, developer, or product manager, this episode is packed with actionable insights and thought-provoking perspectives that promise to elevate your approach to software development and user engagement. Don't miss out!

SummaryIn this episode, Goiko shares his experiences and insights on visualizing specifications, writing Specification by Example, and solving communication problems in software development. He discusses the challenges and patterns in the adoption of Spec by Example and the importance of identifying bottlenecks and visualizing problems. Goiko also talks about causing organizational change and the evolution of software development solutions. He concludes by discussing the promise and reality of no-code tools and sharing his recent work and projects. The conversation explores various themes related to software development and its impact on organizations and society. It discusses the power of expressing human knowledge in software and the role of visualization tools in increasing shared understanding. The shift from specialists to generalists in the software industry is examined, as well as the potential for smaller organizations and general-purpose work. The conversation also delves into the role of AI in minimizing political games in organizations and the responsibility of software professionals in creating good software. The need for spending more time on edge cases and negative use cases is highlighted, along with the societal impact of bad software and the potential for IT to become a profession. The conservation and shifting of complexity in software development is explored, and the conversation concludes with a discussion on the impact of shoddy software on people's lives.TakeawaysVisualizing specifications can help improve understanding and reduce rework in software development.The adoption of Spec by Example and other agile practices can be hindered by organizational politics and resistance to change.Identifying bottlenecks and visualizing problems can lead to effective solutions and improvements in software development processes.No-code tools have the potential to democratize software development and empower non-technical users to create automation. Visualization tools like FigJam and Zeppelin increase shared understanding in organizations.The software industry is shifting towards smaller organizations and general-purpose work.AI cannot eliminate political games in organizations, as they are driven by cultural factors.There is a need for more focus on edge cases and negative use cases in software development.The responsibility of software professionals is to create good software and address the societal impact of bad software.Gojko's booksCheck out our sponsors:www.xebia.comwww.wiserbees.comwww.scrummatch.comwww.masteringagility.orgSound BitesChapters00:00Introduction01:21Visualizing Specifications03:04Early Experiences with Software Quality04:09Solving Communication Problems05:31Validating Real-World Usage of Spec by Example06:29Getting Permission from Companies for Case Studies08:28Persistent Challenges and Positive Patterns09:49Adoption of Given-When-Then and Consolidation of Tools11:42Identifying Bottlenecks and Visualizing Problems13:01Causing Organizational Change14:09The Challenge of Change Resistance16:30The Evolution of Software Development Solutions26:48Goiko's Recent Work and Projects35:26The Power of Expressing Human Knowledge in Software36:03Visualization Tools and Increased Shared Understanding37:27Specialists vs. Generalists in the Software Industry38:49The Shift Towards Smaller Organizations and General Purpose Work41:49The Role of AI in Minimizing Political Games in Organizations42:54The Responsibility of Software Professionals in Creating Good Software51:01The Need for Spending More Time on Edge Cases and Negative Use Cases53:31The Societal Impact of Bad Software and the Role of Governments57:41The Potential for IT to Become a Profession01:01:29The Conservation and Shifting of Complexity in Software Development01:04:43The Impact of Shoddy Software on People's Lives

In this episode, Dave Farley chats with Gojko Adzic. Gojko is a prolific author, international speaker on software and expert practitioner in DDD, BDD and an AWS Serverless Hero. Dave and Gojko chat about a wide-ranging series of topics on product development, steering development organisations to success, Palchinsky principles and how agile development failed for the FBI and the BBC. It's a fun episode! ( ➡️ https://gojko.net)xxGojko's new text-to-speech video maker ➡️ https://www.narakeet.com MindMup - MindMapping tools ➡️ https://www.mindmup.com

Eine Folge zum Impact Mapping war dringend überfällig! Über diese sehr starke Praktik im Produktmanagement spricht Tim Klein daher mit Büşra Coşkuner aus Zürich. Sie ist Product Management Coach und eine der absoluten Expertinnen zum Impact Mapping im deutschsprachigen Raum. Tim liebt ja bekanntlich eh quasi alle Mapping Techniken, weil sie durch die Visualisierung für so viel mehr Klarheit sorgen und Entscheidungen sowie Zusammenhänge explizit machen. Daher setzt er diese Methode auch schon viele Jahre selber ein. Büşra hat den Ansatz aber nochmal weiterentwickelt (Adjusted Impact Map) und ist sehr erfahren in ihrer Anwendung mit Produktteams. Die Praktik wurde insbesondere durch Gojko Adzic und sein (sehr dünnes) Buch "Impact Mapping: Making a big impact with software products and projects" bekannt. Viele weitere Erklärungen und Ressourcen findet ihr auf impactmapping.org. Impact Mapping klärt insbesondere die Frage, was wir versuchen bzw. umsetzen könnten, damit bestimmte Akteure ihr Verhalten in einer Art und Weise verändern, die eine (positive) Wirkung auf ein von uns verfolgtes Businessziel haben könnte. Gemeinsam sucht man also Zusammenhänge von "Why" - "Who" - "How" und "What" und visualisiert sie in einer Art Mindmap. Während die ursprüngliche Idee in dieser Reihenfolge erfolgt, schlägt Büşra Coşkuner vor, auch mal eine "Reverse Impact Map" auszuprobieren. Das Vorgehen erklärt sie in ihrem entsprechenden Blog-Artikel (busra.co/post/the-reverse-impact-map-and-mindset-shift-voodoo). Ein weiterer guter passender Artikel von ihr beleuchtet den Outcome-Fokus sowie den Zusammenhang zu OKR (Outcome-focus with Impact Mapping: busra.co/post/mini-series-outcome-focus-with-impact-mapping/). Es lohnt sich übrigens sehr, ihrem Blog zu folgen! Wie im Gespräch von Büşra bereits angeboten, hat sie uns dankenswerter Weise auch ihre zwei Templates aus den Übungen ihres Trainings zur Verfügung gestellt: Template 1: Wenn man z.B. schon weiß, dass man etwa bestimmtes umsetzen möchte, wäre ein Aufbau für einen Mini-Pitch: In order to achieve [IMPACT], we want to help/make [ACTOR] to/with [OUTCOME] with/by [OUTPUT]. Our riskiest assumptions are [ASSUMPTION 1], [ASSUMPTION 2], [ASSUMPTION 3]. …und falls dieser Detail-Level erwünscht ist: We'll test our assumption with these experiments: [EXPERIMENT 1], [EXPERIMENT 2], …[EXPERIMENT n] Template 2: Wenn wir es noch nicht wissen, weil da ganz fette Annahmen dahinterstecken und wir mehr Daten brauchen: We believe that by [doing this output] --> Solution for [these people] --> Actor we'll achieve [This Outcome] --> Impact which we believe will lead to [this business result] --> Goal We'll know if we are right, when we achieve [quant. or qual. indicators or results]. We'll test our assumption with these experiments: [EXPERIMENT 1], [EXPERIMENT 2], … [EXPERIMENT n] Weitere Podcast-Folgen und Quellen, auf die Tim und Büşra im Laufe des Gesprächs hinweisen: - Data-Fluent Product Manager (mit Büşra) - Outcome Goals & Product Discovery (mit Tim Herbig) - Evidence Based Management - eine empirische Suche nach Wert (mit Boris Steiner und Glenn Lamming) - Opportunity Solution Trees von Teresa Torres (producttalk.org/opportunity-solution-tree/) Falls Du mit Büşra Kontakt aufnehmen oder ihr folgen möchtest, kannst Du Dich über ihr LinkedIn Profil (linkedin.com/in/busra-coskuner/) mit ihr verbinden. Kanntest du Impact Mapping bereits vorher? Hast du eventuell selbst schon mal an einer solchen Mapping Session in Präsenz oder Remote teilgenommen? Wir freuen uns, wenn du deine Erfahrungen aus der Praxis mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite. **Folgt uns Produktwerker auf** - LinkedIn -> https://bit.ly/3gWanpT - Twitter -> https://bit.ly/3NitkPy - Youtube -> https://bit.ly/3DIIvhF - Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> https://bit.ly/3Why63K

This week, our heroes talk with speaker, author, and software engineer Gojko Adzic about how software can go horribly wrong. When it does it can affect our lives in troubling, frustrating, and unexpected ways. The post From the Archives: Peak Software $#!% with Gojko Adzic appeared first on Retro Time.

elcome to another episode of the Testing Peers podcast, this time we have a slightly different show for you.Regular host, Chris is joined by the wonderful Heather Reid, as we look back over the brilliant article Heather wrote back in 2017 - 30 Things Every New Software Tester Should Learn on the Ministry of Testing site.Before we look back at Heather's article, we talk about anything from our past online that we might find a little cringey.Then we review the article, written almost exactly six years ago, talking through all 30 tasks, and Heather provides some insight into each task, as well as where she would make changes, remove or replace any task.We cover a lot of interesting topics, and below are links to some of the things we discuss.QA In Your Job Titles? - Ministry of Testing (The Club)Learning How to Learn: Powerful mental tools to help you master tough subjects - CourseraMaking Work Visible: Exposing Time Theft to Optimize Workflow by Dominica Degrandis (Book via Amazon)Ministry of Testing - Go Pro!Team Guide to Software Testability: Better software through greater testability by Ash Winter and Rob Meaney (Book via Amazon)Fifty Quick Ideas to Improve Your User Stories by Gojko Adzic and David Evans (Book via Amazon)Starting Your Software Testing Career by Nicola Lindgren (Book via Leanpub)How Can I Test This? by Nicola Lindgren, Mike Harris, Suman Bala, Philip Wong, and Shawn Shaligram (Book via Leanpub)Testing Web APIs by Mark Winteringham (Book via Amazon)Contemporary Exploratory Testing by Maaret Pyhäjärvi (Book via Leanpub)Would Heu-Risk it? Tools, traps and weapons for Software Testing by Lena Wiberg (Book via Leanpub)Understanding where quality starts as a tester - Vernon Richards (via LinkedIn)Software Testing Heuristics: Mind The Gap! by Richard Bradshaw and Sarah Deery (via Ministry of Testing)Workroom Productions - Get Better at Software TestingAccessibility Testing 101 - Crystal Preston-Watson (Talk from TestBash San Francisco 2019, via Ministry of Testing PRO)Introduction To Accessibility Testing - Deborah Reid (Course via Ministry of Testing)The Big Test Theory - Ady StokesSupport the show

Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Julie was part of a team supporting a large program of 10 scrum teams. The team that Julie was working with, started to skip the retrospectives because they were trying to catch-up. However, after they had been able to catch-up, the team did not come back to start holding their retrospectives again. When should the Scrum Master stand-up and push the team to hold their retrospectives again? In this episode, we talk about the critical role Scrum Masters play in keeping the teams accountable to themselves when it comes to process, and how sometimes, it is important to stop, even if that affects delivery, because retrospectives are the “power station” for the rest of the work the team does.  Featured Book of the Week: Impact Mapping, by Gojko Adzic In Impact Mapping: Making a Big Impact with Software Products and Projects by Gojko Adzic, Julie found a way to crystalize the concept of business impact. Impact Mapping, is a short book with lot of visuals. You can also learn about Impact Mapping in Gojko Adzic's presentation on Impact Mapping.  How can Angela (the Agile Coach) quickly build healthy relationships with the teams she's supposed to help? What were the steps she followed to help the Breeze App team fight off the competition? Find out how Angela helped Naomi and the team go from “behind” to being ahead of Intuition Bank, by focusing on the people! Download the first 4 chapters of the BOOK for FREE while it is in Beta! About Julie Wyman Julie Wyman has been working with Agile teams for over a decade and is continuously learning with and from them. She's based just outside Washington, D.C., but has had the pleasure of supporting teams distributed across the globe and even experienced her own Agile takeaways all the way in Antarctica. You can link with Julie Wyman on LinkedIn.

En este episodio hablamos con el desarrollador Full Stack Pablo Carballo, que nos cuenta sobre su proyecto con una empresa en EEUU dedicada a crear motores inteligentes y sustentables. Pablo trabaja bajo la metodología Specification by Example, y en esta conversación nos cuenta de que se trata el SBE y sus beneficios a los proyectos de desarrollo. Links mencionados en este episodio: “Specification By Example”, de Gojko Adzic: https://www.amazon.com/Specification-Example-Successful-Deliver-Software/dp/1617290084/ “Behavior Driven Development with Cucumber”, de Richard Lawrence y Paul Rayner: https://www.amazon.com/Behavior-Driven-Development-Cucumber-Collaboration-Software-ebook/dp/B07S649RQ8/ Para aprender el lenguaje Gherkin: https://behave.readthedocs.io/en/stable/ ¡Seguinos! @octobotdev en Twitter, Instagram y Dribble, y @octobot en LinkedIn

Our series of interactive events in live streaming with our experts, an informal 30-minute chat on their area of expertise where you'll have a chance to interact with them, ask questions and learn straight from the source.The first Small Talk of the year will see the comeback of Gojko Adzic, book author and one of our trainers. Let's understand a bit more about Specification By Example, a book he published in 2011 (which is also the title of his upcoming workshop).In a nutshell, Specification By Example is a collaborative approach to defining requirements and tests based on capturing realistic examples instead of abstract statements.Small Talk is a chance to go behind the scenes of our experts' work and get a sneak peek of what their workshop will be about and, as usual, you'll be able to join the conversation by asking questions from home.Always wanted to ask a trainer that burning question about what they do? Now you have a chance!We'll discuss how Gojko's Specification By Example workshop was born, why it is useful, if it is still relevant after more than 10 years from its creation, what type of professionals will benefit from this the most, what type of exercises we'll be doing in the workshop and how these will enable you to learn the key concepts during the class.Did we say it already? You're encouraged to be part of the conversation and ask questions during the live streaming through the chat provided by YouTube.Who: Gojko Adzic is a partner at Neuri Consulting LLP. He is the winner of the 2016 European Software Testing Outstanding Achievement Award, and the 2011 Most Influential Agile Testing Professional Award.Author of: Specification By Example, Impact Mapping, Fifty Quick Ideas To Improve Your User Stories, Humans vs Computers.Workshop link: https://bit.ly/SpecificationByExample_Podcast#SpecificationByExample #SoftwareTesting #Testing #ProductOwner #SoftwareDevelopment #Communication #Implementation #Team #TeamWork #SoftwareDeveloper #SoftwareTester #Agile #Scrum #Kanban #UserStory #Software #Test #Example #Lean #LeanThinking #ExtremeProgramming #Requirements #ImpactMapping #Requirements

Our series of interactive events in live streaming with our experts, an informal 30-minute chat on their area of expertise where you'll have a chance to interact with them, ask questions and learn straight from the source.The first Small Talk of the year will see the comeback of Gojko Adzic, book author and one of our trainers. Let's understand a bit more about Specification By Example, a book he published in 2011 (which is also the title of his upcoming workshop).In a nutshell, Specification By Example is a collaborative approach to defining requirements and tests based on capturing realistic examples instead of abstract statements.Small Talk is a chance to go behind the scenes of our experts' work and get a sneak peek of what their workshop will be about and, as usual, you'll be able to join the conversation by asking questions from home.Always wanted to ask a trainer that burning question about what they do? Now you have a chance!We'll discuss how Gojko's Specification By Example workshop was born, why it is useful, if it is still relevant after more than 10 years from its creation, what type of professionals will benefit from this the most, what type of exercises we'll be doing in the workshop and how these will enable you to learn the key concepts during the class.Did we say it already? You're encouraged to be part of the conversation and ask questions during the live streaming through the chat provided by YouTube.Who: Gojko Adzic is a partner at Neuri Consulting LLP. He is the winner of the 2016 European Software Testing Outstanding Achievement Award, and the 2011 Most Influential Agile Testing Professional Award.Author of: Specification By Example, Impact Mapping, Fifty Quick Ideas To Improve Your User Stories, Humans vs Computers.Workshop link: https://bit.ly/SpecificationByExample_Podcast#SpecificationByExample #SoftwareTesting #Testing #ProductOwner #SoftwareDevelopment #Communication #Implementation #Team #TeamWork #SoftwareDeveloper #SoftwareTester #Agile #Scrum #Kanban #UserStory #Software #Test #Example #Lean #LeanThinking #ExtremeProgramming #Requirements #ImpactMapping #Requirements

Introducing Small Talk, our new series of interactive events in live streaming. Each episode will feature one of our experts and we'll have an informal chat on their area of expertise.This time we talk with Gojko Adzic, book author and one of our trainers, about Impact Mapping (which is also the title of his upcoming workshop).Small Talk is a chance to go behind the scenes of our experts' work and get a sneak peek of what their workshop will be about and, as usual, you'll be able to join the conversation by asking questions from home.Always wanted to ask a trainer that burning question about what they do? Now you have a chance!We'll discuss how his Impact Mapping workshop was born, Gojko's writing routine, why Impact Mapping is useful, what type of professionals will benefit from this the most, what type of exercises we'll be doing in the workshop and how these will enable you to learn the key concepts of the workshop.Did we say it already? You're encouraged to be part of the conversation and ask questions during the live streaming through the chat provided by YouTube.Who: Gojko Adzic is a partner at Neuri Consulting LLP. He is the winner of the 2016 European Software Testing Outstanding Achievement Award, and the 2011 Most Influential Agile Testing Professional Award.Author of: Impact Mapping, Fifty Quick Ideas To Improve Your User Stories, Humans vs Computers.Workshop link: http://bit.ly/Gojko_Adzic_PO_Key_Skills_Avanscoperta_Podcast#ImpactMapping #ProductOwner #ProjectManagement #ProjectMgmt #Agile #Scrum #Kanban #GojkoAdzic #SpecificationByExample #SoftwareTesting #Software #SoftwareDevelopment

Introducing Small Talk, our new series of interactive events in live streaming. Each episode will feature one of our experts and we'll have an informal chat on their area of expertise.This time we talk with Gojko Adzic, book author and one of our trainers, about Impact Mapping (which is also the title of his upcoming workshop).Small Talk is a chance to go behind the scenes of our experts' work and get a sneak peek of what their workshop will be about and, as usual, you'll be able to join the conversation by asking questions from home.Always wanted to ask a trainer that burning question about what they do? Now you have a chance!We'll discuss how his Impact Mapping workshop was born, Gojko's writing routine, why Impact Mapping is useful, what type of professionals will benefit from this the most, what type of exercises we'll be doing in the workshop and how these will enable you to learn the key concepts of the workshop.Did we say it already? You're encouraged to be part of the conversation and ask questions during the live streaming through the chat provided by YouTube.Who: Gojko Adzic is a partner at Neuri Consulting LLP. He is the winner of the 2016 European Software Testing Outstanding Achievement Award, and the 2011 Most Influential Agile Testing Professional Award.Author of: Impact Mapping, Fifty Quick Ideas To Improve Your User Stories, Humans vs Computers.Workshop link: http://bit.ly/Gojko_Adzic_PO_Key_Skills_Avanscoperta_Podcast#ImpactMapping #ProductOwner #ProjectManagement #ProjectMgmt #Agile #Scrum #Kanban #GojkoAdzic #SpecificationByExample #SoftwareTesting #Software #SoftwareDevelopment

This interview was recorded at GOTO Berlin 2019 for GOTO Unscripted.https://gotopia.techRead the full transcription of this interview here:https://gotopia.tech/articles/adoption-and-future-perspective-cloudLynn Langit - Cloud Architect at Lynn Langit ConsultingGojko Adzic - Partner at Neuri ConsultingPreben Thorø - CTO at Trifork SwitzerlandDESCRIPTIONJoin Gojko Adzic, award-winning author and software delivery consultant, and Lynn Langit, cloud architect building serverless bioinformatics cloud data pipelines, to discuss the cloud ecosystem, exploring common and actual use cases and why there are different cloud adoption patterns in different regions across the globe as well as in different industries. They also touch upon what are the next cloud adopters, banks, state institutions, and where the cloud industry heading.RECOMMENDED BOOKSLynn Langit • Foundations of SQL Server 2005 Business Intelligence • https://amzn.to/3hFqXXLLynn Langit • Foundations of SQL Server 2008 R2 Business Intelligence • https://amzn.to/3dQ2BteGojko Adzic • Impact Mapping • https://amzn.to/3dQFCOqAdzic, Evans & Roden • Fifty Quick Ideas To Improve Your Tests • https://amzn.to/3yuDaoLAdzic, Evans & Korac • Fifty Quick Ideas to Improve Your User Stories • https://amzn.to/3jQ4QjPAdzic & Korac • Humans vs Computers • https://amzn.to/2Utz55AGojko Adzic • Specification by Example • https://amzn.to/3hHrEjbAdzic, Marcetic & Bisset • Bridging the Communication Gap • https://amzn.to/3wrjmRQAdzic & Korac • Running Serverless • https://amzn.to/3ytdF7ohttps://twitter.com/GOTOconhttps://www.linkedin.com/company/goto-https://www.facebook.com/GOTOConferencesLooking for a unique learning experience?Attend the next GOTO conference near you! Get your ticket at https://gotopia.techSUBSCRIBE TO OUR YOUTUBE CHANNEL - new videos posted almost daily.https://www.youtube.com/user/GotoConferences/?sub_confirmation=1

As testers, we need to change with the times. What may have made sense to automate ten years ago may not still apply today. In this episode, Gojko Adžić will share five universal rules for test automation. Discover why the test pyramid may no longer apply to modern test automation, and learn about some newer approaches to testing. Listen up and find out how to automate non-deterministic tests.

About Gojko AdzicGojko Adzic is a partner at Neuri Consulting LLP. He one of the 2019 AWS Serverless Heroes, the winner of the 2016 European Software Testing Outstanding Achievement Award, and the 2011 Most Influential Agile Testing Professional Award. Gojko’s book Specification by Example won the Jolt Award for the best book of 2012, and his blog won the UK Agile Award for the best online publication in 2010.Gojko is a frequent speaker at software development conferences and one of the authors of MindMup and Narakeet.As a consultant, Gojko has helped companies around the world improve their software delivery, from some of the largest financial institutions to small innovative startups. Gojko specializes in agile and lean quality improvement, in particular impact mapping, agile testing, specification by example, and behavior driven development.Twitter: @gojkoadzicNarakeet: https://www.narakeet.comPersonal website: https://gojko.netWatch this video on YouTube: https://youtu.be/kCDDli7uzn8This episode is sponsored by CBT Nuggets: https://www.cbtnuggets.com/TranscriptJeremy: Hi everyone, I'm Jeremy Daly and this is Serverless Chats. Today my guest is Gojko Adzic. Hey Gojko, thanks for joining me.Gojko: Hey, thanks for inviting me.Jeremy: You are a partner at Neuri Consulting, you're an AWS Serverless Hero, you've written I think, what? I think 6,842 books or something like that about technology and serverless and all that kind of stuff. I'd love it if you could tell listeners a little bit about your background and what you've been working on lately.Gojko: I'm a developer. I started developing software when I was six and a half. My dad bought a Commodore 64 and I think my mom would have kicked him out of the house if he told her that he bought it for himself, so it was officially for me.Jeremy: Nice.Gojko: And I was the only kid in the neighborhood that had a computer, but didn't have any ways of loading games on it because he didn't buy it for games. I stayed up and copied and pasted PEEKs and POKEs in a book I couldn't even understand until I made the computer make weird sounds and print rubbish on the screen. And that's my background. Basically, ever since, I only wanted to build software really. I didn't have any other hobbies or anything like that. Currently, I'm building a product for helping tech people who are not video editing professionals create videos very easily. Previously, I've done a lot of work around consulting. I've built a lot of product that is used by millions of school children worldwide collaborate and brainstorm through mind-mapping. And since 2016, most of my development work has been on Lambda and on team stuff.Jeremy: That's awesome. I joke a little bit about the number of books that you wrote, but the ones that you have, one of them's called Running Serverless. I think that was maybe two years ago. That is an excellent book for people getting started with serverless. And then, one of my probably favorite books is Humans Vs Computers. I just love that collection of tales of all these things where humans just build really bad interfaces into software and just things go terribly.Gojko: Thank you very much. I enjoyed writing that book a lot. One of my passions is finding edge cases. I think people with a slight OCD like to find edge cases and in order to be a good developer, I think somebody really needs to have that kind of intent, and really look for edge cases everywhere. And I think collecting these things was my idea to help people first of all think about building better software, and to realize that stuff we might glance over like, nobody's ever going to do this, actually might cause hundreds of millions of dollars of damage ten years later. And thanks very much for liking the book.Jeremy: If people haven't read that book, I don't know, when did that come out? Maybe 2016? 2015?Gojko: Yeah, five or six years ago, I think.Jeremy: Yeah. It's still completely relevant now though and there's just so many great examples in there, and I don't want to spent the whole time talking about that book, but if you haven't read it, go check it out because it's these crazy things like police officers entering in no plates whenever they're giving parking tickets. And then, when somebody actually gets that, ends up with thousands of parking tickets, and it's just crazy stuff like that. Or, not using the middle initial or something like that for the name, or the birthdate or whatever it was, and people constantly getting just ... It's a fascinating book. Definitely check that out.But speaking of edge cases and just all this experience that you have just dealing with this idea of, I guess finding the problems with software. Or maybe even better, I guess a good way to put it is finding the limitations that we build into software mostly unknowingly. We do this unknowingly. And you and I were having a conversation the other day and we were talking about way, way back in the 1970s. I was born in the late '70s. I'm old but hopefully not that old. But way back then, time-sharing was a thing where we would basically have just a few large computers and we would have to borrow time against them. And there's a parallel there to what we were doing back then and I think what we're doing now with cloud computing. What are your thoughts on that?Gojko: Yeah, I think absolutely. We are I think going in a slightly cyclic way here. Maybe not cyclic, maybe spirals. We came to the same horizontal position but vertically, we're slightly better than we were. Again, I didn't start working then. I'm like you, I was born in late '70s. I wasn't there when people were doing punch cards and massive mainframes and time-sharing. My first experience came from home PC computers and later PCs. The whole serverless thing, people were disparaging about that when the marketing buzzword came around. I don't remember exactly when serverless became serverless because we were talking about microservices and Lambda was a way to run microservices and execute code on demand. And all of a sudden, I think the JAWS people realized that JAWS is a horrible marketing name, and decided to rename it to serverless. I think it most important, and it was probably 2017 or something like that. 2000 ...Jeremy: Something like that, yeah.Gojko: Something like that. And then, because it is a horrible marketing name, but it's catchy, it caught on and then people were complaining how it's not serverless, it's just somebody else's servers. And I think there's some truth to that, but actually, it's not even somebody else's servers. It really is somebody else's mainframe in a sense. You know in the '70s and early '80s, before the PC revolution, if you wanted to be a small software house or a small product operator, you probably were not running your own data center. What you would do is you would rent it based on paying for time to one of these massive, massive, massive operators. And in fact, we ended up with AWS being a massive data center. As far as you and I are concerned, it's just a blob. It's not a collection of computers, it's a data center we learn something from and Google is another one and then Microsoft is another one.And I remember reading a book about Andy Grove who was the CEO of Intel where they were thinking about the market for PC computers in the late '70s when somebody came to them with the idea that they could repurpose what became a 8080 processor. They were doing this I think for some Japanese calculator and then somebody said, "We can attach a screen to this and make this a universal computer and sell it." And they realized maybe there's a market for four or five computers in the world like that. And I think that that's ... You know, we ended up with four or five computers, it's just the definition of a computer changed.Jeremy: Right. I think that's a good point because you think about after the PC revolution, once the web started becoming really big, people started building data centers and collocation facilities like crazy. This is way before the cloud, and everybody was buying racks and Dell was getting really popular because people buying servers from Dell, and installing these in their data centers and doing this. And it just became this massive, whole industry built around doing that. And then you have these few companies that say, "Well, what if we just handled all that stuff for you? Rather than just racking stuff for you," but started just managing the software, and started managing the networking, and the backups, and all this stuff for you? And that's where the cloud was born.But I think you make a really good point where the cloud, whatever it is, Amazon or Google or whatever, you might as well just assume that that's just one big piece of processing that you're renting and you're renting some piece of that. And maybe we have. Maybe we've moved back to this idea where ... Even though everybody's got a massive computer in their pocket now, tons of compute power, in terms of the real business work that's being done, and the real global value, and the things that are powering global commerce and everything else like that, those are starting to move back to run in four, five, massive computers.Gojko: Again, there's a cyclic nature to all of this. I remember reading about the advent of power networks. Because before people had electric power, there were physical machines and movement through physical power, and there were water-powered plants and things like that. And these whole systems of shafts and belts and things like that powering factories. And you had this one kind of power load in a factory that was somewhere in the middle, and then from there, you actually have physical belts, rotating cogs in other buildings, and that was rotating some shafts that were rotating other cogs, and things like that.First of all, when people were able to package up electricity into something that's distributable, and they were running their own small electricity generators next to these big massive machines that were affecting early factories. And one of the first effects of that was they could reuse 30% of their factories better because it was up to 30% of the workspace in the factory that was taken up by all the belts and shafts. And all that movement was producing a lot of air movement and a lot of dust and people were getting sick. But now, you just plug a cable and you no longer have all this bad air and you don't have employees going sick and things like that. Things started changing quite a lot and then all of a sudden, you had this completely new revolution where you no longer had to operate your own electric generator. You could just plug in and get power from the network.And I think part of that is again, cyclic, what's happening in our industry now, where, as you said, we were getting machines. I used to make money as a Linux admin a long time ago and I could set up my own servers and things like that. I had a company in 2007 where we were operating our own gaming system, and we actually had physical servers in a physical server room with all the LEDs and lights, and bleeps, and things like that. Around that time, AWS really made it easy to get virtual machines on EC2 and I realized how stupid the whole, let's manage everything ourself is. But, we are getting to the point where people had to run their own generators, and now you can actually just plug into the electricity network. And of course, there is some standardization. Maybe U.S. still has 110 volts and Europe has 220, and we never really get global standardization there.But I assume before that, every factory could run their own voltage they wanted. It was difficult to manufacture for these things but now you have standardization, it's easier for everybody to plug into the ecosystem and then the whole ecosystem emerged. And I think that's partially what's happening now where things like S3 is an API or Lambda is an API. It's basically the electric socket in your wall.Jeremy: Right, and that's that whole Wardley maps idea, they become utilities. And that's the thing where if you look at that from an enterprise standpoint or from a small business standpoint if you're a startup right now and you are ordering servers to put into a data center somewhere unless you're doing something that's specifically for servers, that's just crazy. Use the cloud.Gojko: This product I mentioned that we built for mind mapping, there's only two of us in the whole company. We do everything from presales, to development testing supports, to everything. And we're competing with companies that have several orders of magnitude more employees, and we can actually compete and win because we can benefit from this ecosystem. And I think this is totally wonderful and amazing and for anybody thinking about starting a product, it's easier to start a product now than ever. And, another thing that's totally I think crazy about this whole serverless thing is how in effect we got a bookstore to offer that first.You mentioned the world utility. I remember I was the editor of a magazine in 2001 in Serbia, and we had licensing with IDG to translate some of their content. And I remember working on this kind of piece from I think PC World in the U.S. where they were interviewing Hewlett Packard people about utility computing. And people from Hewlett Packard back then were predicting that in a few years' time, companies would not operate their own stuff, they would use utility and things like that. And it's totally amazing that in order to reach us over there, that had to be something that was already evaluated and tested, and there was probably a prototype and things like that. And you had all these giants. Hewlett Packard in 2001 was an IT giant. Amazon was just up-and-coming then and they were a bookstore then. They were not even anything more than a bookstore. And you had, what? A decade later, the tables completely turned where HP's ... I don't know ...Jeremy: I think they bought Compaq at some point too.Gojko: You had all these giants, IBM completely missed it. IBM totally missed ...Jeremy: It really did.Gojko: ... the whole mobile and web and everything revolution. Oracle completely missed it. They're trying to catch up now but fat chance. Really, we are down to just a couple of massive clouds, or whatever that means, that we interact with as we're interacting with electricity sockets now.Jeremy: And going back to that utility comparison, or, not really a comparison. It is a utility now. Compute is offered as a utility. Yes, you can buy and generate compute yourself and you can still do that. And I know a lot of enterprises still will. I think cloud is like 4% of the total IT market or something. It's a fraction of it right now. But just from that utility aspect of it, from your experience, you mentioned you had two people and you built, is it MindMup.com?Gojko: MindMup, yeah.Jeremy: You built that with just two people and you've got tons of people using it. But just from your experience, especially coming from the world of being a Linux administrator, which again, I didn't administer ... Well, I guess I was. I did a lot of work in data centers in my younger days. But, coming from that idea and seeing how companies were building in the past and how companies are still building now, because not every company is still using the cloud, far from it. But not taking advantage of that utility, what are those major disadvantages? How badly do you think that's going to slow companies down that are trying to innovate?Gojko: I can give you a story about MindMup. You mentioned MindMup. When was it? 2018, there was the Intel processor vulnerabilities that were discovered.Jeremy: Right, yes.Gojko: I'm not entirely sure what the year was. A few years ago anyway. We got a email from a concerned university admin when the second one was discovered. The first one made all the news and a month later a second one was discovered. Now everybody knew that, they were in panic and things like that. After the second one was discovered, we got a email from a university admin. And universities are big users, they need to protect the data and things like that. And he was insisting that we tell him what our plan was for mitigating this thing because he knows we're on the cloud.I'm working on European time. The customer was in the U.S., probably somewhere U.S. Pacific because it arrived in the middle of the night. I woke up, I'm still trying to get my head around and drinking coffee and there's this whole sausage CV number that he sent me. I have no idea what it's about. I took that, pasted it into Google to figure out what's going on. The first result I got from Google was that AWS Lambda was already patched. Copy, paste, my day's done. And I assume lots and lots of other people were having a totally different conversation with their IT department that day. And that's why I said I think for products like the one I'm building with video and for the MindMup, being able to rent operations as a utility, but really totally rent ops as a utility, not have to worry about anything below my unique business level is really, really important.And yes, we can hire people to work on that it could even end up being slightly cheaper technically but in terms of my time and where my focus goes and my interruptions, I think deploying on a utility platform, whatever that utility platform is, as long as it's reliable, lets me focus on adding value where I can actually add value. That makes my product unique rather than the generic stuff.Jeremy: You mentioned the video product that you're working on too, and something that is really interesting I think too about taking advantage of the cloud is the scalability aspect of it. I remember, it was maybe 2002, maybe 2003, I was running my own little consulting company at the time, and my local high school always has a rivalry football game every Thanksgiving. And I thought it'd be really interesting if I was to stream the audio from the local AM radio station. I set up a server in my office with ReelCast Streaming or something running or whatever it was. And I remember thinking as long as we don't go over 140 subscribers, we'll be okay. Anything over that, it'll probably crash or the bandwidth won't be enough or whatever.Gojko: And that's just one of those things now, if you're doing any type of massive processing or you need bandwidth, bandwidth alone ... I remember T1 lines being great and then all of a sudden it was like, well, now you need a T3 line or something crazy in order to get the bandwidth that you need. Just from that aspect of it, the ability to scale quickly, that just seems like such a huge blocker for companies that need to order provision servers, maybe get a utility company to come in and install more bandwidth for them, and things like that. That's just stuff that's so far out of scope for building a business to me. At least building a software business or building any business. It's crazy.When I was doing consulting, I did a bit of work for what used to be one of the largest telecom companies in the world.Jeremy: Used to be.Gojko: I don't want to name names on a public chat. Somewhere around 2006, '07 let's say, we did a software project where they just needed to deploy it internally. And it took them seven months to provision a bunch of virtual machines to deploy it internally. Seven months.Jeremy: Wow.Gojko: Because of all the red tape and all the bureaucracy and all the wait for capacity and things like that. That's around the time where Amazon when EC2 became commercially available. I remember working with another client and they were waiting for some servers to arrive so they can install more capacity. And I remember just turning on the Amazon console. I didn't have anything useful to running it then but just being able to start up a virtual machine in about, I think it was less than half an hour, but that was totally fascinating back then. Here's a new Linux machine and in less than half an hour, you can use it. And it was totally crazy. Now we're getting to the point where Lambda will start up in less than 10 milliseconds or something like that. Waiting for that kind of capacity is just insane.With the video thing I'm building, because of Corona and all of this remote teaching stuff, for some reason, we ended up getting lots of teachers using the product. It was one of these half-baked experiments because I didn't have time to build the full user interface for everything, and I realized that lots of people are using PowerPoint to prepare that kind of video. I thought well, how about if I shorten that loop, so just take your PowerPoint and convert it into video. Just type up what you want in the speaker notes, and we'll use these neurometrics to generate audio and things like that. Teachers like it for one reason or the other.We had this influential blogger from Russia explain it on his video blog and then it got picked up, my best guess from what I could see from Google Translate, some virtual meeting of teachers of Russia where they recommended people to try it out. I woke up the next day, the metrics went totally crazy because a significant portion of teachers in Russia tried my tool overnight in a short space of time. Something like that, I couldn't predict it. It's lovely but as you said, as long as we don't go over a hundred subscribers, we're fine. If I was in a situation like that, the thing would completely crash because it's unexpected. We'd have a thing that's amazingly good for marketing that would be amazingly bad for business because it would crash all our capacity we had. Or we had to prepare for a lot more capacity than we needed, but because this is all running on Lambda, Fargate, and other auto-scaling things, it's just fine. No sweat at all. It was a lovely thing to see actually.Jeremy: You actually have two problems there. If you're not running in the cloud or not running on-demand compute, is the fact that one, you would've potentially failed, things would've fallen over and you would've lost all those potential customers, and you wouldn't have been able to grow.Gojko: Plus you've lost paying customers who are using your systems, who've paid you.Jeremy: Right, that's the other thing too. But, on the other side of that problem would be you can't necessarily anticipate some of those things. What do you do? Over-provision and just hope that maybe someday you'll get whatever? That's the crazy thing where the elasticity piece of the cloud to me, is such a no-brainer. Because I know people always talk about, well, if you have predictable workloads. Well yeah, I know we have predictable workloads for some things, but if you're a startup or you're a business that has like ... Maybe you'd pick up some press. I worked for a company that we picked up some press. We had 10,000 signups in a matter of like 30 seconds and it completely killed our backend, my SQL database. Those are hard to prepare for if you're hosting your own equipment.Gojko: Absolutely, not even if you're hosting your own.Jeremy: Also true, right.Gojko: Before moving to Lambda, the app was deployed to Heroku. That was basically, you need to predict how many virtual machines you need. Yes, it's in the cloud, but if you're running on EC2 and you have your 10, 50, 100 virtual machines, whatever running there, and all of a sudden you get a lot more traffic, will it scale or will it not scale? Have you designed it to scale like that? And one of the best things that I think Lambda brought as a constraint was forcing people to design this stuff in a way that scales.Jeremy: Yes.Gojko: I can deploy stuff in the cloud and make it all distributed monolith, so it doesn't really scale well, but with Lambda because it was so constrained when it launched, and this is one thing you mentioned, partially we're losing those constraints now, but it was so constrained when it launched, it was really forcing people to design things that were easy to scale. We had total isolation, there was no way of sharing things, there was no session stickiness and things like that. And then you have to come up with actually good ways of resolving that.I think one of the most challenging things about serverless is that even a Hello World is a distributed transaction processing system, and people don't get that. They think about, well, I had this DigitalOcean five-dollar-a-month server and it was running my, you know, Rails up correctly. I'm just going to use the same ideas to redesign it in Lambda. Yes, you can, but then you're not going to really get the benefits of all of this other stuff. And if you design it as a massively distributed transaction processing system from the start, then yes, it scales like crazy. And it scales up and down and it's lovely, but as Lambda's maturing, I have this slide deck that I've been using since 2016 to talk about Lambda at conferences. And every time I need to do another talk, I pull it out and adjust it a bit. And I have this whole Git history of it because I do markdown to slides and I keep the markdown in Git so I can go back. There's this slide about limitations where originally it's only ... I don't remember what was the time limitation, but something very short.Jeremy: Five minutes originally.Gojko: Yeah, something like that and then it was no PCI compliance and the retries are difficult, and all of this stuff basically became sold. And one of the last things that was there, there was don't even try to put it in a VPC, definitely, you can but it's going to take 10 minutes to start. Now that's reasonably okay as well. One thing that I remember as a really important design constraint was effectively it was a share nothing platform because you could not share data between two Lambdas running at the same time very easily in the same VM. Now that we can connect Lambdas to EFS, you effectively can do that as well. You can have two Lambdas, one writing into an EFS, the other reading the same EFS at the same time. No problem at all. You can pump it into a file and the other thing can just stay in a file and get the data out.As the platform is maturing, I think we're losing some of these design constraints, and sometimes constraints breed creativity. And yes, you still of course can design the system to be good, but it's going to be interesting to see. And this 15-minute limit that we have in Lamdba now is just an artificial number that somebody thought.Jeremy: Yeah, it's arbitrary.Gojko: And at some point when somebody who is important enough asks AWS to give them half-hour Lamdbas, they will get that. Or 24-hour Lambdas. It's going to be interesting to see if Lambda ends up as just another way of running EC2 and starting EC2 that's simpler because you don't have to manage the operating system. And I think the big difference we'll get between EC2 and Lambda is what percentage of ops your developers are responsible for, and what percentage of ops Amazon's developers are responsible for.Because if you look at all these different offerings that Amazon has like Lightsail and EC2 and Fargate and AWS Batch and CodeDeploy, and I don't know how many other things you can run code on in Lambda. The big difference with Lambda is really, at least until very recently was that apart from your application, Amazon is responsible for everything. But now, we're losing design constraints, you can put a Docker container in, you can be responsible for the OS image as well, which is a bit again, interesting to look at.Jeremy: Well, I also wonder too, if you took all those event sources that you can point at Lambda and you add those to Fargate, what's the difference? It seems like they're just merging into two very similar products.Gojko: For the video build platform, the last step runs in Fargate because people are uploading things that are massive, massive, massive for video processing, and just they don't finish in 15 minutes. I have to run to Fargate, and the big difference is the container I packaged up for Fargate takes about 40 seconds to actually deploy. A new event at the moment with the stuff I've packaged in Fargate takes about 40 seconds to deploy. I can optimize that, but I can't optimize it too much. Fargate is still order of magnitude of tens of seconds to process an event. I think as Fargate gets faster and as Lambda gets more of these capabilities, it's going to be very difficult to tell them apart I think.With Fargate, you're intended to manage the container image yourself. You're responsible for patching software, you're responsible for patching OS vulnerabilities and things like that. With Lambda, Amazon, unless you use a container image, Amazon is responsible for that. They come close. When looking at this video building for the first time, I was actually comparing code. I was considering using CodeBuild for that because CodeBuild is also a way to run things on demand and containers, and you actually can get quite decent machines with CodeBuild. And it's also event-driven, and Fargate is event-driven, AWS Batch is event-driven, and all of these things are converging to each other. And really, AWS is famous for having 10 products that do the same thing effectively and you can't tell them apart, and maybe that's where we'll end.Jeremy: And I'm wondering too, the thing that was great about Lambda, at least for me like you said, the shared nothing architecture where it was like, you almost didn't have to rely on anything other than the event that came in, and the processing of that Lambda function. And if you designed your systems well, you may have some bottleneck up front, but especially if you used distributed transactions and you used async invocations of downstream functions, where you could basically take some data that you needed to pass into it, and then you wouldn't necessarily need that to communicate with anything other than itself to process that data. The scale there was massive. You could just keep scaling and scaling and scaling. As you add things like EFS and that adds constraints in terms of the number of transactions and connections that, that can make and all those sort of things. Do these things, do they become less reliable? By allowing it to do more, are we building systems that are less reliable because we're not using some of those tried-and-true constraints that were there?Gojko: Possibly, but every time you add a new moving part, you create one more potential point of failure there. And I think for me, one of the big lessons when I was working on ... I spent a few years working on very high throughput transaction processing systems. That's why this whole thing rings a bell a lot. A lot of it really was how do you figure out what type of messages you send and where you send them. The craze of these messages and distributed transaction processing systems in early 2000s, created this whole craze of enterprise service buses later that came. We now have this... What is it called? It's not called enterprise service bus, it's called EventBridge, or something like that.Jeremy: EventBridge, yes.Gojko: That's effectively an enterprise service bus, it's just the enterprise is the Amazon cloud. The big challenge in designing things like that is decoupling. And it's realizing that when you have a complicated system like that, stuff is going to fail. And especially when we were operating around hardware, stuff is going to fail badly or occasionally, and you need to not bring the whole house down where some storage starts working a bit slower. You create circuit breakers, you create layers and layers of stuff that disconnect things. I remember when we were looking originally at Lambdas and trying to get the head around that and experimenting, should one Lambda call another? Or should one Lambda not call another? And things like that.I realized, let's say for now, until we realize we want to do something else, a Lambda should only ever talk to SNS and nothing else. Or SQS or something like that. When one Lambda completes, it's going to track a message somewhere and we need to design these messages to be good so that we can decouple different parts of the process. And so far, that helps too as a constraint. I think very, very few times we have one Lambda calling another. Mostly when we actually need a synchronized response back, and for security reasons, we wanted to isolate something to a single Lambda, but that's effectively just a black box security isolation. Since creating these isolation layers through messages, through queues, through topics, becomes a fundamental part of designing these systems.I remember speaking at the conference to somebody. I forgot the name of the person who was talking about airline. And he was presenting after me and he said, "Look, I can relate to a lot of what you said." And in the airline community basically they often talk about, apparently, I'm not an airline programmer, he told me that in the airline community, talk about designing the protocol being the biggest challenge. Once you design the protocol between your components, the message is who sends what where, you can recover from almost any other design flaw because it's decoupled so if you've made a mess in one Lambda, you can redesign that Lambda, throw it away, rewrite it, decouple things a different way. If the global protocol is good, you get all the flexibility. If you mess up the protocol for communication, then nothing's going to save you at the end.Now we have EFS and Lambda can talk to an EFS. Should this Lambda talk directly to an EFS or should this Lambda just send some messages to a topic, and then some other Lambdas that are maybe reserved, maybe more constrained talk to EFS? And again, the platform's evolved quite a lot over the last few years. One thing that is particularly useful in that regard is the SQS FIFO queues that came out last year I think. With Corona ...Jeremy: Yeah, whenever it was.Gojko: Yeah, I don't remember if it was last year or two years ago. But one of the things it allows us to do is really run lots and lots of Lambdas in parallel where you can guarantee that no two Lambdas access the same kind of business entity that you have in the same type. For example, for this mind mapping thing, we have lots and lots of people modifying lots and lots of files in parallel, but we need to aggregate a single map. If we have 50 people over here working with a single map and 60 people on a map working a different map, aggregation can run in parallel but I never ever, ever want two people modifying the same map their aggregation to run in parallel.And for Lambda, that was a massive challenge. You had to put Kinesis between Lambda and other Lambdas and things like that. Kinesis' provision capacity, it costs a lot, it doesn't auto-scale. But now with SQS FIFO queues, you can just send a message and you can say the kind of FIFO ID is this map ID that we have. Which means that SQS can run thousands of Lambdas in parallel but they'll never run more than one Lambda for the same map idea at the same time. Designing your protocols like that becomes how you decouple one end of your app that's massively scalable and massively parallel, and another end of your app that we have some reserved capacity or limits.Like for this kind of video thing, the original idea of that was letting me build marketing videos easier and I can't get rid of this accent. Unfortunately, everything I do sounds like I'm threatening someone to blackmail them. I'm like a cheap Bond villain, and that's not good, but I can't do anything else. I can pay other people to do it for me and we used to do that, but then that becomes a big problem when you want to modify tiny things. We paid this lady to professionally record audio for a marketing video that we needed and then six months later, we wanted to change one screen and now the narration is incorrect. And we paid the same woman again. Same equipment, same person, but the sound is totally different because two different equipment.Jeremy: Totally different, right.Gojko: You can't just stitch it up. Then you end up like, okay, do we go and pay for the whole thing again? And I realized the neurometric text-to-speech has learned so much that it can do English better than I can. You're a native English speaker so you can probably defeat those machines, but I can't.Jeremy: I don't know if I could. They're pretty good now. It's kind of scary.Gojko: I started looking at one like why don't they just put stuff in a Markdown and use Markdown to generate videos and things like that? All of these things, you get quota limits still. I thought we were limited on Google. Google gave us something like five requests per second in parallel, and it took me a really long time to even raise these quotas and things like that. I don't want to have lots of people requesting stuff and then in parallel trashing this other thing over there. We need to create these layers of running things in a decent limit, and I think that's where I think designing the protocol for this distributed system becomes an importance.Jeremy: I want to go back because I think you bring up a really good point just about a different type of architecture, or the architectural design of decoupling systems and these event-driven things. You mentioned a Lambda function processes something and sends it to SQS or sends it to SNS to it can do a fan-out pattern or in the case of the FIFO queue, doing an ordered pattern for sequential processing, which those were all great patterns. And even things that AWS has done, such as add things like Lambda destination. Now if you run an asynchronous Lambda function, you still have to write some code or you used to have to write some code that said, "When this is finished processing, now call some other component." And there's just another opportunity for failure there. They basically said, "Well, if it succeeds, then you can actually just forward it off to one of these other services automatically and we'll handle all of the retries and all the failures and that kind of stuff."And those things have been added in to basically give you that warm and fuzzy feeling that if an event doesn't reach where it's supposed to go, that some sort of cloud trickery will kick in and make sure that gets processed. But what that is introduced I think is a cognitive overload for a lot of developers that are designing these systems because you're no longer just writing a script that does X, Y, and Z and makes a few database calls. Now you're saying, okay, I've got to write a script that can massively scale and take the transactions that I need to maybe parallelize or that I maybe need to queue or delay or throttle or whatever, and pass those down to another subsystem. And then that subsystem has to pick those up and maybe that has to parallelize those or maybe there are failure modes in there and I've got all these other things that I have to think about.Just that effect on your average developer, I think you and I think about these things. I would consider myself to be a cloud architect, if that's a thing. But essentially, do you see this being I guess a wall for a lot of developers and something that really requires quite a bit of education to ramp them up to be able to start designing these systems?Gojko: One of the topics we touched upon is the cyclic nature of things, and I think we're going back to where moving from apps working on a single machine to client server architectures was a massive brain melt for a lot of people, and three-tier architectures, which is later, we're not just client server, but three-tier architectures ended up with their own host of problems and then design problems and things like that. That's where a lot of these architectural patterns and design patterns emerged like circuit breakers and things like that. I think there's a whole body of knowledge there for people to research. It's not something that's entirely new and I think you can get started with Lambda quite easily and not necessarily make a mess, but make something that won't necessarily scale well and then start improving it later.That's why I was mentioning that earlier in the discussion where, as long as the protocol makes sense, you can salvage almost anything late. Designing that protocol is important, but then we're going to good software design. I think teaching people how to do that is something that every 10 years, we have to recycle and reinvent and figure it out because people don't like to read books from more than 10 years ago. All of this stuff like designing fault tolerance systems and fail-safe systems, and things like that. There's a ton of books about that from 20 years ago, from 10 years ago. Amazon, for people listening to you and me, they probably use Amazon more for compute than they use for getting books. But Amazon has all these books. Use it for what Amazon was originally intended for and then get some books there and read through this stuff. And I think looking at design of distributed systems and stuff like that becomes really, really critical for Lambdas.Jeremy: Yeah, definitely. All right, we've got a few minutes left and I'd love to go back to something we were talking about a little bit earlier and that was everything moving onto a few of these major cloud providers. And one of the things, you've got scale. Scale is a problem when we talked about oh, we can spin up as many VMs as we want to, and now with serverless, we have unlimited capacity really. I know we didn't say that, but I think that's the general idea. The cloud just provides this unlimited capacity.Gojko: Until something else decides it's not unlimited.Jeremy: And that's my point here where every major cloud provider that I've been involved with and I've heard the stories of, where you start to move the needle at all, there's always an SA that reaches out to you and really wants to understand what your usage is going to be, and what your patterns were going to be. And that's because they need to make sure that where you're running your applications, that they provision enough capacity because there is not enough capacity, or there's not unlimited capacity in the cloud.Gojko: It's physically limited. There's only so much buildings where you can have data centers on the surface of Earth.Jeremy: And I guess that's where my question comes in because you always hear these things about lock-in. Like, well serverless, if you use Lambda, you're going to be locked in. And again, if you're using Oracle, you're locked in. Or, you're using MySQL you're locked in. Or, you're using any of the other things, you're locked in.Gojko: You're actually not locked in physically. There's a key and a lock.Jeremy: Right, but this idea of being locked in not to a specific cloud provider, but just locked into a cloud in general and relying on the cloud to do that scaling for you, where do you think the limitations there are?Gojko: I think again, going back to cyclic, cyclic, cyclic. The PC revolution started when a lot more edge compute was needed on mainframes, and people wanted to get stuff done on their own devices. And I think probably, if we do ever see the limitations of this and it goes into a next cycle, my best guess it's going to be driven by lots of tiny devices connected to a cloud. Not necessarily computers as we know computers today. I pulled out some research preparing for this from IDC. They are predicting basically from 18.3 zettabytes of data needed for IOT in 2019, to be 73.1 zettabytes by 2025. That's like times three in a space of six years. If you went to Amazon now and told them, "You need to have three times more data space in three years," I'm not sure how they would react to that.This stuff, everything is taking more and more data, and everything is more and more connected to the cloud. The impact of something like that going down now is becoming totally crazy. There was a case in 2017 where S3 started getting a bit more latency than usual in U.S. East 1, in I think February of 2018, or something like that. There were cases where people couldn't turn the lights on in their houses because the management software was working on S3 and depending on S3. Expecting S3 to be indestructible. Last year, in November, Kinesis pretty much went offline as far as everybody else outside AWS concerend for about 15 hours I think. There were people on Twitter that they can't go back into their house because their smart lock is no longer that smart.And I think we are getting to places where there will be more need for compute on the edge. First of all, there's going to be a lot more demand for data centers and cloud power and I think that's going to keep going on for the next five, ten years. But then people will realize they've hit some limitation of that, and they're going to start moving towards the edge. And we're going from mainframe back into client server computing I think. We're getting these products now. I assume most of your listeners have seen one like all these fancy ubiquity Wi-Fi thingies that are costing hundreds of dollars and they look like pieces of furniture that's just sitting discretely on the wall. And there was a massive security breach yesterday published. Somebody took their AWS keys and took all the customer data and everything.The big advantage over all the ugly routers was that it's just like a thin piece of glass that sits on your wall, and it's amazing and it looks good, but the reason why they could do a very thin piece of glass is the minimal amount of software is running on that piece of glass, the rest is running the cloud. It's not just locking in terms of is it on Amazon or Google, it's that it's so tightly coupled with something totally outside of your home, where your network router needs Amazon to be alive now in a very specific region of Amazon where everybody's been deploying for the last 15 years, and it's running out of capacity very often. Not very often but often enough.There's some really interesting questions that I guess we'll answer in the next five, ten years. We're on the verge of IOT I think exploding because people are trying to come up with these new products that you wouldn't even think before that you'd have smart shoes and smart whatnot. Smart glasses and things like that. And when that gets into consumer technology, we're no longer going to have five or ten computer devices per person, we'll have dozens and dozens of computing. I guess think about it this way, fifteen years ago, how many computer devices were you carrying with yourself? Probably mobile phone and laptop. Probably not more. Now, in the headphones you have there that's Bose ...Jeremy: Watch.Gojko: ... you have a microprocessor in the headphones, you have your watch, you have a ton of other stuff carrying with you that's low-powered, all doing a bit of processing there. A lot of that processing is probably happening on the cloud somewhere.Jeremy: Or, it's just sending data. It's just sending, hey here's the information. And you're right. For me, I got my Apple Watch, my thermostat is connected to Wi-Fi and to the cloud, my wife just bought a humidifier for our living room that is connected to Wi-Fi and I'm assuming it's sending data to the cloud. I'm not 100% sure, but the question is, I don't know why we need to keep track of the humidity in my living room. But that's the kind of thing too where, you mentioned from a security standpoint, I have a bunch of AWS access keys on my computer that I send over the network, and I'm assuming they're secure. But if I've got another device that can access my network and somebody hacked something on the cloud side and then they can get in, it gets really dangerous.But you're right, the amount of data that we are now generating and compute that we're using in the cloud for probably some really dumb things like humidity in my living room, is that going to get to a point where... You said there's going to be a limitation like five years, ten years, whatever it is. What does the cloud do then? What does the cloud do when it can no longer keep up with the pace of these IOT devices?Gojko: Well, if history is repeating and we'll see if history is repeating, people will start getting throttled and all of a sudden, your unlimited supply of Lambdas will no longer be unlimited supply of Lambdas. It will be something that you have to reserve upfront and pay upfront, and who knows, we'll see when we get there. Or, we get things that we have with power networks like you had a Texas power cut there that was completely severe, and you get a IT cut. I don't know. We'll see. The more we go into utility, the more we'll start seeing parallels between compute and power networks. And maybe power networks are something that you can look at and later name. That's why I think the next cycle is probably going to be some equivalent of client server computing reemerging.Jeremy: Yeah. All right, well, I got one more question for you and this is just something where it may be a little bit of a tongue-in-cheek question. Because we talked it a little bit ... we talked about the merging of Lambda, and of Fargate, and some of these other things. But just from your perspective, serverless in five years from now, where do you see that going? Do you see that just becoming the main ... This idea of utility computing, on-demand computing without setting up servers and managing ops and some of these other things, do you see that as the future of serverless and it just becoming just the way we build applications? Or do you think that it's got a different path?Gojko: There was a tweet by Simon Wardley. You mentioned Simon Wardley earlier in the talk. There was a tweet a few days ago where he mentioned some data. I'm not sure where he pulled it from. This might be unverified, but generally Simon knows what he's talking about. Amazon itself is deploying roughly 50% of all new apps they're building on serverless. I think five years from now, that way of running stuff, I'm not sure if it's Lambda or some new service that Amazon starts and gives it some even more confusing name that runs in parallel to everything. But, that kind of stuff where the operator takes care of all the ops, which they really should be doing, is going to be the default way of getting utility compute out.I think a lot of these other things will probably remain useful for specialists' use cases, where you can't really deploy it in that way, or you need more stability, or it's not transient and things like that. My best guess is first of all, we'll get Lambda's that run for longer, and I assume that after we get Lambdas that run for longer, we'll probably get some ways of controlling routing to Lambdas because you already can set up pre-provisioned Lambdas and hot Lambdas and reserved capacity and things like that. When you have reserved capacity and you have longer running Lambdas, the next logical thing there is to have session stickiness, and routing, and things like that. And I think we'll get a lot of the stuff that was really complicated to do earlier, and you had to run EC2 instances or you had to run complicated networks of services, you'll be able to do in Lambda.And Lambda is, I wouldn't be surprised if they launch a totally new service with some AWS cloud socket, whatever. Something that is a implementation of the same principle, just in a different way, that becomes a default we are running computer for lots of people. And I think GPUs are still a bit limited. I don't think you can run GPU utility anywhere now, and that's limiting for a whole host of use cases. And I think again, it's not like they don't have the technology to do it, it's just they probably didn't get around to doing it yet. But I assume in five years time, you'll be able to do GPUs on-demand, and processing GPUs, and things like that. I think that the buzzword itself will lose really any special meaning and that's going to just be a way of running stuff.Jeremy: Yeah, absolutely. Totally agree. Well, listen Gojko, thank you so much for spending the time chatting with me. Always great to talk with you.Gojko: You, too.Jeremy: If people want to get in touch with you, find out more about what you're doing, how do they do that?Gojko: Well, I'm very easy to find online because there's not a lot of people called Gojko. Type Gojko into Google, you'll find me. And gojko.networks, gojko.com works, gojko.org works, and all these other things. I was lucky enough to get all those domains.Jeremy: That's G-O-J-K-O ...Gojko: Yes, G-O-J-K-O.Jeremy: ... for people who need the spelling.Gojko: Excellent. Well, thanks very much for having me, this was a blast.Jeremy: All right, yeah. And make sure you check out ... You mentioned Narakeet. It's a speech thing?Gojko: Yeah, for developers that want to build videos without hassle, and want to put videos in continuous integration, and things like that. Narakeet, that's like parakeet with an N for narration. Check that out and thanks for plugging it.Jeremy: Awesome. And then, check out MindMup as well. Awesome stuff. I've got all the stuff in the show notes. Thanks again, Gojko.Gojko: Thank you. Bye-bye.

Diese Woche ist Nicole Rauch zu Gast. Mit Event Storming kann man Domain-driven Design ganz praktisch und kollaborativ umsetzen. Und Specification by Example stellt sicher, dass man auch das richtige baut. Buch-Tipp: Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing von Gojko Adzic

In this episode, I had the pleasure to host the product builder and book author Gojko Adzic. Building Products is what we explore in this episode of Le Podcast on Emerging Leadership. In this episode, learn from Gojko: How to build the perfect product, How to avoid waste when building software, How to waste 75 Million in an agile way (does the currency matters here?), Is Impact Mapping simple or easy? How to measure anything, a book by Douglas Hubbard Four Disciplines of Execution, by Chris McChesney, Sean Covey, and Jim Huling The Art of Business Value, by Mark Schwartz How to run control experiment with Microsoft, How to collaborate to built products, Pair programming, of course! How to deal with conflicts, How to give a promotion to your number two problem :) Software and IT is evolving in an upward going spiral! Find out the transcript and much more in the companion blog post!

This week, our heroes talk with speaker, author, and software engineer Gojko Adzic about how software can go horribly wrong. When it does it can affect our lives in troubling, frustrating, and unexpected ways. The post 18. Peak Software $#!% with Gojko Adzic appeared first on Retro Time.

In this episode of Semaphore Uncut, we talk to Gojko Adzic, specialist in agile and lean quality improvement. We talk about how to make truly valuable software products: addressing real needs rather than all requests and establishing quick feedback loops by observing behavior change. Gojko also shares how he has kept his passion for software alive. We hear how he made space to learn and experiment and how he guards his autonomy.Gojko is a frequent speaker at software development conferences. He is also the author of Specification by Example and other books.Key takeaways:A developer-customer communication anti-patternSolve for needs, not featuresBehavior change: a rapid feedback loopData over opinionBooks for budding product designersKeeping the passion aliveThe joy of autonomyEven 'failed' experiments produce learningAbout Semaphore UncutIn each episode of Semaphore Uncut, we invite software industry professionals to discuss the impact they are making and what excites them about the emerging technologies.

Here is our 27th episode with host Joshua Proto and guest Gojko Adzic. Gojko is a Partner at Neuri Consulting and a premier serverless author! In this episode here about: -How Serverless can be a liberating structure -The usefulness of multi-versioning toolkits and their enterprise use cases -Exciting new projects like Video Puppet -And much more! With over an hour of content, it’s our biggest podcast yet! And if you like this episode please go to our website to hear the full catalogue where it is always free: talkingserverless.io --- Send in a voice message: https://anchor.fm/talking-serverless/message

You can find Gojko Adzic on Twitter as @gojkoadzic and his books:Impact MappingSpecification by ExampleRunning ServerlessCheck out his latest projects:MindMupVideo PuppetIn the show, we also talked about the Ports and Adapter (or Hexagonal Architectures) pattern, which you can read more about here. This topic was also explored in length during Episode 18 with Aleksandar Simovic and Slobodan Stojanovic.If you want to have an easier time debugging serverless applications, then also check out Lumigo, and you can get 15% off your monthly bill with the code "Yan15"For more stories about real-world use of serverless technologies, please follow us on Twitter as @RealWorldSls and subscribe to this podcast.Opening theme song:Cheery Monday by Kevin MacLeodLink: https://incompetech.filmmusic.io/song/3495-cheery-mondayLicense: http://creativecommons.org/licenses/by/4.0

Guest Bio: Gojko is a partner at Neuri Consulting. He is the winner of several awards, including the 2016 European Software Testing Outstanding Achievement Award and the Jolt Award for his book, Specification by Example. Gojko is also a frequent speaker at software development conferences.   Episode Description: In this episode, Phil chats with Gojko Adzic about experiencing the joy of coding and programming, but also recognizing the importance of seeing the big picture when it comes to projects. Gojka highlights this by advising people work “close to the money” to gain a better understanding of how customers use the products he makes, and how his first startup went bankrupt when he got too wrapped up in tracking technical effort instead of product value. Still, he says he can’t imagine doing anything other than working in IT.   Key Takeaways:   (1.00) Phil kicks off the interview by asking Gojko more about himself. Gojko talks about writing books, how he got his start developing software, but he always wanted to do more than just “sitting in a development box,” as he puts it. He prefers working on projects end-to-end.   (3.21) Phil follows up by asking Gojka for a unique career tip people might now know. Gojka answers with the advice: “stay as close to the money as possible.” He goes on to say that he feels like today, IT is often extremely divorced from the customers and users that they are actually making things for. It becomes hard to tell if your work is having an actual impact. Staying close to the money means making sure that the things you do serve a purpose.   (7.45) Phil moves on, asking Gojka about the worst experience of his IT career, and Gojka jokes that it’s difficult to pick the “worst.” He says the one that made him feel the worst but was the most important learning experience came when he was a CTO of a startup and that they were good at the technical side of things but had no idea how to calculate value and properly run a business and so they went bankrupt. He was way too focused on measuring effort and not value.   (13.06) Phil switches things up and asks Gojka about his greatest career success so far, and he says that he hopes he hasn’t made his greatest success yes. But he’s very proud of a project called Mind Map and that it has helped him rediscover the joy of coding.   (15.00) Phil then asks Gojka what excites him the most about the future of the IT industry, and he says software specifically is the closest thing to magic there is, and that it’s incredible that people can make something that has such a huge impact on the real world, essentially out of thin air.   (15.50) Phil starts the Reveal Round by asking Gojka what motivated him to pursue a career in IT, to which he answers that he never wanted to do anything else, quite literally from the age of six onwards.   (17.01) Next, Phil asks Gojka for the best career advice he’s ever received. Gojka says it’s probably something he read in one of The Pragmatic Programmer books, which was: “don’t say no, offer options.” Instead of saying that something isn’t possible, try to come up with options for things you CAN do instead.   (18.10) Phil then questions Gojka as to what he would do if he were to begin his IT career all over again now, and Gojka answers that he never really wanted to do anything different, but that he would try to switch jobs faster to learn as much as possible about as many different things as he could.   (19.01) On the subject of current career objectives, Gojka talks about writing a new book that’s actually about a technique that can be used to solve the problem of his worst career moment.   (20.03) Phil asks what non-tech skill Gojka has found the most useful during his career, and he responds that he doesn’t really differentiate between what’s technical and non-technical, but that the idea of selling value and not time was a non-tech thing he learned that has made a major impact on his career.   (21.31) Phil wraps things up by asking Gojka for any parting words of advice for the listeners and he advises people to not waste time working on things that they don’t really care about or find important and that they should be able to work on creating things that bring them joy.   Best Moments:   (1.15) Gojko: “I tend to write books to download the stuff in my brain so I can leave more spare capacity for new things.”   (5.48) Gojko: “My career advice for people starting here would be to figure out where the money is and stay as close as possible to that because that just cuts through the whole bullshit that most people shouldn’t really care about.”   (7.24) Phil: “I think it’s all about what the end purpose is, rather than the actual solution that gets you there.”   (12.50) Gojka: “IT’s really nice as an industry because you can make stupid mistakes and learn from them and then kind of pull yourself up.”   (14.48) Gojka: “If people feel that their work is dull they should build their own product.”   (21.56) Gojka: “You can spend a lot of time building stupid systems nobody cares about and you shouldn’t be wasting your life on that. Programming should be a joyful activity.”   Contact Gojko Adzic: Blog: www.gojko.net LinkedIn: https://www.linkedin.com/in/gojko/ Twitter: https://twitter.com/gojkoadzic @gojkoadzic Latest Book: https://www.amazon.com/Humans-Vs-Computers-Gojko- Adzic/dp/0993088147    

  Product Owners think a lot about delivering value and how best to do that. One way that can help focus those efforts is a technique from Gojko Adzic called Impact Mapping.  On this episode, Gojko joins us to talk about the basic concepts, some tricks to asking better questions while putting one together, and ways to help facilitate better collaboration. It’s a very interesting area and skill for PO’s to learn and after listening, you should be able to start creating one yourself.           Feedback: twitter - @deliveritcast email - deliveritcast@gmail.com   Links: PO Coaching and Consulting - seek taiju Gojko Adzic @gojkoadzic https://gojko.net/ Gojko Adzic - Impact Mapping with Innovation Games Gojko Adzic - Product Owner Key Skills – Impact Mapping, Story Mapping and Valuable User Stories Mark Schwartz - The Art of Business Value Ronny Kohavi - Online Experimentation at Microsoft Chris Williams - Why We Can't Stop Overcomplicating Agile  

Moving from your business strategy to product design using impact mapping to connect development roadmap to business goals. Some of the things we mention in the episode are: MindMup (https://www.mindmup.com/) - brilliant online mind mapping tool that works especially well for running impact mapping sessions Impact Mapping by Gojko Adzic (https://www.amazon.co.uk/Impact-Mapping-Software-Products-Projects/dp/0955683645/ref=sr_1_1) - short, approachable, pragmatic volume on how to get started with the technique

Jeremy Miller is the creator of Storyteller. This episode was recorded at CodeMash 2017 in a massive dining room, so the audio is a bit different than normal. Show Notes: Check out Storyteller Book: Specification by Example by Gojko Adzic Jeremy Miller is on Twitter Want to be on the next episode? You can! All you need is the willingness to talk about something technical. Theme music is "Crosscutting Concerns" by The Dirty Truckers, check out their music on Amazon or iTunes.

Guest: Gojko Adzic @gojkoadzic Full show notes are at https://developeronfire.com/podcast/episode-019-gojko-adzic-software-as-magic-and-impact-mapping-to-avoid-the-underpants-gnomes

Молодой тестировщик Александр Лысенко (Харьков) - засыпал в прямом эфире экспертов вопросами. В программе, которую вел программист, создатель UI-testing framework Selenide Андрей Солнцев (@asolntsev, Эстония) принимали участие гости-эксперты Алексей Петров (директор по качеству Mail.ru, Москва), Алексей Виноградов (@vinogradoff, Германия) и Станислав Катков (Таиланд) В выпуске: приветствие и представление экспертов Основное блюдо - вопросы "подрастающего" тестировщика В каком порядке применять техники тест-дизайна? Должны ли техники, проверяющие основное поведение бизнес-модели, следовать первыми? проблема декомпозиции требований: как правильно декомпозировать очень сложные переплетённые функциональности? как тестировать хранение данных и целостность этих данных? регрессионное тестирование: как из всех тестов отобрать тест для регрессионного набора? как часть нужно добавлять новые тесты в существующий регрессионный набор и какие выбирать тесты? отчёт о выполнении регрессионного тестирования: что необходимо отобразить? применение priority и severity (доклад с SQA Days 17) Рубрика "Новости" закон о забвении, подробности German Testing Day 2015, Франкфурт; ReTest.de - генерация автоматизированных UI-тестов (на немецком) Рубрика "Плачь, Ярославна!" Утилиты для управления двумя PC с одной Keyboard и Mouse, вторая утилита Jing падает при заливке файла на сервер после обновления до Windows 8. Лучше использовать Skitch. Evernote обновил интерфейс, стало больше движений. Рубрика "Последний писк" русскоязычные сессии Weekend Testing с Романом Шейко в скайпе. сервис Gravatar для аватарок книга "50 quick ideas to improve your tests" от Gojko Adzic. Пример: "Даже не пытайтесь заменить ручные тесты автотестами" обзор пользовательских интерфейсов российских интернет-банков от Алексея Скобелева из Markswebb простая багтрекинговая система LeanTesting

In this episode, Gojko Adzic speaks with us about how to deliver solutions that the business truly needs to achieve their goals and avoid creating shelfware.  He’ll also introduce us to a tool that he uses called Impact Mapping.   After listening to this episode, you will understand: How to focus on creating an impact for your […] The post MBA025: Don’t Just Make Software, Make an Impact – Interview with Gojko Adzic appeared first on Mastering Business Analysis.

Gojko Adzic “does computers” which means he helps people deliver software and he caught up with Craig on a recent YOW! DepthFirst tour of Australia. Gojko is the author of numerous books including “Bridging The Communication Gap“, “Specification by Example“, “Impact Mapping” and “50 Quick Ideas to Improve Your User Stories“. XP – started with “Extreme Programming … Continue reading →

This month we bring you an interview with Gojko Adzic. Gojko is a frequent speaker at leading software development and testing conferences and runs the UK agile testing user group. Over the last eleven years, he has worked as a developer, architect, technical director and consultant on projects delivering equity and energy trading, mobile positioning, e-commerce, online gaming and complex configuration management. He is the author of several books and articles. In 2012 his book Specification by Example received the Jolt award. To celebrate the Jolt Award, the publisher of Spec by Example is offering our podcast listeners a 37% discount on Specification by Example. Note that Goiko has recently published a new book Impact Mapping: Making a big impact with software products and projects, which we did not get around to discussing in this interview. Follow Goiko on twitter via @goikoadzic or on his site on http://gojko.net/ This interview was recorded on the 8th of oct 2012 at the Holiday Inn Express in Amsterdam. Interview by @freekl and @felienneAudio post-production by @mendelt Links for this podcast: Book:Specification by Example, Gojko Adzic, 2011. Book:Bridging the Communication Gap ('The Blue book'), Gojko Adzic, 2009 Article: Redefining software quality, Gojko Adzic, 2012 Book: Made to Stick, Chip and Dan Heath, 2007

This week Scott learns about Executable Specifications with Gojko Adzic, Jonas Bandi and Aslak Hellesoy. What's all this talk about BDD, Cucumber, Gerkin and SpecFlow? Where's the best place to start and how to Acceptance Tests fit into my existing projects?