More Features Will Kill Your Product with Maarten Dalmijn

Hi everyone. My name is Patrick Akio and I just want to say more features will kill your product. That is exactly the topic of today's episode and joining me is Marta Domain. What a blast of a conversation we had. We go into the details of why that is. How do you balance features versus improving what you have, software development as well as the product view over that and much, much more. Enjoy. Well, you told me before the

show you do a lot of reading and not necessarily podcasting. Have you thought about writing stuff as well? Yeah, I mean, I've. I've written a book, right? So I mean, I write regularly, but yeah, but writing like a novel or something, maybe one day. But it's a different ball game. Yeah. So here's my I love movies. So I've got a dream to one day write a movie script. Oh, wow. It's a dream, right? I mean, I want stress. It's totally like something I cannot achieve.

But. I think you can, why not? Yeah, doesn't seem that that far away. Yeah, well I mean who knows, like, but that's a dream. And I think the best way to achieve that is to write a novel at the moment. And yeah, so I'm, I'm reading a lot of books about screen writing, about writing. And yeah, at some point I'll start writing about like, like, yeah, but this is a 10 year project.

Like, yeah, yeah, I don't think I've never written a story or a short story, so. We do a lot of things that we've never done. But that's what I'm saying. This is kind of. So how can I say I could write another book in the realm of product management, Agile. I don't know if it would be interesting, but I'm confident I could pull it off right? But this something I'm like. I have no clue if I'm able to do it. Maybe I'm not capable of doing it. So that's what intrigued me. Interesting.

It's it's funny that you say this piece, this domain is like comfort. Like I'm confident I can do that because you've done it before because you have the experience to do that and then when it comes to kind of out of comfort probably where you'll learn the most because you've never done that, that's kind of scary and you're like that might be a 10 year project. Yeah, yeah, yeah. I mean, that's what I'm thinking. Did we start already or like what's?

The I mean, everything's recording, so everything's running. I think it's fun. So it might make it in, Yeah. Why are you asking specifically? I just curious, but yeah, how much attention do I have to pay to what I'm saying, right? If if every if you say something we really can't put in, we we might edit it.

I can count on one hand actually the amount of times we edited and it was because someone I asked the question and someone said I can tell you this, but it cannot make it in the episode completely took me out of it. Basically, I never had anything edited so. That's good. So I look forward to that movie script once you. We have to dream, right? It's dream.

Yeah, but one of the one of the main reasons and one of the topics I wanted to talk about was mainly how do you say that building complex software or what? What makes it complex in the 1st place? And then the most complex part, which I think is kind of features and how to balance the amount of features that need to be in there. What is kind of your experience when it comes to kind of the products you've built? Can you give us a a brief overview of what you've built

with a team? Yeah. So I need to think a little bit, right. So my journey you said has been like I've been AQA, I've been a business analyst, I've been a product owner, I've been a head of products. So I've been involved in products in various roles. So I'm just going to tell you all the products. I also was a marketing manager, so I've worked on a healthcare product actually where I was the marketing manager, but I also did, it's a start up, right.

So I also did some testing and yeah, I was also talking to users doing UX testing. So that is one of the first products I worked on. We also rebuilt it and we made, we made many mistakes there but it's not a lot of story after that I build, I worked on on software for all rigs. So that's something completely different.

So basically crisis 2008 eight. I was a marketing manager and nobody would hire me because they were looking at my resume like resume and I didn't have a marketing background. I studied like functional genomics. So I literally was sending interviews and I have like a, a engineering title, you know, they're just a little bit asked me why should we hire an engineer. That was kind of why you. And that was literally how the interview started. And I was not good enough to

handle those. So I was never hired. And then I decided, OK, I'm going to become AQA because I I did that before. I was good at it and I thought it's scarce like, so it's going to be way easier to get in. And I had a job within a week and there I works on Ulrich Software. So basically, I can go in a lot of details on this. But what's interesting is so O Ricks, they're very often mobile. So depending on where they are, they need different certifications to be able to drill for oil.

Yeah. So they need software to track to keep track of that because let's say you're in one kind of water and you need another certification. And some of them they can actually, how do you say they're valid in multiple waters? So you and you have different crews. So you need to keep track because the moment somebody checks and you're not compliant, you're literally using like millions, like every moment that they stopped drilling. So, yeah, so Ulrich software.

So after that, I worked at Binder, Damn Digital Ass management software, which is SAS. It's basically storing all the images for your brand. I've worked in e-commerce, so rebuilding a whole e-commerce platform. Yeah. I also worked another company in e-commerce and let me see, last company I worked was a head of Product SAS project management software. So e-commerce and a lot of SAS in different domains. Interesting.

I I usually look at product owners and I had a person on the show who does a lot of writing as well. He has his own sub stack Bondon. You know him? Yeah. Yeah. He's, he's very popular in the product management community, right? Absolutely. Yeah. I read his work. As a as a product manager, as a product lead, he is always kind

of in the payments domain. He was like something about that domain just interested him so much that he's like wherever I move across organizations, I will always kind of, yeah, get drawn to kind of the payments section and that. And I'm more like you. I think right now where I don't really mind the domain, I think everything is kind of interesting. I haven't really found something that I'm like, OK, I want to do this maybe across organizations

or across projects. And I think that's an interesting kind of contrast where on the one hand you have a group of people that like really go from the kind of the same domain, from organization to organization, even region and country, because he worked in Singapore now in different regions as well. And then people on the other flip side that are like, OK, give me any domain, I'll try and be an expert or I'll, I'll make myself familiar with that.

That kind of maybe is scary, but it's also a challenge in that way that kind of drives them. Yeah, yeah. I also think that I've worked in payments, of course not the level done on has worked. But yeah, I can tell you that one one of the key things there, I suspect at least there's a lot of legislation, a lot of rules, a lot of details you need to, you really need to know how stuff works with credit cards,

debit cards, pay later. So there's a lot of expertise to be acquired and then once you have it, it's super valuable. So I also think that that probably plays a role like if you're really an expert in the payments domain, you just, I mean that knowledge has been acquired over many years and you can say goodbye to it, but it's also what makes you very valuable. I think probably could be also one of the reasons. Yeah, that's I. In that conversation with him, that's also what I told them.

I was like you must be incredibly valuable, especially from the different perspectives across region as well you see problems that have been solved in other areas. Yes, correct. That's what I would suspect, right. But he's not there. He's. Not here, yeah, but I think it's really fun to to learn that you actually went a lot across domains. Would you say one of the domains was like most fun? Or.

Yeah. I mean, I think what's interesting is learning about domains. For example, I also was Product Owner for finance, I was for logistics. So I've also seen those aspects and what I think what often is missing is in companies is this end to end understanding. And now I'm not claiming that I had the full picture, but I found it very fascinating that you're literally rebuilding a product and you're sending all

of this information over. For example, you send an XML file, a certain code that determines how it's packed. Nobody in the company knew how it worked. So you'll Italy be kind of reverse engineering kind of what someone had thought out to make sure OK, it's working, expect as expected. And I think there's tremendous value in having this end to end understanding. And I think maybe you can also relate. I think one of the big challenges, writing code is

easier than reading code. Documentation is never up to date. So very often there are just people that understand pieces of the puzzle, but there's nobody that understands the whole thing and that's a big challenge, especially when rebuilding stuff.

Yeah, yeah, absolutely. It's funny because I I look at this kind of from a software engineering perspective and I've always worked with product managers and maybe I expected too much of them, but I expected them to kind of kind of get an understanding of that end to end process, kind of be the the domain expert within the team. And I I always wanted to also know the domain, 'cause I felt that made me a better engineer.

And now I've kind of switched roles and recently I'm now in the ESG domain, product manager there. And now I I feel this dread because of my expectations looking at product people. Now I have engineers looking at me and funny enough I realized that okay, I I do not have all

the answers. Probably the people in my past did not have all the answers and that's still okay and I have to kind of figure out this confidence and this, yeah, I think drive to figure things out and be OK with kind of the unknown and the ambiguity. Yeah. So you're touching up a super important point in my opinion. So I mean, I'm going to say it very black and white.

But what I've tended to see is the developers always say just give me the perfect requirements and then I'll know exactly how to build it. And and I think the big problem is it's complex, it's you're building a system like nobody. Like it's often nobody really. And especially because the complex piece you're adding has to work in an existing piece, like nobody knows exactly how it's completely going to work in

all detail. And even when you do, then you build it, you discover you missed something or the customer actually wants something else. So I think that's one of the biggest challenges that that like I wish more developers instead of thinking like, hey give me the perfect requirements, they would think, OK, so this is the problem we're trying to solve. How do we figure out how to best solve it? And there is some uncertainty and emergence to be expected. And I I think that comes with

experience. I think I I think, yeah. That's that's what I've seen. Like I I have seen that description what you mentioned, they give me that, give me the requirements and I'll figure it out or I'll get it to you done real fast basically and then still pieces are missing there. And then on the flip side, that's also where I am something about kind of understanding just drives me that I cannot build something. It's really hard for me to do

that. I think maybe principally if I do not understand why I'm doing this and I can do it and I can do it again, but at some point I'm going to be like, no, no, I cannot do this anymore. Like that's it. Basically I have no clue what I'm doing. I'm not I I need to know if I'm doing the right thing. I think that drive also moved me to product because then I can kind of take responsibility in answering those questions for myself and with that responsibility also for others.

But that's also from the engineering side. What kind of drove most of the conversations? And maybe maybe this is controversial, but as an

engineer I would much rather not build anything then build the wrong thing basically. And I would re fight to not build things. And from some perspectives that might look like I'm lazy, but from other perspectives I want to build the right thing basically. I completely agree with you. I've worked at start-ups where actually they build a lot of the wrong things. So just imagine that you had a screen with all these feature

toggles, like 100 of them. And for example, there was two different toggles for watermark and if you were turned both of them on, you were screwed. It wasn't supposed to work together, but you had to know that, right? So just imagine all the combinations that were possible with this 200 checkbox in the settings, and yeah, that means

you get a Frankenstein product. You have a huge code base, like whenever you introduce a new feature, you need to think about, OK, is this going to break any of the other stuff? Like, I think the hardest thing is to keep things simple, but if you don't, then you end up with this complex Frankenstein code

base we're adding. Anything becomes very difficult and and as well all of those features, you're going to get support issues, right and and somebody's going to say this doesn't work, this doesn't work, you need to fix it. So yeah, I just kind of see it as like a quicksand, you know, like you're kind of sucked in and everything becomes more difficult. Yeah, Yeah, it's I, I first of all agree with that, but I am going to play devil's advocate

kind of from a business side. Software is never done right and we're paying let's say teams of engineering. I think a lot of tech teams now are internal in a company. It's becoming part of a core domain of organizations even. And let's say we say from a product side that OK, this is finished and we really have to test things out and optimize things, the things that we have rather than building new things.

Then for the business side, people might say, well, our competitors are building new things that have functionality, XY and ZED. Every other week we should also do something similar, and that really drives then this force of building new features and building new stuff rather than optimizing what we have. Yeah. I mean, I think it's about trade-offs. How do you make the right trade off?

And I think one of the challenges is, so if you don't know what you can remove from your products, that says something about how much, you know how your product delivers value, how much. And I think it's very important that you remove stuff because the assumption that everything you build is a home run and people are really using it.

I mean you know, I I actually think most features are not that used that much and I think that should be driving the conversation like actually removing this stuff is going to free up time to market for new features. So you need exploration, you need to discover stuff, but you also need to balance that. What you have is not an anchor that drags you down. And and I think a lot of companies just add, add, add, and you have a huge anchor.

And then at some point somebody says we've got technical depth, we've got a legacy monster, we need to rebuild and then you're screwed. Yeah. Yeah, yeah. And somehow that's like a circle that I've seen in many organizations. Yeah, yeah, absolutely. Why do you think that happens? I have my hypothesis. Yeah, I I think it is because of that drive of features, right. At some point you build on top.

And I mean, let's say you start with a solid base, because sometimes that's not even true, but at at some. Point let's. Let's think about Jenga. Because you build up this tower and at some point it tumbles, right? And in software it might not tumble, but you might start building slower. And the higher this thing goes, the more complex it needs to be. Especially when you need to change and flip kind of the blocks that are underneath, it might actually tumble.

And when it tumbles then you have an an issue on production. Basically, I don't think you can build and build and build without something breaking. And I do think you need that time to kind of revise and see what is needed and also slice out the work that is not needed anymore. Slice out the features that are never being used to keep things simple and comprehensible. And I yeah, and I think so.

Personally, I think one of the reasons why we suck at it is because actually they did some experiments where they actually gave people a puzzle and it could be solved in two ways, by adding a puzzle piece and by removing a puzzle piece. So most people only had the option like saw the option of adding the puzzle piece. Very few people actually thought, oh, if I removed this then the puzzle will be solved.

And I think that also has to do with loss aversion, like whether the Daniel Kahneman won won a Nobel Prize for that, like prospect theory and loss aversion. So yeah, we hate losing stuff. Like when they introduced the new cola, right? They introduced the new cola. It actually objectively tasted better than the old cola.

They only didn't take one thing into account and that is that's the people were losing the old cola and then suddenly everybody hated the new cola and it was a total fiasco that Coca-Cola lost millions. True story. So we just hate losing resumes, right? Most resumes suck. Why is that? Everybody wants to add everything they've done. We really suck at the determining like what should be in there, what not, what's necessary, what not. It's incredibly difficult because you need to remove

things. Yeah. And I think we we're just not that good at it. And and that's a very important skill. I think we have to develop more. Yeah, yeah. I think it's funny to think about that and that innately humans are just not good at that. So then can we leverage technologies to make more objectified decisions you think is that going to be kind of the

future of decision making? Because it's also it's really hard to do make the decision of what needs to be there and what can go. Yeah, so so actually I read this article recently, I don't know if you've seen it as well, where they looked at code bases, where code was generated by AI and actually they the conclusion was lot of duplicated code, lot of like it made more stuff more complex.

I don't know if you saw that as well. So I actually think how nice would it be actually if you to have an AI that looks over your shoulder to remove stuff to simplify stuff like less lines of code, you know, I think that that would be super cool. I mean, I'm not a developer, right? I've scripted so I don't know, would it be possible? I assume so, right?

Yeah, I mean partially. There are code code automation tools that already look at kind of stuff that's not used and clean that up. Some code doesn't even compile anymore. When you talk about specific languages, when you have functions that are unused or variables that are unused, it just doesn't compile and it's just clean this clean this up basically. Get your shit together. Exactly. And it's it's specifically in Go that I know and I'm very fond of

that because of that. And it also leverages kind of the readability rather than writability. You have to write in a verbose way, but reading it is is pretty simple. You can see probably if I showed you that code you'll be able to figure out what's happening. And I think that's the more we do that, the more kind of simpler the tools are we use when it's a language or any other type of piece of software. Basically I think the better it does, the better it is to keep things simple.

But yeah, the the complex reality is it's not. It's not easy to keep things simple. No, it's incredibly difficult. But I do think that's what we what we should be focusing on because yeah, it's just easy to get dragged down by complexity. Yeah, I feel like I'm trying to figure out how to make that kind of habitual because I right now I'm in the PMC and I'm, I'm looking at a road map of things

we're going to deliver. And there's not really anything about reviewing what we have and cutting things loose. And I I knew going into this conversation this would be a topic. So I I already kind of kept an eye for that. And I'm like, OK, I'm trying to make kind of up in my mind why that might be. It's a tool for internal use and it's not external use. So there's a limited amount of users.

So maybe that could be a reason. But then still I think it's very valuable to kind of just take a certain amount of time and that's why I like kind of making it habitual is then it's just continuous and reviewing what we have and cutting loose what we don't need. Yeah. I think it's not easy because at the end of the day, like a product creates value for its users because they're able to accomplish something, because it makes something better in their

lives. So the better you understand that, the better you can you can understand, hey, maybe this action product is not necessary or we can remove it or we can make it simpler. But yeah, that really requires a certain understanding like that. That's not easy to obtain, especially because the people who created those features many years back often are no longer there. Yeah. So good luck.

Yeah, yes. Still, I think one of the most fun experiences I've had, and this was kind of a recent one, kind of in the last two years, was a lot of experimentation kind of on production, right, AB testing features. And I would build those features with the mindset of I might throw this away. So then I was really fast in the features I was building. I would AB test and sometimes the features had value and most of the times they had no value.

And even I could come up with a third option that the business didn't think about because it was easy to implement. And I just really was curious to see if this version would be better. And because of that experience and because of just the vast amount of users, we would see subtle differences in conversions because that's the

metric we would measure. And then it made me realise that a lot of features we were building or we were thinking that would be right or actually not right or did not increase conversion, so we could just remove them and I had no trouble removing them. And for the features that did have value, I would kind of put in the effort to make it more production ready than it was. But I really like that experience and I think we should do more of that, do more of

actually user testing. We do a lot, maybe qualitatively but not quantitatively. So yeah, that's a thought that I had. Yeah, no, I think that you're right. But I also think not every

developer has the same stance as you. The moment they build something, they are proud of it. It looks nice. I don't think they would like every developer would like removing their code like that. It could be, yeah. You think that's a sunken cost we? Don't care. I don't know, right? I mean, how can I say, let's say I, I, I write articles. I've written an article. I'm super proud of it. And it's not popular. And then you remove it, like, I don't know, man, it's very, very

frustrating. I would think, like, I mean, I've written articles that were like big successes and total failures. And yeah, the ones that are total failures, I'm frustrated about because I invest a lot of time. Nobody cared about them. And I was like, OK, that sucked. What a waste of time in In the end, I'm still proud of them, right? I'm still like, I still think they're good. But yeah, how do you say I'm not the best judge of that?

Yeah, it could be. But let's say now you're not writing multiple articles, but you're writing the same article and you have to expand that article continuously and continuously. Then I think at some point you would be like, Oh no, this part doesn't make sense and we would remove that, correct. Correct. Absolutely. We can build more, let's say, code repositories and then keep things simple in those kind of

isolated sections. But the problem is we build a lot kind of on top of each other. And that is where I think the complexity is of just having too

much. Like, it's it's hard for a single human, even a team of people. And what is going on in this landscape that is an organization, an organization is still just a group of people doing things, doing whatever they need to kind of achieve their goals. Yeah, but let's be. Honest, I think you don't even need to look at an organization. Just look at human beings. Like, if you look at your best friends or your family, how do you say?

And I would ask you about them and then I would ask you, do they have something weird where you're like, it doesn't make any sense? I don't get it right or that way. And I'm I'm sure every person has their weird quirks, which makes sense because they're complex, you know what I mean? And same with me. Like, I also got my quirks and weird things, you know, I mean every person. And if and if they don't have them, you probably don't know them well enough. Yeah, I fully. Agree with that?

Yeah, I immediately have to think about OK people. And yeah, the quirks pop up immediately. I I thought you were going to say you might not know, but I definitely know. Yeah, I mean. I mean, I, I we're not going to turn this in the person. If I ask you about your dad or your mom, I'm sure there's stuff in there that you're like, yeah, that was a bit strange, but but for them it made sense because yeah, it's just a complex

system. It has certain behaviour and it's and yeah, we might find it weird from the perspective of our complex system, but for them, it's apparently, yeah, normal. That's normal. Yeah. I was wondering if you've ever

found yourself kind of in that PO experience, advocating for things that needed to be removed rather than added. Because I think that those conversations for me are very interesting because I'm expecting to have them in the future as well. Yeah, I think. So I worked at a company where we wanted to remove something and and the big the big mistake I made is asking you know what I mean? Because The thing is when you ask people should we keep this, they will always say yes because

people hate losing stuff. Like we didn't have product analytics to be very clear, because the most obvious thing you should do is just, is it actually being used with data. But we couldn't do that. So I had I asked. So actually I just thought because I knew. So this feature, I knew how it worked and it didn't make any sense. We got so many support questions and I understood how it worked and if it would send an e-mail explaining how it worked. It was completely rubbish right?

And and it was so much filled with technical depths that reworking didn't make sense. I mean just to give an example, it had paginations pagination there and it was super slow and we discovered it was virtual pagination. So it's just kind of like no pagination at all. We have everything. Yes, yes, yes. It was actually loading. Everything. And then chunking. You're a developer, you can you understand what I mean. So very stupid. So basically what I did, I turned it off in the front end.

I just went to the developer and said, look, we're going to turn it off in the front end. I'm going to take the blame if we get support tickets and I just asked them, look, imagine we get 10 support tickets and people are super angry. How long would it take to get it up again? A few hours. OK, fine. I'll take the risk. I'll take the blame. Let's do it. Well, we turn it off, never heard anything. So I have a few months. We just removed it from the code base.

Yeah, so this is an example. I didn't have the hard data, but I mean, I do know there were a lot of support tickets and I did know it didn't make any sense because I couldn't explain it. I didn't get it. That's really funny and it's

also scary because sometimes I feel like, I mean, I am APM now, but I'm not. I don't hold the budget, let's say over the product. I have stakeholders and I have, I have business sponsors and basically I have to advocate for what is right, what I think is right versus what they think is right. And it'd be way easier from their point of view if they just say, well we need this go fix and go execute, but that's not how I'm driven.

So then that it becomes a dialogue because I think most people that's not how they're driven from the product side. You want to be, you want to have that ownership. So then you want to fight for what you think is right. If you think we need to remove that and someone from the business side says actually everyone is using that based on nothing, basically, then you can take that risk, go rogue and be like let's turn it off and see what happens.

But that might also have consequences then when you are actually incorrect. Yeah, yeah, I mean. Yeah. I mean sometimes you got to how do you say ask for, ask for forgiveness instead of permission. But of course I think one of the main things I try to do in the situations. So fundamentally I think there are a couple of problems in product management. So what people want all your stakeholders is this, what you're capable of delivering is kind of like this. You know it's just a big

bottleneck. So that's that's on your plate as a product person. The the other, the other problem is people want all these different things, right and you want to go this way. So one of the main things I try to do is facilitate those conversations. So instead of having a conversation with sales and the conversation marketing separately then you're the bad person. You know what I mean? Because you're making the trade off choices and it's opaque for

them. So much better is get them all in the room and just say like, hey, we can do these three things, you want these 10 things, we need to make choices. Yeah, and then you make choices together and then then there's much less disagreement. But I think the moment you kind of like do it separately, then they think you're the bad, bad person, You're the bad guy. Like, yeah, because. You're saying no to kind of just their them. Yeah. Yeah.

And yes to others. And they have no clue what's going on. Yeah, exactly. And they're. Thinking that you're the one, you're the gatekeeper, you're the the bully, so to speak. But I think, yeah, if if everybody agrees that it's less valuable, then we're all the bully and which is much better. Yeah, exactly. You can fight it out. Don't involve me. Yeah, you can also. Just say like, look, if you 2 disagree, go figure it out. Like tell me what? Yeah, I mean get back to me.

Yeah, get. Back to me, I mean. I mean, that's an extreme case, right? I don't like doing that. But let's say there's just vehement disagreements and it's A or B, and you just tell them like, look like you 2 figure it out. Like we have to choose, we can't do both. And then they'll get back to you when there's a decision. Yeah, exactly. When it comes to kind of

filtering all that output and seeing what the value is and and where you want to go, I think that's kind of where I'm still learning because I have, let's say, numerous amounts of problems that I see and that we can solve. And people love coming up with solutions. And I have to be like, OK, that's one option. It might not be the one we go with and I was like, but my,

like my option is the best one. Like that's the feeling I get sometimes and and I'm I'm really learning and filtering that out and writing down even though a few options, a few options that make no sense. But sometimes there's a little bit of value in that. How have you kind of learned to navigate that? Because I feel like exactly as you said you're kind of the funnel there.

Yet you also don't want to become a bottleneck because it converges with you and then it diverges to the team again. And I feel like somehow you need to filter out the nonsense versus the value. Yeah, So what? I think. What is very makes it very difficult is some of the stuff you're doing is actually not

complex. It's complicated like like let's say let's say you're working at e-commerce and you you you have like a A. How do you say you can optimize the shopping cart, you can make it a little bit faster. We all know that's guaranteed money and probably you could say hey reasonably well in one or two weeks we can improve the time. You don't know exactly how much, right, but you can reasonably be so.

You also have stuff where it's much more uncertain, like it's a completely new feature, like it's a new problem you're solving which is way more complex. And I think one of the main things which I've seen is so a lot of companies, they make all these business cases, right. They use Rice, for example. I think that works really well when what you're doing is complicated because then you can count yourself, Rich, you can predict and plan.

You've got an idea. Oh, we're adding a new payment method for the Netherlands. Oh, it's ideal. OK. So probably it's going to bring in 100K per month because we know that, right? And it might be 80 K when we finally do it. But you can guess that. And I think that's the main challenge the moment, if you really pick like a approach like Rice or with these business cases, then you automatically

focus stuff on you. You think you're able to plan and predict right well all these complex things. So I think the main thing is keep also room for exploration. Don't count yourself rich. There's a Dutch saying, I don't know if it it translated like all those spreadsheet victories doesn't mean you will deliver more value. I've literally worked at companies where they deprioritized adding a new payment methods which is guaranteed money, right? What's the most popular payment

method in the country? Well, they prioritized a giant business case for international shipping. So basically people could order from Greece and other countries. Yeah, there was only wrong problem. The shipping costs were like €20. You know what I mean? So.

So if they would have done a little bit of research on experiments instead of immediately jumping to building because the business case looks amazing on paper, they would have discovered that and I and and these are just kind of the things which make it incredibly challenging. So the main thing I would like to say is do small things, get more understanding, do cheap small things like you said, like

PO, CS or stuff you throw away. Because if you immediately start building based on all these assumption, all these ideas, there's I've been in situations where they literally worked on six months or something, you could throw it all away, you know, and and yeah, it's just a coding stuff is a slow way to find out you're wrong. Yeah, yeah, exactly.

That's very interesting. I I still wonder somehow like I know this and you know this and probably people if you if you explain it like this, look at what you have and expand what you have because that's easier than than building something from scratch and then adding on top of that with a piece of glue. People are like, yeah, that

makes sense. Yet it it still goes wrong in organizations, yet those decisions still kind of get skewed in maybe the incorrect way, with hopes of better returns, basically, yeah, but I think. I really honestly think that boils down to our schooling system, like our whole schooling system and also a lot of universities. You get questions where it's kind of boils down to, I mean university had like a questions where they like they dissolved like a molecule in water.

The water raised wasn't raised by this much. What is the molecular weight of the molecule? These kind of questions around like 6 pages of calculations, but you could calculate it, right? But that's not real life. You don't have perfect information. You know, I mean, you don't have all the understanding. And I think that's the main thing. We, we act on this one track where we're like we have perfect information. We have all the understanding, we can predict and plan and all

that complex stuff. It's much more like we don't know what works. We have to figure it out. We need to build something so small, see, see if it works. And yeah, we're just not that good at that. I think our education system just kind of is like, here's the book, study everything. These are the answers. Yeah. Good. Luck. You can get 100%, Yeah, that's not how it works, no. No, and especially because

that's not how it works. I feel like when you have, let's say, a conflicting opinion, that's the most challenging part. I feel like and especially when people get dogmatic or people don't look at data and and really become, yeah, attached to their ideas, I feel like that's when conflict happens and those are the hardest to get out. Do you really actively change your communication style, for

example? Or how do you how do you influence people and still move towards what you think is right? It's sometimes it's very. Difficult. Let me just give you a very concrete example and I'm just curious how you would solve it. And I'll, I mean I don't think I handled this one graciously but for example you are rebuilding a product and and one of the lead developers said hey give me 3 months and I'm going to design the architecture.

You're just going to write stuff down not do any coding, just talk, think things through and then yeah. So how do you respond to that? Is that how you. I mean how would you respond to the how I would do it? No, no. But it's very interesting right This, this this person was very senior and they and I just still don't look, I don't believe that's how good software gets built. Yeah, I don't. I believe the best software is emergence.

I believe like complex systems evolve from simple systems that work. You start with something simple that works and then you make it more complex. And I don't believe you design something complex because then we make all kinds of mistakes, right? All kind of undesired behaviours creep in because yeah. And by starting it simple you actually see how it behaves and whether there's undesired behaviour.

That's that's my paradigm. So I just said, look, I don't believe that's how it how it how you build good software. So we're not going to do that. We're going to do APOC or something. And yeah, was I right? I don't know. Right. But this is a fundamental belief like so how would you have tackled it? Did you? Before we handled that, did you lose that person because you? Yeah. Yeah, yeah, yeah. Yeah. I lost that person. Yeah, right. I definitely lost them.

Yeah. It was just a fundamental different way of looking at software development. Yeah, yeah. It's it's hard because I think losing that person is a risk basically because they do have experience. They they have value probably within that organization, the history, maybe Even so that's the hardest part. So that's what I would try to avoid. But if it's really that fundamentally different, then yeah, you have to make a decision there. I I've had it before and I I

even have the role of a consultant. So it's harder for me to argue with people that hired me. But I came into an organization and it was very similar. The architecture was already thought of, but for me, the reality wasn't just it, it wasn't there yet. I was like, why do we need this? Yeah, because in the future we're going to have XY and Z like, but we're we're not there yet. And then again, why do we have

this? And this because from a developer standpoint, I was really, it was really hard to get things done right. I I would have to make changes here, move to a different repository, do things there. There would still be a dependency and I would be like, that shouldn't be the case. And especially when we're building up, I don't want to deal with all these this, this headache. Basically, I just want to get the stuff done. I know it's supposed to be

simple. Yeah. Our architecture would make it very complex and we challenged that over and over and over again. I'm I'm lucky to be with colleagues that have the same mindset until a point where things just didn't make sense. And we said, OK, give us time to try our way basically because what we've built now is a proof of concept. He always said we might throw it away. We're like this is the time to throw it away because we've learned a lot and we can incorporate those learnings and

do it better. So then basically we built up the trust by going their route and then at some point saying, OK, now we have to go our route and then we're going to see what makes most sense, give us, give us a little bit of time to prove ourselves. And then we went from scratch, very simple. And this was also the first time that I've been involved from the scratch of creating software, which is a completely different ball game basically than building on top of what is already.

It's pretty different. It's very difficult. I one of the. One of the, yeah, challenges I saw was making decisions because let's say we need a database, OK? We have numerous amounts of databases to choose from. Which one do we pick and why? And I'd be like, man, I don't have the knowledge to investigate all of them, but we do have to make a decision. I was with a person, I really looked up to this guy.

It's one of the reasons why I joined that project because I wanted to work with that guy and he said, well these are the non functional requirements, we don't want any operations. So it basically boils down to these two because we're also in a cloud environment and this is what they offer. We'll pick one, if it doesn't work, we'll go to the other. I was like done, OK, done. We picked one. It actually did not work. And then we moved to the other

within a day. And I was like, OK, this is a completely different way of making a decision, a decision we made a decision that was not set in stone and we were flexible enough to move because of the choices we made in software. And then we built things up from scratch, very simple. And then we expanded and made it more complex when it was

necessary. But that was actually kind of a year in. So this way of working for a year, we leveraged speed and simplicity rather than working in an architecture which was already kind of future proof, but not really because no one knows the future. That's how we handled it kind of in that project. And I'm really happy to have been in those shoes with that experience because now I feel like I can make a more solid argument if that happens again. But I do agree that not not

every on things like that. The person from the business side had this grand architecture view and that's actually what was built when we started. And we had to kind of, yeah, fight back and gain trust and do it differently, yeah.

So I think one of the challenges is before starting and these are concepts I mentioned in my book Fog of beforehand you just don't don't know everything before starting and when that happens is we get scared. So we're actually getting this mode of analysing thinking like, you know, like let's look at 20 database and then we inject the fog of speculation and we actually probably make an even worse choice, you know, and and yeah, and and that leads to all kinds of problems.

And I think that's the key thing, like every step you take help shape the way make simple decisions makes it and and and as you gain more understanding, adapt, like don't rely too much on prediction because you're going to be wrong. Like premature optimization is the root of evil. I know some people told me that. How do you say this was taken in a different context than people use it? But it doesn't matter. I still think it's a great

quote. I think, yeah, how do you say emergent design like that, that's that's crucial. Like discover what's like when you do the work, you discover what's necessary and that's what you have to do and it's very scary. But that leads to the best solutions. And to your point, I the same company, right, where where I kind of had a difference of opinion, they had to pick a testing framework. So you know what they did. They did exactly what you said.

Compare 20 testing framework with all the checkmarks and then they actually had a number one choice and then they actually tried to use it and it didn't work because it didn't work with Cloud Run or something like a cloud Run had some kind of agents and it didn't work with that agents, Cloud Run agents. So yeah, Lot of time wasted, yeah, Yeah. That's good. Then you're like, OK, do we compare the other 19 now where where do we go from here? And it just. Doesn't make sense.

Just go for something that's popular. Many people use Good enough, you know? And yeah. I I do understand it because like comparing everything and for me having not had that experience, I was like that's how you do it. Like we have to make a an accurate decision based on the knowledge we can find and the knowledge we have.

And then that just the other person in my team was like it's not that complex that we just have to make a decision and a lot of stuff works basically and we get to a point we already stress test it and kind of future proof it by virtue of doing it very simply and then we see if it works or doesn't. And I thought pivoting would take a lot of time right. Because some decisions are like the backbone of your software.

When we talk about that Jenga tower, these are like the building blocks, the base you start with. And if you start with an uneven base, yeah, then everything comes tumbling down. Yeah. But apparently, and this I had to learn, you can actually swap out a base if there's nothing on top pretty easily, Yeah. So then you do that. Yeah, but.

You're right you for example I worked at a company where they used a non relational database, but then they actually needed a relation so they used it in a relational way. Yeah. Yeah. No, don't do that. I know, I know. But that's that's very interesting, right? That's an example of making a apparently simple choice, but really screwing yourself up. And I think that's the key.

It's very hard. It's kind of like playing a game of poker and not all the cards are on the table and you have to make the best decision you can with the limited information you have. And I think the key thing there is keep in mind they're going to, their new cards are going to appear and they can change the playing field and that's the main thing we have to take into account. We don't have all the cards on the table. There are new cards that are going to appear.

So how do we make a choice that we can act on the new information to the best way possible? And I think that's what we often forget. Absolutely. I think it's funny because I I

now have the PM role and I I have to learn and I can do this to let go of the technical side and trust my team and I know the people in the team. So trust comes easier in that way comes by default, but it's better if you've already worked

with these people and I have. But from a technical side, I still have kind of insights and learnings along the way and that way I feel like from APM that is non-technical, they have to really rely on their team and especially when you have for example that discussion with the architect that says this is the way we should do it. You have to really stand your ground if you believe something differently and if you don't, if you don't have those overview, that overview, those insights,

then you go that route and it might be very painful. Yeah, and by Pier. It's very difficult, right? Because I think one of the main challenges is, I mean I'm going to generalize a bit, but I think it's, it's true a lot of developers like shiny new things, right. So like micro services or graph QL is out.

I mean a while back like oh, let's use graph QLI mean I think it was, I don't know for who this quote was, but someone said like software engineers are are drawn to complexity like a moth to a flame, you know. Yeah, I don't know who said this, but I read this somewhere. But there are definitely those cases out there. And I think that's one of those challenges like how do you, how do you say, I think often case the shiny new thing is probably not the best choice.

You probably you should go for something that's more reliable like, but it's going to be more boring. You're not going to learn new things. But yeah, that's what I often see wrong and it's been very difficult to challenge. I mean, I've worked at a company where actually we were rebuilding our products and they went for Kraft QL, caused all kinds of problems because I'm

not an expert, right? But I mean, for example, this was in digital asset Management. So based on certain fields being present or not, they could not see certain information and it was just there was not as much out there on how to solve these things. So yeah, wrong decisions made, stuff slowed down. Yeah, I think that's one of the challenges as well. Like, they can fool me, you know what I mean? So the well, I would often be thinking that let's go for the more robust, more boring stuff.

But they'd say, no, we need craft UL because it it's less size, it's going to be more performance, future proof. And how do I know whether it's really a legitimate reason, you know, that that that's, yeah, that's what I find sometimes difficult, You know, I can see that. Challenge. Yeah, absolutely. I I wonder if people are drawn to the complex technologies or

the new stuff, let's say, because reality might not be that complex. Like there's a lot of money in e-commerce, right? But if you've seen e-commerce, if you've done e-commerce, you can do that with the technologies that exist. When an LLM pops up, it solves some problems, but it doesn't solve all the problems. So you shouldn't use it to solve all your problems. Yet it's interesting to do that, and it makes it more complex,

makes it more challenging. So I can see that from that kind of engineering mindset, But that is the worst choice then for the organization, yeah. But it surprises me because for example, I rebuilt an e-commerce platform that was one of the only rebuilds that was almost delivered on time. And why was that? It's because we had a team that had rebuilt many e-commerce platforms before and all of them, they do kind of the same things.

They're, they're of course, there's, I mean there's an order, it needs to be shipped, it needs to be paid, there's a refund. And yeah, I mean if you do that a lot, then you've got a pretty good understanding of all the things that you need. Maybe not exactly all the details. So yeah, but I I think one of the challenges still there is, like you said, people like keeping stuff, making it complicated.

A good example is so when we're rebuilding, we discovered, how do you say that the current order XML file contains all these redundant fields? And the developer came to me and said we need to have a workshop and discover all the fields and blah blah blah. And I told them no, I said look, look, here's what's going to happen.

Nobody will know. We're going to waste a lot of time just implement all the fields make sure it works first and then we're going to remove, remove fields that we are like, hey, we don't know if we need this and then we can check you know, does it do we really need it? Because I don't think anybody knows. And he of course he went to opposite road and then he came back to me. I can't get it to work because

nobody knows stuff. And then he did what I what I said and he and we removed stuff and yeah, in the end we had a simple file. Was it more work on paper? Yes. But in reality, it was less work because we first had something to work. Yeah, because you cannot rely on people. They don't know how everything works, unfortunately. Yeah, it's like you. You. Find yourself in a labyrinth and you're like, oh, we're going to try every route. It's like, yeah, that's not

going to work. No, no, We have to figure things out. Make it smaller. Make it at the end of the day, even when. People say they know how it works. They they are sometimes even wrong. You know and and and much more reliable judge is the system like is the order really ships is the refund really processed in the correct way That's way more reliable. Yeah, yeah, I. Fully agree.

I I somehow and I I feel like this is a circle that people know of that things get complex the more complex you make them right and the people who are there, sometimes people leave and new people come in, but we're always there.

We're always building things and at some point I don't know if there needs to be a trigger or a a certain symptom, but things get slower, whether it's velocity, whether you're measuring that or not, whether it's kind of your thought of how things work versus what's actually delivered and then the time spent there, somehow it slows down and that's slowing down. If it doesn't stop, then it it's it's basically not feasible anymore.

Basically people start thinking, OK, if we do it from scratch, even though that's also a a huge decision, The more you time you spend on it, the more time you're going to spend building it from scratch basically because then you really have to figure out why do we have this, how does it work, why is it there in the 1st place? You get into all of that. But it is a cycle that I've seen and it's it's really hard to get out of, I feel like. Yeah.

So I think the big problem is, for example, if you look at products like first version of products, they have a lot of parts and then over time they reduce the parts. And I think the main reason is because there's a clear cost. It's very visible. You're making a car and you know how much the the car part costs. If you remove a part, you're going to save a lot of money because the best part is no parts, it doesn't break. You don't need to make it so.

So I think in software engineering we don't look at that enough. Like every line of code is kind of like a parasite that needs to be maintained unless it delivers value, you know, So we should really take a look. Do we really need this? Because they're going to be support tickets. There's somebody asking questions. A new new team member needs to be on boarded. And I don't know we need this. I think this pressure is really good. Like, what can we remove, What can we simplify?

And another reason is there's just always a lot of rushing, a lot of pressure to deliver stuff.

Like when I was a product person, product owner, I always said I want your estimate, including cleaning up stuff. I don't care whether it's 8 or 13. I don't like what do you need to do your jobs. We can deliver stuff fast in the future. That's the estimate I want. And and and yeah, of course I will sometimes ask questions, right? If I ask for something simple and it's a huge amount of work, then I will ask why. But I mean, I think that's

that's what we should be doing. It's part of the job and and and and what made me really sad is so I think this is from Henrik Nieberg, so it's not mine. Basically a cook, you know when they cook they need to clean up like if you're cooking like 5 courses in a star restaurant. If you wouldn't do that, you cannot do your job. So it's expected. It's part of the job and I think same software engineering cleaning up as part of the job. Like, nobody should ask you,

like do we have to refactor? Like, no. I mean, it's part of the job and of course that comes with responsibility. Like if you, if you're going to make the kitchen spick and span like completely perfect, clean between courses, you're going to be too late. You know what I mean? So, but I think that's, that's a kind of professionalism we should, we should expect and also give, like allow them to do that because it's part of the job, I think. Yeah, yeah.

Again, I'm going. To last time, I'm going to play devil's advocate for me. What I've seen is the right way to clean things up, let's say remove code that is not there. But I've also seen developers that are like, I think this is

nicer and then it doesn't change anything. And then am I like, OK, is that, is that good effort? Is that wasted effort? Because the people that built it are still in the team and then they're going to get into this argument of it was already working. Why is it not this? And then a person's going to say a very subjective opinion, I think it's nicer and then they're going to butt heads in the way either it's going to go left or right. But I I think in any case people

are going to be unhappy. That's kind of the the hard part of the OR the dark side maybe of refactoring I've seen, but that's kind of. Like the discussion, like how do you feel the the dishwasher in the most optimal way? That's exactly that. Exactly. At the end of the day, most. Of the times the the dishes are going to get clean even though you do it slightly differently. I mean of course if you're really horrible, right? I mean it is possible it is there.

But. Yeah I do agree to you and and and and a good example which I've never ever worked at a company where a developer came was joined and he saw the code base and was like this code base, the joy. It looks beautiful. I get it. I've never had them alive. And that's and I think that's and I think this boils down to I think this was Joel Spolsky that said this writing a code is easier than reading code and and and how do you say all choices that were made by people writing

that code. They had all the context. So whenever someone takes a look at this code from their current perspective, unlimited understanding, they're like, what the Hell's this? But they're just seeing one button from like, the whole car without understanding, like all the trade-offs and the sign decisions that were made. So yeah, maybe someone put the put, put the button there because that was the only place there was room because of

something else, you know, like. And yeah, it was not optimal, but it was the best choice given the constraints. Yeah. And and and, Yeah, and. But that makes me sad, right? I mean, I wish one day that would happen. Yeah. Yeah. Absolutely. I think there might be a really good learning in there. If you want to refactor things because you think it looks nicer, maybe, maybe gather the team and say this is my idea before you start working. Yeah, and and see if it actually

is nicer for the team as well. Yeah, yeah. And. And what is nicer, right, It's very. Subjective. No, absolutely. Because then we're entering. Spaces versus tabs territory, you know, like. I mean the reason. It's a discussion is because people think it's nice. Yeah. And I. Think then you should just have a like a make a how do you say decision like this is how we do things whether it stops or spaces or whatever and stick to it And yeah, some people are going to be happy, some people

are going to be unhappy, it's. It's it's a good thing, and it's OK to disagree and still commit. But we need commitment. Yeah, agree. Cool. This has been a blast night. This was a lot of fun.

Was this kind of what you expected? Yeah, this is what I expected. So here's what I find interesting, right? So I I very often get asked for product management and agile podcasts. But I'm not. I'm not a I've never been. I mean, I've scripted automated tests. I'm not a developer. So I find it nice to to discuss these more technical topics, kind of. But I of course I'm very well aware I'm not a developer. No worries, there's. Always when people.

Tell me like, yeah, you're a product person, but you're not a tech person. You're not a but I mean, I do think I do my best to understand. I think that's. The best part I I don't like labeling people. I think people can do whatever they want. If you want to be tech person, you can be tech person. It's just time and effort and if you want that, then you can get it. So I look forward to that movie screen. Yeah, one day, 10 years maybe. Yeah, for sure.

Cool. Then I'm going to round it off here. Thank you so much for listening. I'm going to put all my to socials in the description below, check them out, let them know you came from our show. And with that being said, thank you for listening again. We'll see you in the next one beyond. Coding.