ProductiviTree: Cultivating Efficiency, Harvesting Joy

From BS to Better Solutions - David Pereira on Product Management – Ep27

• Santiago Tacoronte • Season 1 • Episode 27

Share episode

In this conversation, David Pereira discusses the critical distinctions between effective product management and what he terms 'BS management.' He emphasizes the importance of creating value, the pitfalls of traditional roadmaps, and the need for product managers to own outcomes rather than merely deliver features. The discussion also addresses the myths surrounding product management roles, the effectiveness of rituals, and the challenges posed by frameworks such as Agile. David shares personal experiences and actionable advice to help product teams enhance their practices and outcomes.

Takeaways

  • BS management drains energy without creating value.
  • A lean backlog is essential for effective product management.
  • Consensus-driven decisions often lead to poor outcomes.
  • Product roadmaps should focus on desired outcomes, not just tasks.
  • MVPs are often misunderstood and misapplied in practice.
  • Technical understanding is crucial for product managers.
  • Accountability for outcomes is essential for product teams.
  • Agile should be about adapting, not following strict rules.
  • User research should be continuous and goal-oriented.
  • Product teams should focus on initiatives rather than projects.

Thanks for listening to ProductiviTree! If you enjoyed this episode, please subscribe and share.

🟢 Spotify

🟣 Apple Podcasts

🟡 Amazon Music

🔴 YouTube

Connect with me:

Have questions or suggestions? Email us at info@santiagotacoronte.com

David, welcome to the Productivity Podcast. Thank you, I'm glad to be here. David, you've been working for years in product management. You're a legend, a guru of project management, and you're known for calling out BS in product management. What is it and what are the biggest trends in BS product management in the teams today? It's important to give a bit of context because sometimes when I call that people think that I'm pointing fingers. So let's start with the following. For many years I have been working with product and I had no idea how what I did created value. And then I had the realization that I was not doing product management because I was doing something else. And then I started saying like, I need to change that. But what is the name of what I'm doing now? Because it's anything but product management. then realized there were some things getting in the way. And then I was thinking, who is the antagonist of product management? And then I came up with the idea of bullshit management. That was the term. And how I define that is the art of doing things that create no value, but drain your energy. And why do I say that? If you're doing something and you have no idea how that drives value, there's a big chance. You know what you're doing, it's BS management. Can you give us a quick checklist? Something high level what separates a productive product manager from a performative one? Sure, we can start with the backlog. If you are trapped on the BS management, you're gonna have a bloated backlog with everything in and you have a hard time explaining how that will help you drive desired outcomes. But if you are doing real product management, your backlog will be lean, focused on what matters most right now. And real product management means that you dare to remove things that become outdated. So you don't keep them in the backlog for the sake of it. This is one aspect. Another aspect is how decisions are made. When it comes to the BS management, decisions are under made based on consensus, saying that everyone has to weigh in what they think, generally leading to opinion driven decision making. So you don't get the best option on the table. You get actually the worst because you're gonna... uh Deny, for example, expertise, evidence, because opinion will matter most. Whoever is in the room will make the decision. But solid product management will be like this. What do we know? And what is the best step forward? So you look at what you know and you move forward. So use evidence to progress. These are a few examples that happen. You've written that most teams build roadmaps, but not real products. What do mean by that? So the thing is, as humans stepping into the unknown is something we don't like because it's unpredictable. It makes us feel uncomfortable. We don't know what is going to happen tomorrow. For example, we arrive to work. What am I going to do today? And when I'm going to talk to my boss, what is the thing that we should be doing? It's hard to explain. So we come up with a roadmap. We know everyone is busy doing things, so they will be working on something. but then we don't know how that will create value and I say it's like placing all of your chips in one place so it's a bet all in so if it's fine what is in the roadmap everybody's happy then we deliver something of worth but we focus on creating something and the learning cycle is very long because we are gonna learn if something worked or not maybe three four months six months from now and that's too late And that's why I say you cannot create a product like that because you are just placing bats and very considerable bats. Product management would be like, all right, so where do we want to be? For example, you want to reach this part here. How do we get there? What is something we can do this week to learn next week and so on? And you gradually adapt so you get where you want. So the solution you may have foreseen in the beginning is something that will evolve and... transform into something completely different, because you'll learn fast. So are you saying that we need to kill roadmaps, shorten them? um And I fully agree with you. I've seen roadmaps with vision in five years and I look at them and I say, good luck if this will ever happen and good luck if this will bring any value to the product. Because at the pace that the society also changes, putting roadmaps with three years. So how do you build a roadmap that somehow meets the assurance of humans that we have a plan because it's all about the plan and how you balance it with building something that is valuable for So it depends a lot on the risk aversion of the place, let's say in the size of the company. I see generally two ways that could be helpful. My favorite way is setting the desired outcome. So your roadmap say like for this quarter, that's what we want to reach. For example, you want to let's take an e-commerce. Maybe you say we have a huge sign up and then once people sign up, they never get activated because they don't come back. We lose 50 % of them. So we want to start getting people activated and we can engage them. So you have this desired outcome. So you can work on that. You have no idea how you're going to do that. That's one example, but you have clarity on what you are supposed to achieve, then you can explore. This is one example, but that has a high level of uncertainty. Another one is if you take a big organization, You can say the area you would like to work. For example, what is most important for this year? You can say for this year it is expansion. So we want to explore different audience. So we're going to focus on this audience and we want to move from, for example, 0.5 % of our whole audience to this. We want to reach 5 % of them. That's our objective, a new audience and so on. It's expansion. So you know the area you would work, how you are going to... get there is you don't know, but the clarity you have is where you would work. And that's the difference I like sharing with people. And I also tell people we can have some bucket strategy. For example, in whatever quarter, you can dedicate maybe 70 to 80 % of your team's capacity to innovation, to something that you want to expand. And you can say there are maybe 20 % for keeping the lights on. There are things you just need to do it because it's necessary. There's new technology coming in and you have, for example, some code that we'll need refactoring for different reasons and so on. You can invest that time, but it's important to make it transparent. And I generally move from estimation to investment because it's a very different question. If you ask someone, how long does it take to do that? the person will immediately start thinking about implementing a solution. And if I ask a different question, what can we do in two weeks? Then people will start thinking what they can do to solve the problem in those two weeks. It's a very different mindset because you are going to think about what is essential while on the other one you think about like what do I need to do to implement the solution assuming the solution is the right thing. David, what is one myth about product management that you believe is actively harmful? One myth is that product managers need to feed soft engineers. So I think someone once said that product managers define the what and software engineers define the how. So that means you have to feed them with what they should achieve. Then there are some soft engineers that expect product managers to write, for example, precise backlog items. Sometimes even Amy, you have to write a minimum of five acceptance criteria and I'm going to do what is in the acceptance criteria. And if it's not there, I'm not going to do it because you didn't tell me to do. So this is very harmful for everybody. Let's talk about product rituals, daily stand-ups, retrospectives. Are they still useful or they have become a bit of a theatre? Generally they become a bit of a theater because they become mechanical. What I see as of now, our current state we are. It's beneficial to have a mix and match. For example, you don't need to do scrum by the book or shape up or any of that. Look at your scenario and say, what would help us move forward? That's the question you need to ask and then you decide what to do. Overall, I do think the teams will benefit from having a goal Time-bounded, short one. For example, what is your goal for this week? And then you can say, how do we organize ourselves to achieve this goal? That would lead to some rituals, but define a goal and then you can agree on something. So what I like doing, for example, I see the importance of a collaborative refinement. Why? Because the result should be a shared problem understanding. So you agree on what you want to solve. And then together the team can figure out how to get there. So I like having this. One thing that I don't like is any kind of planning by capacity. I don't like conversations, for example, last sprint we delivered 37 story points, what is our capacity for this sprint? I don't like that. I like starting like this. We have this goal for this week. What can we do to achieve this goal? It's a better conversation. I prefer this. And I still recommend, regardless of how teams work, to step back and reflect. That's a retrospective. I like having different types of retrospectives, so different things come to the table and the team will act. And why is that important? Let's say you skip retrospectives altogether. It takes about a quarter. Then the moment you have a retrospective, it's going to be a three, four hours retrospective because the team has so much they want to share, so many things that could have been addressed in the beginning, but they just piled up. I know many people will look and say, yeah, but the team should... talk during the day to day, share feedback and so on, but that doesn't happen naturally. Within some teams forming, they need some help, a room that they say like, this is the room where we will talk about the things that have helped us and things that haven't. And now we are going to figure out how to improve. So create this moment. So this is what I see as important, but I don't like the dogma, following strictly things and so on. So it's more about being adaptable. Let's point some fingers. I know you don't like it, but it's human nature. Who's more to blame for unproductive product culture? Is the PMs who avoid accountability? Or is that leadership that treats products like project management and use all leadership tactics? Where do we draw the line here? It's tricky question. I would say it's everyone to blame. So everyone will have part of the blame. Let's go back to my story. I said that I was no product manager when I started. I was a backlog manager at best. could blame leadership because they gave us, our product teams, roadmaps and we followed. So shame on them, I received that. But then I'm being the victim of this story here. Now let's look at a different scenario. I moved to another company, I received the same roadmap. I look at the roadmap, I start questioning. For example, what is that for? And then some people would not know that. Some people would know. And what I tried to do was to run an experiment. And then I ran an experiment, within the result I presented to leadership saying like, hey, I talked to 10 customers and the evidence is showing me that they actually don't need this. What should we do? Leadership was actually very curious about it. They said, okay, so if they don't need this, it might mean that we need to switch this priority. So I could have a conversation of changing. So it depends. So... there will be a lot of people to blame. And the question is, who is going to take action to change? David, em let's talk KPIs and OKRs. Are they being weaponized to justify bad decisions and avoid real outcomes? Well, it's a very interesting thing what happened. So many companies are used to work in a kind of projectized way. So they prioritize different ways and they get projects. Once they start working with OKRs, generally it's just a layer to the project they have been working. They will define objectives and then the key results will somehow lead to the projects they wanted to work anyway. So... That will not help the teams. It will be more or less the same with a different framework. But when teams are solid on that and they really agree on clear key results, they have the opportunity of doing that well. I know that OKRs can be powerful, but they can also distract teams. I already made mistakes with OKRs when I was a CEO because I set too many key results with the team and then we went on a divide and conquer situation. need to be mindful about this. When it comes to KPIs, they will help you understand what is going on and adapt course of action rapidly before it's too late. So I think teams would benefit from understanding this and so on. But it goes again to what I just said, someone needs to take the action. What's your take on MVPs today? Is Steam still doing minimum viable products or is it just minimum effort project? So today is a dangerous term. So MVP is misunderstood by most people. So generally in a product team, they will mean something that they can get out and test and then iterate fast. That's product teams would understand. But still many business people will convert an understanding of MVP to first version. So their expectation is very different and there will be people who want to, for example, avoid damaging the brand because you don't want to put something there that is lower than expected quality this to get people speaking about it. So I don't like using the term MVP anymore because it creates confusion. I like using the term actually a question. How do we know this is the right thing to do? And then I ask again, what can we do today to get some evidence and shows us that is the thing to do and then if people say like Today is not possible. We need more time. I say what can we do in a week? And I keep bumping that until I find an answer that I like. Generally somewhere between a week and two that we can get something that we can already start learning gradually and that leads to better conversation. So kind of I suggest teams doing an MVP without talking about MVP because then they will have better conversations. Should product managers be technical or just business experts? That's a question I get all the time. And my view is the following. Product managers need to understand how to connect the dots. So you need to know, for example, when a software engineer is talking about like cloud and talking about APIs and talking about queues and so on, you know how the box is connected. And then you can help them have better conversations. Why am I saying that? sometimes they're going to talk to the team and they will look at you and say, this is super complex, they will load you with terms and say, it's going to take three months to do it. If you lack the technical expertise, there's not much you can do there. So you will need to ask a few questions and so on. But one thing, once you have the technical expertise, you develop a nose for misunderstanding. So you realize there's something wrong there. I had a situation once, it was in Germany. I came to the team and I said, we have an issue in Australia and users there cannot access our application. It's taking too long for them. So we need to do something about it. And then software engineers talked and they came to me and said, is it going to take from two to three months to upgrade our infrastructure in AWS and so on, so it will be scalable there? And so I said, why is that? And I said, well, because it's super complex. They loaded me with Kubernetes terms and everything else and so on. I said, okay, let's go back to this. What is driving complexity? Break it down to me. What are the things you need to do that drive complexity of this aspect? And then someone said, the thing is about our CMS. Our CMS today is hosted in Frankfurt. And if you want to have editors in Australia adapting the CMS, that would be troublesome. I said, but I didn't say that we have trouble with editors. I said we had trouble with people accessing the result of what editors create. And then someone look at me and say, this is easy. I can just adapt something here. It's going to take about two or three hours only because it's a smaller thing that we need to do, not the big one. So that would help because then you have, you know, the questions you should ask. I am a technical person, I was a software engineer in the beginning, but today I tell product managers, get the minimum understand of your current infrastructure. How does it work? What does it do and how it connects? then you can talk better with soft engineers. Because if you are highly technical, it's a bit dangerous because then you will fall prey to the thing of feeding soft engineers. But now going back to the business acumen, that is mandatory. This is the part where it's not negotiable. Product manager needs to understand what creates value and why you are doing what you're doing. If you cannot explain that, it doesn't matter if you're technical or not. because this is the core of everything. I remember being part of a few trainings and there was one thing that stuck with me saying like, if there is one thing you have to do right is prioritization. Because if you prioritize incorrectly, it doesn't matter what you do after. You're just gonna work on the wrong things. So how do you prioritize? You can only prioritize well if you have business understanding. Should the product team own the business outcome or just the delivery? that's an interesting part. So I always vouch for owning the outcome. Who defines the outcome is a different question. In startups, I would say probably it will be a C level defining the outcome combined with the product team. The product team needs to have a buy-in, needs to be something realistic. In a bigger organization, might have some layers, but I would still hold the team accountable for the result. Because for example, if teams are shipping features, that's great. But how do they know those features are the right ones? How do they know the features are delivering value? They will know that once they start being accountable, because then they will find the time to measure results. If they are not accountable for that, that's the first thing they will chop from their daily doing. They have a lot to do. Big chance they have more things to do than capacity, and they need to reduce something. So I hold them accountable for outcomes because I want to ensure that they measure the result of whatever they do. David, it's agile as a password, killing real innovation. Yes, because the problem is like people start having wrong discussions. They start asking like, is this really scrum? Is this really Kanban? No, we are not doing Kanban, right? We need to adapt this. And then comes weird question. We work with Kanban. How do we do product discovery with Kanban? And say that's just the wrong question. Even talking about discovery, it's the wrong question. It's like, how do you... uncover what matters doing and then you figure out how to drive value. It doesn't matter the framework you work with. Once I had a conversation with Randy Silver, who is from Mind the Product, and he had the best definition of frameworks I've ever heard about it. He said frameworks serve two things, better communication, better decision making. If you're not getting both, either you stop using the framework or you adapt until you get both. And that's what I look at Agile. People start thinking, no, we need to do better refinement. We need to do better scrum. We need to do better sprint planning. And say, well, these are just rules for you to do things. And if I would talk about agile, it is all about adapting. It's inspecting and adapting. You look at what is happening. You say, am I getting the result I expect? No. Then let's adapt something. And then continuously doing that. And some people think that agile, you have no plan. And then it goes in a dog, no, I cannot see this plan. And even many people tell me, Dave, do you hate plan? Well, I don't hate plan. I hate following a plan that actually becomes the goal. And we don't even know what the goal is behind it anymore. So for me, a plan is a good starting point. So we agree where to land, where we are and how do we move further. And on the way we adapt, that's fine. So that's what is Agile all about. It's again, you can... Do MVP without talking about MVP and you can really do agile without talking about it. But the moment you try and convincing people, what I see as of now, many leaders are tired of agile. They feel like they were fooled. They didn't get to the results they wanted. They paid loads of money for trainers and consultancies to do agile transformation. And now they don't know what is the real result. When was a time where you also fell into BS product management and how did you get out of it? So I realized I was not a product manager once I failed an interview for booking.com. That was the realization. It was a bit funny because I had just got promoted to a senior product manager back then. I was still in Brazil and then I switched my LinkedIn to English and I started getting contact from companies from abroad and booking was one of them. I felt great about it. That's the reality. said, okay, that's proven that I am a great product manager. And I was feeling good about it. Then I had the interview. The first one, cultural fit was awesome and I was getting excited already. And the second one, the technical, was a disaster. Complete disaster. Like the first part of the interview was some things related to delivery and that's where I did well. But then it went to things I couldn't answer. I simply couldn't answer. I didn't know what the person was talking about. Then I looked at the hiring manager. I said, I know I'm not going to get the job. That's clear to me. But as we have still 15 more minutes, maybe you'll tell me what I'm missing. Then I'm going to go after that. And the person stopped and said, all right. So the thing is, you are very good at delivery, but you don't understand what experimentation is. Everything you talk about is getting something out of the door. The next one, the next one. But you don't talk about how do you ensure this is the right thing. You don't talk about how you uncover that and so on and so on. And that's the moment I realized I was missing probably 60 % of what product management is all about. then I thought I need to start doing things differently. And then I start trying doing things differently where I was and I did up to a certain extent until the company deployed something called Safe. So the company started using Safe and then I had a feeling I was locked in a box. I was a product owner. They defined me as a product owner back then. And I was a product manager before Safe and with Safe I was a product owner. And then I said, what is going on here? So on. And I realized that it wouldn't work anymore. So I said, I need to go to a startup road. I said, I need to do wild things now. I need to understand how things move. Because I was part of an organization. Initially, 5,000 people was acquired by a big one of 100,000 people and things got very, very different. And then I searched for a startup. And of course it happened that why would we hire you? You are a corporate guy. You have four years of experience working corporate road as a product manager. We don't see how you fit in the startup road. And then I said like, I need to do this. And I'm willing to take a pay cut, 20%, give me three months, I show you, I can do it, I learn fast, give me the chance. And then the person said, all right, you have the drive, you know what, I'm gonna give you the job and we are gonna see. But the person said, you don't have three months, you have six weeks, you don't prove me you can do the job in six weeks, that's it. I said, all right, fair enough, let's do it. So that's what happened. What is the most frustrating product meeting you've ever been in? Roadmaps tend to be quite frustrating. I had several frustrating meetings but if I would come to you honestly As I moved in the startup world far and so on, I remember having a meeting with investors in the room, C-level and nobody from product apart from me. And I felt it was 12 people against one. No matter what I said didn't matter and everyone had an opinion and I realized we were not doing product management at all. It was based on who had the highest influence and it became highly political what would make to the roadmap and beyond being political it became a fantasy world and I started telling them look I understand all of you have good intentions with all of these ideas. I don't doubt that. But let's look at reality. Over the last three quarters, there is no single team that delivered half of the things we put in the roadmap. Why are we doing this again? We're gonna end up with a roadmap with dozens of items we all know here, they're not gonna get delivered, and we will do this again in three months. I said, what is the sense in that? So it was very frustrating. Of course I didn't win this. We went again to all of this big roadmap and so on and so on But that was quite frustrating If you had to ban one word from product teams forever, what would it be? One word, I need to think a little bit more about it. The word that came to my mind was project. The reason is it is very hard to move to a product thinking if we talk about project. When we talk about project, it comes immediately, timeline, scope and effort. And when we think in timeline, scope and effort... We're gonna do project. That's what happens. I generally tell people, let's talk about initiatives, opportunities, anything else. And then we say like, how much we want to invest in this opportunity? How much do we want to invest in this initiative? And who should be involved here to get this initiative out of the door in a way that creates value? It's a better conversation. It's more like a product thinking. So coming into my mind, I would say project. It's a word I would ban. David, has there ever been a product you worked for that you loved, but it failed? I loved, but it failed. ah And what did you learn? So there was one actually, so it was in Brazil, we helped car owners sell their car in about an hour and we had several products there. had products for car dealers, so they would participate in auctions. We had products for our mechanics. They were part of a big system. But once we developed a product for those who were selling the car, and we created an app that they could see everything about what was happening with their car in the auction. And I love that because it increased transparency and they could see everything in real time and it was very beautiful. And it was nice, usability and so on. Once we put it live, I think it took about one week to get an average rating of two and half stars. And that's how it killed the product. and nobody else wanted to download. What did I learn there? I learned a very basic thing. You need to develop something that is natural for your user. So you need to understand what your user cares about and what is natural. And then you should understand the emotions behind it. And then you can move on. Why did it fail? It failed because We assumed that people wanted transparency, which they did. But we forgot that there is an emotional attachment to a car. And if you see someone pointing fingers to your baby car, that there's a defect here, there's another thing here, and so on, and so on, defensive immediately. People were not rating the product at all. They were rating the experience. And then I realized that we failed to do that. eh And that was a disaster, but it was a nice learning. Let's do a quick answer, rapid fire questions. Answer in 30 seconds. Let's do five of them. Number one, product roadmaps, strategic tool or outdated relic. It can be a strategic tool when used right if you focus on outcome, but most teams I know would be better off without it. How can they get together? Agree on a goal and stay behind the goal. And that's it. Number two, user research, a must have or is it overrated? The term user research will go into open-ended research without clarity on the goal. I don't like the term user research. I prefer continuous discovery, which the resators use a lot. I would say focus on that. Continuous talk to your user, but agree before on desired outcome. Then you figure out what would lead you to that. Three, one product metric to rule them all. Which one? Your North Star Matrix. Whatever you define. Yes, you need to define your North Star metric. Just ensure that it's something that keeps growing forever, then you can look at that. That's the most important thing. Airbnb nights booked the day, for example. Number four, product market fit, science or art. Art. Why? People are unpredictable. So you may do everything correctly and so on. And once you put in the market, you don't understand why it didn't fly. You can combine with science, but you need to have a bit of art there. And number five, what is the worst stakeholder behavior you've ever seen? telling the team you have to do that because look I am the CEO of this company and I want you to do that is putting the title in front of someone and saying that's why this is important. David, let's wrap up this interview with a couple of actionable advice. What is one high leverage change that every product team could make this week to drastically improve their output? So what they can do to drastically improve their output? The very first thing, it is about challenging what you are doing in terms of value creation. Look at what you're doing and name how it creates value. If you lack evidence, run a small experiment, product interview, product survey or whatever. Do that so you gain clarity if it's still worth pursuing. If not, you can have a better conversation with those who prioritized. And what's your advice to PMs and potentially POs who feel stuck in process bad want to actually build great products? Take action and talk about results. Most people hate being lectured. So if you come up with a great idea and you tell someone, is how we should be working, the default answer is no. People hate change. So think about what is the smaller thing you could do to create some result and talk about the result. Example, for I just mentioned, run an experiment, do something like this, look at your roadmap. Something doesn't work, you are doubting that. Try something out and then you talk about what you learned. That leads you change. David, you have written a book about product management. Where can people find it? The book is available on Amazon, Pearson and all other online libraries. It's called Untrapping Product Teams. And this book is not about telling you what you should do. It is all about hope. Giving you hope that you can act today for a better tomorrow. And what about getting in touch with you and knowing more about what you do on a day to day? can find me on LinkedIn, so David Pedeta, easy to find. You can also go to my website, d-pedeta.com, and then you can see what is going on there. I keep it very updated. And probably you're gonna find me in some conference worldwide. David, thank you so much for this advice, packed and very straightforward conversation. I am taking away that product management is evolving very quickly and there many teams still stuck with what the ideal of product management would be and that probably everyone, every product team needs to find their way. David, thanks a million for this time and we hope to talk to you soon.