From Bullsh*t Management to Product Management with David Pereira

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.