Hi everyone, my name is Patrick Akio and I want to ask one
question. Is your company doing product
management or bullshit management?
Joining me today is my friend David Pereira and he shares his
hard earned stories from the field of product management here
as well as in his new book which is of now untrapping product
teams. Enjoy this episode.
I asked Mark to the same and I'm very curious to hear what you
think because, I mean, I see him speak, I see him write, and I
see you do the same. Do you have like a preference?
Do you like writing more than speaking, or I think you enjoy
both? No.
I enjoy both. So it's hard to say what I like
more, but I like helping people. So whenever I see that people
can benefit from what I do and say, ah, that's cool.
So speaking, it's easier to see that happening.
So remember giving a talk, It was what Krakow?
And then I shared a story there and so on.
And then I asked my favorite question, which is are you doing
product management or bullshit management?
And then everyone was looking like very curious what is he
talking about? And so on.
And I said I shared my definition of bullshit
management, which is an art of doing things that drain your
whole energy and contribute to no value at all.
And there's an equation behind it.
The more bullshit you handle, the less value you create.
So I started saying like examples that you are doing this
kind of thing. And then I saw a loads of people
taking picture and so on and very curious and people like
from the back because there were I think 150 attendees and then
standing, taking picture. And after that there was a line
people wanted to talk. So it's easier to see how they
benefit from it. And writing is different.
Some people will comment, some will say oh like thumbs up and
so on, But you interact less. Yeah, yeah, interesting.
I was thinking about the bullshit management and kind of
the reason why. Because I'm wondering, is the
reason why people don't know if they're doing bullshit
management or let's say product management because they roll
into this, or because the role is not as defined, or because
organizations are just doing the best effort they can?
I think it's a combination of everything.
So if I look at myself, when I started my career, I simply
didn't know what product management was.
I started as a product owner and in general, I thought I was a
bridge between business and tech.
So I did more of that and people actually would tell me you're
doing great work. So I thought I was doing great
work until I realized I was not. So it took me a while because I
I I got promoted because I increased the velocity of the
team. After six months, I say, hey,
you increase the velocity by 35%.
So hey, let's talk money now. So I said all right, so I was
rewarded by things that actually didn't drive value.
So in this case there was a lack of product management
understanding in the organization and I arrived and
row unprepared. So then I I did loads of
bullshit management instead of product management.
Then I moved to another place that was someone who knew how to
do it. This person has founded 3
startups and said hey, that's not how we do it.
Don't focus too much on this backlog management.
Focus on understanding what works and what doesn't and
that's it. Backlog should be just something
to have enough for the upcoming Sprint and that's it.
Keep iterating and drop things that distract you and then I
Start learning. So what happened is many
companies haven't seen a different way of working and
when they hire someone who knows if the person is not in power to
change, it will be more or less the same thing with different
frameworks, then that becomes bullshit management and so on.
A very interesting. So there's really, there needs
to be a good understanding of what actually drives value,
right? And it's easier to probably look
at some artifacts like backlog and velocity and things that get
thrown kind of in the bunch of this framework and then focus on
that rather than actually delivering value, Yeah.
Because there's an extreme focus on efficiency and thinking that
we can predict the future. And I like comparing with the
physical product. Rd.
'cause if you look at microphone, microphone is
something you can study how to do it and so on, and you can
deliver the same microphone all the time.
There's a process you can put behind and you ensure the same
level of quality, the same product.
But when it goes to digital product, actually imagine that
you are creating a microphone, one that thousands or maybe
millions of people are using that, but it's only one and it
needs to serve all of them. How do you do that?
It's a very different game and something that we are still
learning. And what I see happening is that
some people, they know how to do the thing, but they prioritize
safety because of course they need to make a living.
And they say I'm not going to pick this fight here, I'm not
going to pick this conflict. Then you accept sometimes
because you don't see the room and so on.
And in my career, actually, I have been, let's say, quite
rebellious. Yeah, I haven't because I I
don't like wasting time. So I would say why are we doing
this in the 1st place? And then sometimes would be
because the boss of my boss said so, so we should be doing that.
I said OK, that's all right, but why did he said so?
I want to understand why he said so and then someone said I don't
know, I'm not going to dare asking him.
He is in a high rank. So if he said we have to do it
said yeah. But if I don't understand why,
big chance I'm going to do something that won't deliver on
the why, maybe leave on the what and the how.
But if I miss the why, what is the point?
So some people don't want to pick on this kind of questions
because it might be that the why isn't clear to the top
management and then you need to change and that's all right.
And what I got surprised is if you have a genuine intention of
helping people listen to you, it's not about challenging, it's
about how you challenge. And you say, hey, I just want to
do something good for everyone. And if I don't understand this
part here, this piece of the puzzle, it will be very hard for
me. Can you help me?
And then I can help you. So it's more like this
conversation. But some people say, hey, it's
for me, I'm exchanging maybe money for time.
So I come here, I work 9:00 to 5:00 and I whatever you tell me,
I'm going to do my best from that.
Don't want headaches beyond that, and that's fine.
It's a choice. So not everyone wants to to
change the status quo. Yeah, for myself I it was
definitely a big driver asking why, but then more from the
software engineering side in and I'm lucky I'm at a consultancy.
So the next assignment I had there was a product management
role. And I thought it would be really
fun to do that and kind of leveraging software engineering
experience and then having those conversations and see if I can
drive value and actually be accountable for that as well.
Now I think it still drives me kind of this curiosity, but then
I get into conflict of stakeholders and incentive
structures and more complex political structures than I
could have ever imagined. And I'm trying to navigate that.
And still at sometimes I'm like, I'm actually driving value or am
I just stuck in meetings And like it's very hard to find the
same fulfilment I had that I had as a software engineer because
things were more black and white.
I delivered a feature. A feature has value or we
iterate on that. And with product management, I'm
trying to make decisions based on what I know there's a lot of
unknowns. And also I'm in the ESG domain,
so it's even more unknowns from a domain perspective.
And then sometimes I doubt myself and think of am I
actually making a difference here?
Like there's not the same black and white fulfilment I had from
software engineering. And I reflected on that and I
realized I do miss that. Yeah.
I get you and what I have realized is like the farther you
are from getting things done, the longer it takes to see the
value creation of what you contribute.
For example now in AC level position I don't know if I'm
doing a good job until I see the result which is the team doing
the work and the work creating value.
So I need to create the space where the ideas can flourish
instead of telling them what to do.
But that is a very different job and in the product management
sphere should say, I like saying like the job of a product
manager is to find the signs through the noise.
And for that it's about communication.
And some people ask me like, what do you do as a product
manager? I said you talk and you talk a
lot, you communicate to loads of people and the magic happens
when you can convert all of this communication conversation into
something that drives value and you create alignment out of
that. It's easier said than done, but
it's all about communicating and making it clear, very
transparent. All right, So this is where we
are going. Let's find what will get us
there and let's drop what will distract us from getting there
and getting stakeholders on board.
Because there's this thing of stakeholder management, which is
a term I don't really like because you don't manage them.
You need to involve them because if you try managing, then you
will get on this political situation that there will be
kind of a bit, hey, I need this thing here.
I need this thing. So you do it for me.
That goes through kind of a very strong classic service provider
relationship. Like I pay you due and that's
not what you want. So the product management, if
you don't like communication, you don't like this kind of
game, it's not going to be pleasant for you.
But like, I like that because I was a software engineer.
And then the other side of the coin, it means like it's kind of
the classic giggle, which is garbage in, garbage out.
So sometimes I receive some things like a feature, I would
implement the feature and so on, but the feature would not be
used by anybody and I would not know why.
So that's why I moved to product management, because I said maybe
I can figure out the why and ensure that software engineers
will never do something without knowing the why.
So I would tell them This is why we need to do it and this is
what we want to achieve. How can we get there?
Yeah. I love that that's what I'm
trying to do as well. And I'm trying to make it
crystal clear on what the Y is. Because also from the other
side, if I have to implement something and if I don't
understand that, if it's not clear, there's a lot of room for
error like. And now being at the product
management seat, I can see like all the room for error that can
happen because if I don't do my job well or I communicate in a
way that people don't understand and actually say yes, but they
don't truly understand, then it's not what I expected or not
what people expected. And we have to have a
conversation there. I feel like it's really fun and
I'm continuously improving, but I could definitely use maybe
more guidance in in how to communicate.
And I'll give you an example, I, I came and there was a
predecessor and they had different Rd. maps for different
stakeholder groups and timelines.
And I mean from a software engineering point of view, I
don't like Rd. maps and timelines especially when we're
talking about end of the year timelines.
I have no clue what we're going to deliver at end of the year.
But then I came into a seat and that was kind of what was
expected of me to manage this road map and update timelines
and communicate accordingly. And I'm really trying to fight
for actually just having a list of milestones and timelines will
flow. Actually when we've done more
research and design and even when we have timelines, it will
definitely be something we deviate from because it's just
not possible to predict, to predict.
And I feel like I don't want to set wrong expectations with
timelines, but yeah, that's a that's been a struggle
especially because that's what people were used to kind of Rd.
maps all the way to the end of the year.
And I get it from a budget perspective, it's more easy to
allocate money and resources and etcetera.
But from my side and from the team's side, I just want to work
more in a trust based environment where we say OK,
list of milestones as have a dialogue on what the biggest
priorities are and let's work from them top to down and
something comes in between, it's no problem, we'll pick that up
and it's way harder to do it with milestones and with
timelines and road maps rather. For for sure.
The more prescriptive the timeline and the road map, the
harder it is to be creative. And that's what I have been
telling stakeholders. I can make these things up.
You will be mad at me. That's very simple.
At the end of the year, we will be talking why we didn't
deliver. So that's not going to be
helpful. And then what I start telling
them is let's think about opportunities.
So let's think first about our strategy.
Which game are we playing? Are we playing a growth game?
Are we playing a game that we want actually to increase
retention and we want to increase the customer, for
example, lifetime value. It's different game.
Are we trying to enter the market?
We're trying to go to a different audience.
First let's start understanding the game we play and then we say
what do we want to see? That will show that we are in
the right direction, that those are the milestones.
And then we can say maybe we want to start here and start and
see this thing happening. So then let's figure out how we
can make that happen. But always go oriented.
So road map can be fine even if we go a little bit longer.
I also don't like long road maps because they are lying.
So what I say for example, now in the B2B world, I'm struggling
with that because the expectation as you said, I'm
bringing a product to the market, it's B2B in a classic
industry, maritime industry. So they tell me like what's
going to get done by when and then I say what's going to get
done by when is a bit complicated and they expect
feature definition. And then I start saying like
what we enable, what kind of jobs to be done we will enable
in our product. It's a different thing.
So when I look at the maritime industry, there are many aspects
there. So you have the container, you
have general cargo, you have cars being transported and so
on. So at first we start with
containers and then we will adapt that for the
transportation methods. We can start with the vessels
and trucks and then we can add rails.
So we enable rail coverage, but we don't say with features and
how we enable. So why do we do that?
It is about a strategy of market expansion.
So we started like that, but in the beginning the conversation
was like I want to see the road map for the next three years,
what you deliver by when, it's simply a lie if I if I do that
and we will all the time discussing why we didn't deliver
because I can tell you we're not going to deliver anything like
that. So you need to find some
balance. And for me what helped was this
strategy, what we need to achieve and why.
And then from there we can go, we can set milestones that help
us Orient and make decision. And very important is to say no
to the other things and be able to prioritize one goal at a time
because one of the dysfunctions I see is a prioritization of
multiple goals. Then you are going to have
multiple micro teams. That's not helpful and not fun
for anyone. But moving the conversation and
the dialogue from one stage to a stage that is more effective, or
at least in your vision, let's say, requires a lot of
confidence, right? And I feel like, I mean, for me
in this position, I have, let's say, the history of software
engineering and I have guidance from ACPO or my manager at a
customer. But I'm not sure if let's say a
product manager always has one team and they're responsible for
that team and that product. Is there kind of a lack of
guidance you think in doing the right thing because it's very
hard to, I mean, gain confidence in moving conversations and
actually say no or you're in the driver's seat and that's what
expected, that's what is expected of you from an
organization and maybe even the culture.
It's a highly complicated job. Oh yeah.
Yeah. So there is the competence, the
confidence and the experience. So have you been exposed to that
in different ways? Either you were part of a team
and you have seen this way of working.
If you haven't, you need someone who has done that to support
you, because that's what I see. Companies expect you to be the
driver even if you have one or multiple teams, but then they
quickly push you to be the passenger.
And the problem in this case is you start being the passenger
and you don't even know who the driver is.
So it's very unlikely we're going to get anywhere.
So you need to claim back the driver's seat to the best you
can, and that's not about complicating things.
I had that in Brazil, for example, one of my first jobs
and it it was a situation that I I was just doing a little bit of
everything to keep people quiet. That worked in the short term
because then everyone would see some of their wishes in the road
map. Then it would say good things
are progressing. But what happened is the team on
the other hand was saying, hey David, what's going on?
We have no idea what we're doing here.
We're doing loads of thing and nothing.
They don't connect to each other, said, can you prioritize?
I said this is a prioritization. They said no, this is a
fragmented set of things that you asked us to do.
This is A to do list, not a prioritization.
And then I went to the stakeholder said, hey, I'm
concerned this is what's happening here.
The soft engineers are unable to collaborate because they work on
different things. And I said, I have one question
for you, what is the biggest problem we have right now?
And then someone looked at me and said, well, every customer
we acquire costs more than the customer lifetime value and then
said all right, so should we work on that?
And then the others start nodding And I said what is in
your list of requests that we could work on that?
And then two stakeholders said you can forget about everything
that is related to me because they don't contribute to this
and I can't wait. And these two stakeholders were
always pissing me off. They say, hey, when are you
going to deliver that and so on, because they also didn't have an
orientation. What or were we trying to
achieve? So it's more like having a
conversation. But the key part, I got all of
them in the same room and I wanted them to have a
conversation and I shared a concern.
So the point here is can product managers share vulnerability and
say one very important thing which is just a few words?
I don't know. I don't know what is the most
important and I need help. Can you help me figure that out?
Yeah, I I realized that. And once you do, people will
help you out. It's just getting to a stage
where you have to acknowledge that and it will be very
confronting also for people if they don't know.
Because if no one knows, then you have to have a real open
conversation and think about where are we actually going and
what are we doing. I've noticed that not so much
from the stakeholder site yet, but it's very clear to me when
it's from the engineering side. When we have a conversation and
they're like, OK, we've done this, now we have, we see four
options and like, OK, let's let's pick from the options.
But then if I explain what the goal is with these features, or
this epic, or what we're actually trying to achieve and
why specifically for the user, then all of a sudden everyone
points to the same option and where there was confusion first.
All of a sudden it's now clear, OK, if this is the goal, then we
only have one option and we're going to do that.
Realising sometimes that the vision or the why is unclear and
clarifying that or at least navigating and exploring that
has been very valuable to me and it's something I've learned on
the job. Like from the software
engineering side, I never realised that having that
clarity is actually what really increases productivity.
But now that I'm in the product management see, and productivity
is still something I want to focus on also from a team
aspect, not really from an efficiency point of view, but
actually from an effectiveness point of view, then, yeah, I can
see if things are unclear, things are not moving as fast
for sure. Yeah.
And then moving that to the stakeholder side, it's really
hard to figure out when things are unclear for whom because in
those conversations, people have the confidence to say this is
how it is or this is what it is. And I don't know if those are
holes or if those are based on research or if all of those are
assumptions. The worst thing I've heard
people say is, well, I think XY and Z based on nothing.
And then I have to be like, OK, is it right to poke holes in
this now? Is it worth it?
Does it matter? Do I need to park this and focus
on other things? And you can only do it once, I
feel like, because I mean the conversation happens and yeah,
you can park it and have it again, but you have to move and
build trust with people and it. I feel like it takes a lot of
time and I I don't want to underestimate the time aspect
there. It takes unprecedented amount of
time, right? So what what I like doing
actually is start talking about bats.
So instead of saying like hey, how long does it take to build
this feature or this module or whatever it is, I see, let's
start with the smallest best we can and then we are going to
understand whether this is valuable for us to invest
further. Because what I want to move away
is from a classic project management aspect because it is
imprinted in many brains saying we need to estimate, see the
size of the effort and decide if it's worth or not.
I say how can we move from talking about the work and start
doing the work? Because the truth is, you only
understand something once you get hands on and once you get
users to do something, Even if there was research on all of
these and so on, I just say like, all right, so these are
the promising ideas. Let's not go all in.
Let's name what needs to happen so we can go all in.
In other words, what are the assumptions?
What are we assuming to happen here?
Then we run experiments. I give you an example.
When I was in one of the places there, we were trying to help
car owners find their cars, sell their cars and we connect with
dealers, car dealers all over Brazil.
And these car dealers, they would play speeds and so on.
And we said they are missing the auctions, the car dealers.
So of course we don't get a good offer in the end because they
just don't attend the auctions. Said what if we build a bot and
they can't just set up the bot and say, hey, I want this car on
these parameters. Whenever this car is in an
auction, you can go as high as that.
So it would be a bot just placing bids, sounds, sounds
nice. And we had talked to some of the
dealers and they were interested in that said, but building this
is something quite complicated. And then we said what if instead
of building a product, we become the product?
And I said, what if we just say, let's call a few dealers and
say, do you want to participate in this program?
Give me the parameters and I'm going to put that in a
spreadsheet and then I'm going to do that and see how it feels.
So actually, we became the product before building the
product and we realized that half of our assumptions were
incorrect and there were way more things that we would have
to consider before building that.
And in the end, we dropped the idea.
It was way more complex than necessary.
The only thing the car dealers needed was a good way of knowing
a few hours in advance when the car they wanted would be an
auction. They would have to attend the
auction, but we just need to notify them timely.
That was what we realised with this test of becoming the
product which is the classic concierge model.
So we placed the bet there. We did invest two weeks on this
setting up and so on. We didn't build the product, but
that created loads of learning so we could do something that
actually was worth building. Yeah, that's incredible.
I and I really realized this when talking to people or
potential stakeholders or even sponsors.
People love going to the most complex vision they have in.
I mean at some point I I'm working on an expert now and we
have to have a lot of data visualization and the idea was
there that we just make a huge Configurator and people can
toggle on and off what they want in visualizations and so on so
forth. And I was like OK to get to a
point where this actually delivers value like we're going
to be months ahead and we don't even know if this is one of our
most important features yet or if this this just the one off or
if this is actually going to be used.
So I'm really in in those I mean and I leverage definitely
engineering experience because I hate building things that don't
actually provide value. I want to simplify and simplify
and deliver the bare minimum and then actually test all the
assumptions I can with real users.
That's really driven a lot of my conversations and that's more
from experience and kind of gut feeling.
And I'm wondering if I rolled into this either from a business
analyst background or not, with an engineering background, not
having been part of a team, could I have those same
conversations and with that same confidence?
Because I feel like guidance and mentorship is going to be huge
in a team success and especially when you talk about the product
there. And I don't know how I would see
that from an organization, let's say outward facing in.
If I look at organizations, I can see they deliver features or
value or products, but I don't know what goes on behind the
scenes or if product management is up to par on what I believe
it needs to be to drive value. Where have you kind of find that
gown? It's because talking about your
story from bullshit management to product management, you said
I was doing bullshit management and then I found someone that
actually knew kind of what the bullshit was and how to move
away from that. It feels like you kind of rolled
into that, but is it something you can perceive from an outside
point of view in where the management or when the
mentorship and guidance is? Sure.
So this is something I wrote a lot in my book on trapping
product teams. It starts with stepping back and
understanding reality. So what is reality?
And I start by the overall picture.
Are we working on a coordinative model or collaborative?
And coordinative is the very classic one.
You talk a lot about the work and you hand over things to the
others, and it's a very classic thing because if things go
wrong, you know who to blame. In a collaborative way, it is
more like you involve stakeholders, you don't manage
them and with the team you figure out potential solutions
together and you test them and you drop the bad ones and it's
fine. It is a different way of
working. So the very first thing is
understanding the the differences and then you'll see
what is happening in your scenario.
So you can use some guidance on that.
In one of the parts of the book I say about remaining untrapped
and remaining untrapped is what I I mentioned.
Like you step back and look at your company aspect, what does
success look like? Who is involved?
Where do you have a product person in the executive team?
Because if you don't things will be a bit different.
So then I I give there some orientation.
It's kind of you first need to understand the cards you have
and then play the game with those cards.
Because the other alternative is you just fold and you don't play
the game, but that you will fall into the victim of the
circumstance. But you can be different.
You can be the hero of the story, and to be the hero of the
story you understand the available cards and say what is
the best move I can do right now.
And generally there is one move that anyone can do.
Even if you are totally trapped, you have no strategy.
Because strategy for me is not something complex, it's
something that we talked here. It's about simplifying decision
making. So you remove the confusion and
the team can make decision. But you you will realize that
maybe you are in a situation that it's confusing and you
receive features and the road maps and so on, and you cannot
change everything from day one. But one thing is understanding
where to start and most probably it is the assumption.
So you can say, all right, we're building this feature, what do
we assume to happen and how can we test that as fast as possible
so we understand if we're doing something that matters or we are
actually fooling ourselves. And then you share results with
stakeholders and say, hey, I just test this and this is what
I learned. What should we do now?
So then you start bringing more ingredients and involving them
instead of managing them. So this is the kind of thing I
see about people starting the product management, like
understand the game, the big picture, see what is going on
there and where you're going to act.
But one thing is you cannot change everything from day one.
Just start playing the game and I say it's very classic.
Thing is you meet the company where they are, not where you
want them to be. Because you may read some books
which are great, like inspired by Marty Kagan, but then you
feel powerless because you are not going to see most of the
things there. That's the truth.
But it still can have some fun. If you are open to say, let me
just arrive here, see how it is and maybe try one or another
thing different and share with others.
Yeah, I like. I mean, that's where the fun is
for me. It's getting people on board
starting as small as possible and actually testing assumptions
and delivering value. It's something I I found
fulfilment in from the software engineering side and then with
the more hands on work. But now I'm more high over and
driving values differently and people know where to find me
also. So then time management all of a
sudden because something I have to more consciously work on
because from a software engineering point of view, I
mean I didn't have to have many stakeholder conversations, I
could drive them. I could be like, this is not
clear, Talk to the PM, talk to actually the people that are
either users or are domain experts in that way.
But not from the PM side. People just love sending in
calendar invites randomly, people I don't even know.
And from my side, I mean, I'm only there even four days a week
and my agenda, even with the podcast is a bit fragmented.
So I have no trouble saying no. But I feel like if you're very
fresh in the game and you want to please kind of the people
that you're working with or you have that mindset of it's more
coordinated instead of collaborative, then it's very
easy to just be in meetings and have dialogues and not actually
make change in that way. And other people will manage
your time, I think, for you. Yes, so that goes.
And one of the bullshit management I say is like you
become a victim of your calendar.
So your calendar defines what you do, not you.
So there are some hecks you can do.
So you start putting blockers. You say I'm going to block this
time to do some work and you don't need to just find the
blocker. And also I I create some rules
for for invitation if I don't know the goal of the meeting.
I I asked a person like what are we trying to achieve here and
why am I necessary for that. And if the person doesn't give
me an answer, I say, hey, I'm very sorry, but I cannot attend
something that I don't know how I'm going to deliver value in
this session. So help me understand that.
So I haven't exchanged it, but it's very important to take
control of your calendar. So I said blockers every day, so
I don't have meetings before 10:00 AM, for example.
And there's a reason because I am more productive in the
morning. So I want to ensure I have that
first one and a half hour of the day focus on doing things that
are important to me. So I look at what am I going to
achieve here and one of the aspects I tell associate product
managers, start your week with a goal and then look at your
calendar and understand how your meetings are contributing to
that goal drop the ones that don't.
So keep understanding that because if you don't take over,
you're going to be a people pleaser.
So, and if you try pleasing everyone, you end up very easily
pleasing no one. Yeah, yeah, for sure.
I think I don't have an issue saying no and I think that's
very strong. And the more I I hear you from
your side of the table, it's like saying no is one of the
biggest superpowers you can have.
And you need to do it both from a time management point of view,
but also to derive what needs to be done right and where the
value is. I feel like sometimes and this
might be a little bit of imposter, I'm like do I actually
know where to go? And then other times I'm like,
but I I shouldn't be the only one to figure out where to go.
Like I have people that help me either from the engineering side
or from the domain side or from the stakeholders and not in
managing, but instead collaboratively and figuring out
what the right way is. It's just, I feel like when you
come into an environment that is not like that, it's very easy to
then become the passenger like you mentioned and let someone
else be the driver. And that's very scary.
Yeah. Yeah, it is very scary.
But there is one advantage of arriving there very fresh.
You just need to know the ingredients, you know, so you
look there, where's the vision? And it doesn't need to be
something written in the wall or something fancy like as people
say, what does success look like in a few years?
What are we trying to achieve with this?
And see the story they share, Try understanding that.
Then look at about the strategy and then you see what is
happening there and within a fresh perspective, it's very
important, this fresh perspective of the first month
because then you can see where you can focus on because if you
just arrive and start getting things done, it's easy to move
from product manager to backlog manager.
So it is very connected to what you just mentioned, saying no
and saying yes, there's a balance there.
But to say no, you need to know what is the anchor because you
need to base your rejection to something anchoring on something
else. For example, how does this
contribute to go to go a or to our strategy?
And if it doesn't contribute to say, well then if it doesn't
contribute, I must say no. But if you are unaware of this
goal or strategy, how do you say no?
Because a very simple strategy I had in the beginning is like I
say no three times. Even if the person comes back
the 4th time, then I'm gonna listen for sure.
Not everyone would come back even the second time.
Only a few people would come back the third time and almost
nobody the 4th time, so I had way less things to take care of.
But then my boss got too many emails and I got a nickname, the
Business Blocker. That was not fun.
But my strategy of saying, oh, I was a poor one, So I change I I
start asking questions. That takes a little bit more
time. First you need to do your
homework. You arrive there, understand the
strategy, understand the vision. And then you start asking how
does this help us get closer to our vision?
How does this do that? And then you can also ask them
which evidence do you have supporting your claim.
And then you will realize that people don't have evidence and
they may say like, hey, the evidence I have is that I'm a
senior manager, that's evidence enough.
Then you will understand that actually maybe the ego got in
the room. It can happen and say, hey, I'm
not doubting your I'm not challenging your expertise, I'm
not challenging your title anything.
I know what you're asking makes sense, but to ensure I believe
the right thing, I need to understand where you are coming
from. So help me understand that.
I had situations like that once someone told me like you have to
change the way we present the delivery time and we had more
than 100,000 customers, I said all right, help me understand
this. And then I got this answer like
I'm a senior manager and I want you to change.
Oh, wow. I said I can do it, but it will
impact 100,000 users and they are quite sensitive to this
information. And then I asked one very
important question. Do you want to endanger our
conversion rate and a person look at me, no I don't.
Why do you say that? I said because I don't
understand what you're trying to achieve with this.
Help me understand. Then the person said, well, I
have a strong feeling said OK, a strong feeling, something
different. Said we we could do an AB test,
for example, We put the version you're saying compared to the
other for a small portion of our audience, and we see how it
behaves. We hack a solution here.
And then he said, all right, let's give it a try.
But the trick I use there is when you ask a question that
leads to a negative answer, people step back and reflect.
Because if I say like, do you want to succeed, everyone would
say yes. Why are you saying that?
But if you ask do you want to fail and then people.
No, no, no, no. Why?
You're talking about it so then you can move from like a top
down to a conversation. Because I asked, do you want to
endanger the conversion rate? And then they answered like
helped step back. And that's the key part of
however you arrive in a position like what can you find to help
people step back so you can move to a dialogue and then crack
course? Yeah, in the role of a product
management, is that also where you find most joy?
Because I like having those conversations and I like having
that also that part of the education and driving value in
that way. And I've never thought of, OK,
when is it time for me to leave the organization or leave the
environment? Because I like having fun in the
conversations where things are not as smooth of an operation,
but when it becomes a smooth operation and I've never
actually driven that, I don't know if it would be more boring
to me because you you're not going to have as many of those,
let's say, challenging and interesting conversations
anymore. What does your experience said
to you? When?
When was it time to, let's say, move on to the next challenge?
That's a great question. So what happened with me?
Like I moved to many places already and at some point I
would get through an interview and someone would ask me, hey,
you have worked already for 10 companies, What would guarantee
that you stay with us for a longer time?
And I said, I will be very transparent with you.
I will stay here as long as it's challenging enough for me and I
can drive value for you, for our customers.
And I will have fun. I can bring my best.
And the moment I don't have enough challenge, I will live.
And I say like the moment I start feeling that I become
obsolete because things are just turning around in a good way,
then I want the next one. Because the truth is, I like
fixing things. I like mass environment because
then you have work to do and that's what I enjoy and deliver
value. So I moved on several times when
things start getting rounded and we start moving around.
So other people would like more of that because it's more stable
and then you drive more value. But I like fixing kind of the
engine that drives value. And then once it's moving and I
became obsolete, I say, all right, time for the next one.
Yeah. Have you also been in an
environment where you're, let's say, working on this engine and
you're like, it's just not, it's just not getting done?
Yeah, because it's it's challenging, but it can also be
just blocking in every sense of the word.
I've been, yes. So there was a situation I had.
I had a strong feeling I had to move on.
So the company went in a layoff and what happened is 1/3 of the
employees left. That was already shocking
enough. But what became even more
complicated for me to digest is that product got murdered with
technology and the CPO was let go.
And then I had to report to the CTO and I had nothing against
the CTO. But for me, product and tech,
it's necessary to have a sustainable conflict because
tech wants to do this thing the the right way and product wants
to do the right thing. So you need to find some balance
there and one helping the other challenging.
So if there's too much power in one of the side, it can get like
derailed very easily. But I decided to stay there and
what happened is one of the things the CTO implemented was a
bug free policy. And I asked why do we need the
bug free policy. He said because we need to have
high code quality. I said I agree with that, but
some things we need actually to create very buggy, so we learn
if it works or not fast. And if we try building it right
from the beginning, it would take too long to learn.
And he said well it's better to build it right then it build it
wrong. And I said, well, I disagree
with that because my principle is first you build to learn,
then to scale. Because if you build something
to learn and you realize it doesn't work, you throw it away.
Yeah, Why scale? Yeah, so why scale?
But if you build something that actually you made it perfect
from the beginning, psychologically you don't want
to throw that away. Some could cost.
Yes. Then you want to keep that in
the product. So that start happening and then
I noticed one of the things happening within the product and
I told this the city 08, this is something we're not covering and
we do need to act on that and said I will take to the
management and I will see what they think.
But for me it's the most important now to pay our tech
debt off. I said, well, that's not sinking
our business but not keeping the current, the current customers.
It is because what I realized was something very dramatic just
in context, layoff of 1/3 of the employees.
So situation was already bad enough.
And what happened is our recurrent customers were
dropping. So it means we had a high churn
rate. And I said this is something we
need to work on and it's not about paying the tech that off
now. So I gave this feedback.
It was ignored. I gave it again, it was ignored.
So I realized that I was unempowered to change this game.
And then I said, hey, you're not listening to me.
And I didn't come here to be ignored.
So I'm going to leave. I will start searching for
something else. You actually told them.
Yes, I said I will start searching for something else, he
said. Well, your job is to ensure that
the team is working the right way.
I said no, that's not my job. It's to ensure that the team is
working on the right goal and how they're going to do it.
That's their job. And he said, well, I see
differently. I said that's the thing.
Me too. So I need to leave.
So I start searching for a new job, but I tried.
So my philosophy is sometimes you cannot change the game, no.
So you need to decide do you want to stay that that if you
want to stay, make peace with however it is and do your best.
I couldn't make peace with that, so I decided to move on.
Yeah, yeah, I can see that. That must have been a hard
decision though at at, I mean at some degree until you realize
that it's actually not going to work, right.
Different blood times don't mix that well.
And that realization of, I mean, the CTO just having a completely
different view of reality in a different environment.
He might have been right. But in that real environment, it
was challenging And at some point, yeah, there's not really
a a future path there then that's hard.
Yeah, So what happened for me was it was pure tech driven.
So I like the mixture and for me the balance is supposed to and
the one of the things of product, there is no right way
of doing product. There are different ways and as
you said bloodstream, some will make, some will not.
That was transparent. And I move on and I, I pick the
next challenge and it's a hard decision indeed.
I was thinking all right so am I.
It's a it's a funny thing because what happened is after I
decided to say that to the CTO, the CEO invited me for lunch and
he even told me, well, you know, a good person like when you are,
the ship is sinking. He told me, and we all know
that, but you should not jump the boat because it's sinking.
You should help us figure it out.
So that's what would be something very valuable to do a
turn around. I said yeah, but that's the
thing. I'm sharing many things and I'm
being ignored all the time. And I know some of my
suggestions got to your meeting and you ignored even that.
And I asked him like why did you accept focusing on paying the
technical debt off instead of figuring out how to reduce our
churn rate? And then he looked at me and
said I trust the CTOI said is he able to make this calls because
you remove the CPO who was able to make this call.
And he said, well, we don't have budget for that.
I said I understand. So that's why I said I am not
here just to be told what to do and I'm not here to be ignored
all the time. So it was hard.
I said I I'm very sorry, but I need to move on.
I I cannot stay in a place where I don't believe you know where
we are going because for me it seems anything but a big iceberg
we are going to hit very soon. And that happened.
The company went bankrupt a few years later.
Well, yeah, I was thinking to those conversations and
definitely early in my career, I would not look forward to those
conversations telling the CTO, you actually have a different
vision on how things work or asking the CEO, like, I know
some of the decisions went to your table and you kind of
ignored it or you chose this. Like, why is that?
Those are hard conversations where they can be confronting
only from the view of hierarchy, but also from the view of, I
mean, they're your colleagues, they're all C-Suite.
How have you learned to kind of manage those conversations?
Because from the way you're telling the story, you're very
confident. You're actually very direct also
and honest with them. And that's everything I want and
appreciate in people I work with.
But to get to a point where again that confidence is there,
I feel like you must have had a lot of conversations to kind of
build up that confidence there. I think it comes something from
from my dad. So my dad always told me, you
know, you can grow in life, you can do everything, but you need
to be humble. So no matter which job title you
have, in the end of the day, everyone in the in the company,
they are employees, they have a number, they are registered and
they're just numbers there everyone, even if they are on
the top level, you should treat everyone the same way.
And then I had this in mind and some places I work I remember
very high Oracle place. And when I started as a software
engineer, I asked loads of Y and I got my nickname as Mr. Y.
And what happened is one of the guys, he was a director, he was
super annoyed with my questions and he asked me who do you
report to? And I said wow, why does it
matter? He said no because I want to
have a conversation with your boss and I said all right.
But in general, if you are asking me who I report to, if
you want to have a conversation you can have with me.
So I asked him, like, do you have feedback to me?
He said, well, there are some decisions, they don't belong to
you and you are challenging those decisions.
I said I'm not challenging, I'm trying to understand and I know
they don't belong to me. But what belongs to me is to
ensure that I do something that helps this company become better
in some aspects. And sometimes I don't connect
the dots, so I want to understand that.
So what comes from this job? It's like I always perceive
someone as a person working there.
I don't look at job titles, so I treat everyone the same.
And I I know of course the CEO will be, he can call all the
shots. But for me, he is a person.
He has a family, probably. He has dreams, he has feelings.
So I say like I tried talking to everyone at the normal eye
level. So now for example, yes, I am in
AC level position but I have done a session with all
employees there and I talk normally, talk about life, talk
about things because in the end of the day we are all people on
planet Earth and why we may have job titles here may say but
we're people so let's talk like that And and I try finding
common grounds that's what I try saying like it's about
understand situation this conversation.
I had this with the CEO. The CEO wants the success of the
the company, no success. The job is on the line.
You're out. That's it.
I said I'm seeing the success in danger.
That was a common ground. And then I asked like why didn't
didn't you accept that? Why didn't you have a
conversation about it at least and you accept that The other
part, I wanted to understand the strategy behind it.
So I asked because nobody told me and some people, they are
afraid of this hierarchy. Am I going to get fired?
Is this going to happen to me? I just don't have this word
because life is too short to worry about these things.
Yeah, yeah, I love that, man. I mean, it's interesting to me
because a lot of people say that, but they don't come across
as humble as you are. And I've had conversations with
you before the show, even on the show, like, I can see that's
actually how you are. And I really admire that.
That's been that's really cool. I've really enjoyed this
conversation by the way. I think I'm definitely going to
re listen to it. There's lots of learnings here.
So I want to thank you for coming on and sharing.
Is there anything you still want to share before we round off?
Sure. Thanks for inviting me.
But what I don't want to share is like recently I wrote a book
and there are loads of books about product mail.
Oh yeah, yeah. So why another on earth?
And what came to my mind when I started writing this book is
based on our conversation here. People don't challenge the
other, maybe because of hierarchy, they fell prey to the
situation. And I wrote this book because
I'm normal like everyone else. I haven't worked in any of the
big fancy tech companies, Google, meta, or whatever else I
haven't. I worked only for the
underground companies, the ones nobody knows like most people.
But we also aim to make a living out of that.
So I said what are the challenge that the common people, common
product managers like me do face?
So I started writing this thing and then I called as untrapping
product teams. It's written from a product
manager perspective but it helps any product person.
I would say a product person for me, someone working the product.
And the message I want to leave to people is whenever you are
working on a product there will be challenge and you cannot
overcome them alone. And the core of The thing is
help the other see what you see. So you're going to see problems,
help the other see maybe you're the living loaders of feature
and you have no idea how that creates value.
What about creating a feature report and showing the result of
the other saying, hey, we created loads of feature over
the last 12 months. This report here shows that only
50% of the features are used. What should they do about it?
So move to a dialogue, a conversation.
So the core message I want to leave is just help the other see
what you see and talk. Forget about hierarchy and all
of this. Have a conversation because if
you have a genuine intention of helping, people will listen.
Yeah, absolutely. On that note, thank you so much
for listening. I'm going to put all David's
socials as well as the link to the book in the description
below. Check it out.
And with that being said, thanks again for listening.
We'll see you on the next one.