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.
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.