Untrapping Product Teams World Exclusive (With David Pereira)

I call bullshit management as an art, and it's an art to drain all of your energy and create no value. And it's your simple equation. The more bullshit you handle, the less value you create. But now now it comes the truth. When I started my journey as a product manager, I realized that I was actually doing more bullshit management than product management. But it took me a while to realize that. And now, let's be honest, you are going to handle a certain level of bullshit. Either you like it or not, but you should be aware of that so you don't spend all of your energy into that. And why am I talking about this? Because that's the reality. For example, gathering requirements. You meet the wants from business stakeholders. Without knowing the needs of customers, you go to a meeting marathon. Without connecting to the goals you're trying to achieve, you just blindly become a passenger of your calendar. Welcome to the Product Agility Podcast, The missing link between Agile and Product. The purpose of this podcast is to share practical tips, strategies and stories from world class thought leaders and practitioners. Why, I hear you ask? Well, I want to increase your knowledge and your motivation to experiment so that together we can create ever more successful products. My name is Ben Maynard and i'm your host. What has driven me for the last decade to bridge the gap between agility and product is a deep rooted belief that people and products evolving together can achieve mutual excellence. This is the Product Agility podcast with a very, very special interview. And what makes it special, I hear you ask? Well, it's because we are joined by a returning guest, David Pereira. I think I said that. Almost are better than the previous attempts anyway. So thank you for your potions here David, because David at long last has a book that is now out digitally. And this is the first podcast Dave has done since the launch of the book. And it's with great pleasure and a huge honor that is giving us some of his time to give us a little tour of the book, talk about some of the awesome materials that's in there and let you all know where you can go and get it at the end. So David, thank you very much for giving up this time. i'm so happy that you're here. Thank you for inviting me. i'm glad to be here. Yeah. I mean, this is a big moment for me. Like, i've read lots of your stuff. This book i've been so excited about and being privileged enough to have got my eyes on a copy of it, it has not let down this morning when I was reading for it. it's the first time i've properly paid attention to all of the amazing support you've got from some phenomenal names in our industry. i'd forgotten that Jim Highsmith had said yes, there was crazy, the amount of support. i'm very delighted. And you know, people invested a lot of time to help me make this book better. And I was so impressed on how generous they were. Like Jim, he reviewed my very first manuscript, gave massive feedback and really helped me improve this, Not only him but others as well. I think it speaks to the quality of the content. it's a very easy book to engage with. Your language of your use is fantastic. Yeah, I can hear that it's you. And yeah, to get such amazing, what is the four words? And to have just such lovely, quite see whether it's Mike Cohen as an example, as obviously Mike Cohen give his support to the book, but also for support to you in making this book a reality is just phenomenal. So i'm flattered and I feel like this is a very great opportunity for me to get you back on the podcast and to let the world know about your brilliant book. But anyway, for those of you that don't know, David, I mean, for those odd person or two that has never been on LinkedIn and note to anything product related, David, would you mind giving a bit of an introduction to yourself? Sure. So i'm David Pereira. I come from Brazil now, living in Germany, have been playing the product game for the last fifteen sixteen years or so. Worked initially as a soft engineer, then product manager, head of products and all other stuff. let's say I have learned many things that didn't work that well because I screwed up massively. Then I start sharing my knowledge so you can find a lot of my content and link it in on how not to do things. And sometimes I may tell you what you should be doing, but it's more about sharing experience. Yeah, that's what I do. And I have my newsletter called Untrapping Product Teams, which is also the title of my book, and it's all about helping people avoid the blows I had to take. Well that is a gallant crusade and more much I fully support. I like the fact you tell people about your mistakes and we talk about what what don't to do. That makes no sense, Ben, what you should not do, things you should avoid. So thank you very much Dave, for that introduction. And you mentioned untrapping product teams. This is your fingers untrapping. And we looked at the book and you look at the structure of it, it's in three very clear sections. Part one facing facing dangerous traps, Part two overcoming dangerous traps, and part three is remaining untrapped. let's say we thought that perhaps for this episode we could spend some time going through each of those different parts to give people some useful tips, some valuable advice, and also give people an idea for what they can expect in the book. So if we begin with part one facing dangerous traps, and perhaps just to make sure everyone 's working on a level playing field here, David, when we say traps, like what on earth are we talking about here? And it's something that we're going to face and we may not even see it, and that's going to hurt us. It boos low hours down and it will cause trouble. So the reason I started facing dangerous traps it is because no matter where I have worked I have seen things that got in the way of creating value and many times I tried to find what I should be doing. But then I realized that there were some things already in place slowing me down, and I see that we benefit most if we can remove the straps so we can walk. Without these issues ahead of us, it's yeah, it's interesting of your angle, particularly when you begin the book talking about simplifying things. I get a strong lean feeling from some of this at times, which is no bad thing at all, I would say. When we look at this first section and facing dangerous traps, one thing I was particularly interested in everything I particularly liked in here is when you spoke about different flows and when we think about product development, there are there are articulate two different flows. Could you tell us all a little bit then about what these flows are and I suppose the traps in relation to them? Sure. So in general I see that there are two ways of working. One I call is the coordinative development flow and the other the collaborative. And it's quite interesting because many people may associate the coordinative directly with a waterfall wish way of working. But that's not what I meant. Even if you work with Scrum, Kanban or Scrum or whatever, the question is how do you work when you are in a coordinative development flow? So to say it means you talk to many people before you get something done. There might be some approval part. A lot of the work is about coordinating and aligning before you even get hands on, and the collaborative is something different. It is more like focusing on the goal, What do we want to achieve? How do we move on right now? So everyone is on the same boat and the main difference is on active development flow. When something goes wrong, you know the one to blame. And very interesting also is things will go wrong. And what happens after that. In the collaborative you say what do we learn from that? We move on when we adapt and the coordinative, we go back and we do the same and we hope the next time will be better and say this is what I was wondering about. i'm just going to get to the page in the book because when you say when you've got coordinate coordinative development flow, I think when people look at that, Well, when I looked at that image, what you're not saying here is what has been said a thousand times before probably which is everyone should work together and we should be collaborative because what you're talking about is. is the how the flow of ideas gets narrowed down and how we figure out actually how do we get the bad ideas out quickly rather than just picking idea and then having to shake lots of hands to get it out is a fair summary it is because in the coordinative development flow what i say is We focus too much on the process. How do we get ideas out and most probably the organization we spend time within. One question, how can we accelerate delivery? Because it's assumed that the ideas are good. So you take a long time deciding which ideas you work on and once you start working, you go from the beginning to the end. You carry ideas throughout each stage. I even say stage here because they are really separated phase. On the contrary, the collaborative flow spends time with another question. How fast can we drop the bad ideas? Because we know that most of our ideas will not survive reality. So we know that some ideas will not go throughout all the iterations. And here I even change the name. it's not about stage, it is about iteration. If the idea does not support our strategy, why should we bother with it? If the idea doesn't have any signs of desirability, why should we run experiments with that? So that's the kind of question we spend time with, which is an entirely different game. And when I look at the. Those images you have when we're looking at the coordinative flow, you have a a batch of ideas and someone 's plucking one out and then that's going into design and we're handing that idea over and over. And even if it ends up being a massive turd at the end, then we find out at the end we're not testing anything. we've we believe we've picked our winning horse and we're going to follow that through. what's different then with your collaborative development flow is that you introduce, well, you rename some of the stages, at least for the sake of kind of giving people an idea. what's in the book on the coordinative flow, it's ideas, design, user test, develop and launch. But then when we get to collaborative flow, we change that to ideas, evaluate, learn, experiment and as if they're quite significant differences. Would you save it in the collaborative development flow? Those stages that were mentioned before, do they disappear or are they just relabeled? Like how do you marry those together for the people that are listening? it's about where we put our energy. The first one, it's on the delivery. So that's the the biggest thing and what I try to avoid with the collaborative is the commitment escalation because the first one we put a lot of energy on the prioritization. It takes really a lot of time because we try to find the most promising idea and then what we do after we are going to create something high fidelity prototype most probably that stakeholders can approve, but there's no chance that actually users have seen. And when I go to the other part on the collaborative, it is more about how do we incrementally increase our investment. So it's a different way of working. So answering your question, some things do disappear because what I want on each stage is to decide do we want to invest further or should we just drop the idea. So when I say here for example looking at the evaluate phase, if you look at the image, all ideas will move to there and the only thing you want to do is to answer a few questions. How does IT support our product vision? How does IT support our product strategy? How does IT support our goal? And if they don't it don't bother. And this is an exercise of a few hours. Then after that, you move to another exercise where you try hitting that those ideas with reality. You see the angle is more like on the learning and testing our assumptions as fast as possible so we don't waste our energy. Yeah. This reminds of a conversation i've just had with Jeff Got Health and Dan north actually because we were talking about how do organizations that are large, how do they get themselves in a position where they can compete with the smaller product companies that are emerging. And one of the the big things that Jeff was talking about was that ability to learn and then to do something with what you're learning about, which is what we're saying here isn't it is actually we need to learn as we go and that's what we are able then to then do with what we've learned. Correct. And this is one of the reasons that I hand picked the forwarder for for my book we have Gene Highsmith and Ashmore. Why Jim Highsmith to relate to Agile and why Ash Mara to relate to Lean product development specifically? You said about Lean and one of the things that Ash says a lot on his books, Running lean and scaling Lean. Your unfair advantage is your speed of learning and that's what I try to convey. How fast are you learning and not speculating? Because if you stay in a room discussing things. You don't create knowledge, you create speculation. that's not what we want. Yeah, got me thinking because I always think that there's a like what you write about in the book, there's big parallels of lean. But then as a consequence, it's something that I spent many years kind of noodling around me, which is large scale scrum. And there's lots of similarities to that as well. But that's we can part that conversation. that's one for another day. One thing I would like to pick up just in part one in the book, and this is something which I think you are, well, this is whenever I hear this term bullshit, whatever I think of you, whatever I think of you, David, I think of bullshit in a nice way. Because I remember the conversations we were having over dinner, around self application and then were bullshit. And it's nice to see it in the book. But when we talk about bullshit management, is bullshit a trap? Or is bullshit something else? that's a big trap? So The thing is, I call bullshit management as an art, and it's an art to drain all of our energy and create no value. And it's your simple equation. The more bullshit you handle, the less value you create. But now now it comes the truth. When I started my journey as a product manager, I realized that I was actually doing more bullshit management than product management. But it took me a while to realize it. And now let's be honest, you are going to handle. Certain level of bullshit. Either you like it or not, but you should be aware of that so you don't spend all of your energy into that. And why am I talking about this? Because that's the reality. For example, gathering requirements, you meet the ones from business stakeholders. Without knowing the needs of customers, you go to a meeting marathon. Without connecting to the goals you're trying to achieve, you just blindly become a passenger of your calendar. I say like it's a kind of a calendar routine, a calendar driven routine, something like that. Another example, it is about opinion driven decisions. So what about evidence? Who is comparing that? No. Someone has an opinion and the opinion becomes a factor which goes through road map and boom. So yeah, so that's why I talk, let's say eloquently about bullshit management, because I think this is one of the biggest trap. Yeah, this by what you said about something you said that I call EDD ego driven development, yeah, which which I think is a big issue. Like, oh, eco belief in oneself blindly with no evidence, you know, and we just want to carry that on and that Linden leads to this explosion of bullshit management. Now we're clear on what that is and meeting marathons and being a passenger to your calendar. I love that. I think the the idea around just getting requirements from business stakeholders who are actually talking to their customers and really understanding their needs just leads to a load of turd at the end being produced. i'm thinking now that maybe we've got some idea, and I must say in the book, just to backtrack a little bit, you've got lots of interesting little tools as well. Whoever it's the bullshit management. Check whether it's that thing you did at the conference in Poland where you're asking people to gauge themselves and certain metrics. Actually, I think that the little tools and techniques that are in the book are really practically useful and things that people could piece together themselves to build some kind of unknown useful feedback mechanism within their own organizations. The choice of including those tools. Was that something you'd always intended to do, or was that something that came out through the process of writing the book? So when I had the idea of writing the book, I started trying different things in different ways. So I tried things through blogging, through LinkedIn, through conference workshop and then I start noticing. That some of the tools I brought there did help people because I wanted. When I say about facing dangerous traps, it means you need to help the other see what you're seeing. So I was thinking, which tools can do that? And then I tried out some things, and the bullshit management as an example, or the other one about helping you understand the status quo, which we talked in chapter. Two, about the growth and the fixed mindset. These tools aim to start a conversation. So very simple question, what are we doing today? let's just look at that. Are we getting a requirement? Are we having bloated backlogs? Are we having meeting marathon? And then we look at reality and we say is that where we want to stay? And then if the answer is a no and say what can we do differently? Pick one item and then have a conversation about it and try differently. So I mindfully put that in the book to foster conversation, collaboration and change. And before we move on to Part two if you were to list under your top top five traps, is that something you could do? Sure. I like doing things this spontaneously because then it comes the most important to my head. Yeah. So let's say that one of the not in order, but let's say the top five that comes to my mind is the opinion driven decision making. Why? Because this one ensures that we start creating things that are disconnected to reality, and it's very dangerous because the result is going to be pain everywhere. Another one. It is about the meeting marathon. We become a victim, so we just play the game. We kind of become robots and start going to work, attend meetings, and then we forget to do what we should be doing, which is figuring out what creates value and driving that. Another one that is quite dangerous is the bloated backlog, because when we have a focus of cultivating A backlog and so on, it will quickly become something very problematic to maintain because they expect if it is in the backlog there are expectations which will be unbearable. And then once we continue on this, the requirement gathering. This is one of the most complicated to escape because companies have been working with that for a while. But again, it is not about asking business. What they want to have in the product is understand what business want to drive so you can figure out what customers need and they will combine both. i'm not asking to ignore business, i'm asking to partner with them instead of trying to please them. And if I go to another trap, I would say it is the output focus. So more features does not mean more value and unfortunately many times people focus on that and often if you would remove a certain amount of features probably your product would become even better but that's often ignored. So your top five you had a opinion driven decision making, which is what I think is ego driven development. Sometimes meeting marathons, bloated backlogs, which equals unmet expectations, which I really like. That part there. The requirement gathering and the idea of the businesses you're partnering, not trying to please and output focus because more features does not mean more value. Yeah, love it. So now we've got those traps in our minds, Dave, but let's move on to Part two of the book which is overcoming traps and I leave it. There was a when we spoke about maybe certain parts of that chapter we could look at. You mentioned the ingredients. Yeah. Because I try associating a lot of product management with cooking. I like cooking. It doesn't mean that I am a good person cooking, but I try my best. And one of one of the things I notice, it's not only about the recipe, it is about the ingredients you have, but also about how you connect them, Your role as a chef and I say that a product manager or a product person is similar to that. You need to have the right ingredients and somehow use them. And when it comes to product management, there are certain ingredients that will help you and if you like one of them, it will be very hard for you to play the game. And when I say escaping the traps, you need to have some anchors. So it enables you to ask some questions and then you can go back to your anchor saying here's where we're going. For example, strategy, what is your strategy? And for me, strategy will include who you serve, why you serve them. And how do you differentiate? What is value and so on and where you are going? And the strategy for me has one simple thing, simplifying decision making. If you have a clear strategy, it means teams won't fall prey of analysis paralysis. But that's not enough for you to go directly to start creating a product. How do you play the game of discovery? So you need to connect discovery and delivery. Discovery. It is about uncovering what creates that, and delivery is about building what treats well. And then many people may think that is a waterfall ish thing. it's not one fuse the other and you can't tweak because this rattle should not be written in stone. But now it comes one thing very important. You need to recognize the ingredients you have and then use them to the best of your capabilities. Because sometimes people say if I don't have these ingredients I cannot play the game. I would say this is wrong. it's kind of which cards do you have in your game and then you decide the best move to do with your cards so that you can win the ones that are missing. Because I say for example if you look at your scenario, you don't have anything I just mentioned. You can always start by naming assumptions. We talked about opinion driven, we talked about the other scenarios and so on. If someone comes to you with a feature request and say I want you to put this in the product, you will ask like. What are we assuming to happen here? You will quickly realize you assume that someone 's going to use it and benefit from that and then return fed. So your name assumptions. You start testing and within that you can gain the discovery card, the experimentation card and then eventually you can gain the strategy. But Chapter two is about bringing perspectives, elaborate on the ingredients with stories and so on. So you will understand where you start and how you can change for the best. So when you say the ingredients are we talk, are we saying the ingredients of strategy, delivery and discovery? Yes, I would say these are the main ingredients and if we haven't got, we've never haven't got a strong hand in all three of votes. it's how we, how we play that hand to then give us some more cards overtime. Yeah. One of the things that happen in most companies, it's an extreme focus on delivery. You don't have the discovery card, You don't have the strategy. The strategy might be do whatever the stakeholders want. Or who shout us who shout. The one shouting the loudest is the one getting everything. Might be That is a strategy. So you have only the delivery and delivery. It is not about accelerating output, it is about accelerating value creation. So what can you do here? You can look at what is happening to your scenario. One of the things that happened in the delivery is phase part is the backlog. And then you say, oh, I have a gigantic backlog. One of the suggestions I have there is what about bringing some extreme backlog cleaning to your game? How extreme are we talking here, Con? Oh, let's talk about house, then let's talk about, let's say, your home. You have certain level of cleanings, right? So every day you wake up, you make your bed, you go to the toilet, you clean after yourself, you wash the dishes and so on. So you do that every day. And probably once a week or a few times a week, you remove the dust, you wipe the floors, you do these kind of things a little bit more serious and once you have a special visit, then you do a serious canal. In my case, it's when my mother. in law comes here or my mother Because they will find us in place. I didn't even know they exist. But now if I ask you what happens if we stop doing the daily cleaning? So probably your home discussing right now. let's go to the product backlog. What would be daily cleaning? Daily cleaning. It is about asking questions before you put something in. So how does this serve us? How does this contribute to our product strategy? doesn't support our vision. It doesn't go to the product backlog. What about the weekly cleaning? You remove the dust, right? In this case, you say what are the things we have not touched over the last three months? So let's get rid of that. Instead of making the backlog bigger, you make your trash bin bigger because the trash bin is your friend. So you keep throwing things there. And what is a special moment? A special moment is called road map, our partly plan and you define a goal and you say how does our backlog support our goal And if doesn't you remove everything that doesn't contribute to the goal. You only keep the one supporting the goal you have right now. So then you have an extreme backlog cleaning. So it is about the questions you ask before you put an item in the backlog. Frequently removing the dust and then ensure that the backlog is clean enough because for me, the backlog is like the home of the product. And if you take a position where you want to move forward, looking forward not move forward looking backward because if you do that it doesn't take long hit the wall yeah oh we've opened that we've been there driving whilst looking backwards he's got kids at heavy david i mean the amount of time in the car and my boys are like oh daddy what's this and i'm like i'm trying to drive the car not look behind me it reminds me of to have cars and this type of thing is that my friend bars voda was in the car with his sons coming back from a swimming lesson this was in singapore many years ago and they were stuck in a traffic jam and his son looked over to the other side of the freeway and the cars were just going by at speed and he was like daddy why are we going slow and they're going fast can we not just go on that side and go fast he thought that i was like well we could but we'd be going in the wrong direction and is that what you want and he's like if it means we can go fast yes and at that point boss said yeah and this is everything that's wrong with the way we try and create products we're so so it's such a desire to go fast we never check the direction yeah and i think this is what the great thing about your book is that you give lots of really practical ways for people to begin to understand that direction whether it's you know looking at verb discovery and delivery whether it's looking at things like lean canvas there's other tools that you can use and part two is full of again practical stuff that people can then use to help untrap themselves and around this day the backlog size i think is a wonderful one and and a reoccurring theme that we've had i think when we came on a podcast before we i think we mentioned this and i know there's a gentleman called dave bowie who's the CEO of a company called aha slides and they have a a big purge on the backlog maybe they don't do as much housekeeping as they should do but they do have those big cleans because they know they've actually a a good backlog is one which is is pretty pretty focused. Or more. we're actually trying to achieve one that that contains all the other stuff. So I know that people are probably listening to this. Oh yeah, that's great. But yeah, OK we end up with a bloated backlog and there's lots of expectations with that, and I need to get rid of things. But people are going to push back and complain about this. Like, how would you manage some of those conversations if people are pushing back on what you're trying to remove? There are different ways of doing this. You can start slowly. You can just archive. You say, let's just put it aside. let's not in front of us so these people would have less resistance. it's not my favorite, though. My favorite. It is about focusing on what your role as a product person is. Your role is to create value. It is not about creating unmet expectations. And one thing that happens is the power of prioritization generally is missing. So if you keep the backlog full of things, I know you can tell me that Jira, Asana or whatever do you're using has unlimited space. let's just put to the bottom. But you know what happens if it is there. People have expectations. And if it is there, you need to refine. And it turns out that the product evolves and then things that you refined maybe three months ago, it means you need to refine again and you can all work on that. And probably they lack context and they are outdated right now. So it's about choosing where you want to suffer. So do you want to have a conflict that is unavoidable right now and then just solve it, which is called prioritization, where we go? Then you just do your backlog cleaning. Do you want to have the the conflict later which is related to the same thing but then they will say well it's in the backlog, you haven't delivered anything and it's always there for nine months and there's nothing. So if it's not there then you don't have these expectations. So it's important to have the hard conversations as fast as possible. There are different ways. I one of the my recommendations there in the book situation I had in Brazil, we we lacked a vision and we had loaded of requests. So I tried to understand what was the biggest problem we had back then. And the biggest problem was very clear, every customer coming in wouldn't stay longer with us. So it means our acquisition cost was lower than the customer lifetime value. So we would not survive in the long run for turn on. But I had requests from accounting, from finance, from operations, customer service, legal and so on. And everyone told me that everything was urgent. And you know what I did? I got everyone in the room and I wrote what I just said. We pay for the customers. And they just leave us. How are you going to solve it? And then I wrote this and I said, I have at least five requests from each one of you here in this room. There were five people in the room that day. I said, I don't know where to start if you don't support me. So let's evaluate where we can go Then one of the stakeholders said, based on what you wrote, my requests are irrelevant, just disconcidered them. But there were three stakeholders very passionate about their requests. Funny enough, they started discussing among themselves who has the most important request. And one of the guys from customer service said I cannot handle this amount of requests. And that's the reason that customers are pissed off because we don't solve their problems fast enough. And operation said you will never solve that problem fast enough if we keep delaying shipping. We need to fix the problem with shipping, then you will reduce your requests. So we need to adopt to address the root cause, not the symptoms. And that was an interesting conversation. So we had a better conversation there. And then the director of operation said, so here is where we go, that's what we're going to do first and the others, So how do you do it? Your scenario is will arrive from the ones I mentioned. But the most important thing you need to build align, it's not about building the backlog, it is about building alignment. And then you focus on that thing. The others you need to remove because one of the biggest challenge of being a product person is how do you do your work when everyone else is distracting you? Only if you can remove the distractions. When you were talking there, I was wondering there's some things here which if you wanted to you could measure things like that about the number of customer requests and the speed to get things out there. And then your book there is a part which talks about met other in what are the biggest takeaways of it. You can people expect then from this segment on metrics. In Part two It is about defining what success looks like and use that throughout your. Product journey, so to say. that's what I say. So for example, one of the aspects about measuring value is who is measuring. Many people expect only the product manager to measure. I expect everyone to measure. The product manager is automatically accountable for that, but not the only one measuring. And another aspect about metrics is stories. it's not about creating the dashboard. So you may have a dashboard with all the metrics and then a US your stakeholders have a look at this and we are all fine. No. What is this story when trying to tell behind the metrics and why them? And another aspect is i'm not telling people which metrics to use it. I do give some hints on potential metrics there, but the most important is the lining on the ones you are going to focus on. I explored there in the metrics different, let's say levels. There are laggards, there are leading metrics and input and output. Because one of the aspect is if you say I want to increase revenue, join the club, everyone wants to increase revenue. But how do you measure that? This is a laggard matter. It takes too long for you to realize you missed your part of the revenue O the question is. What do you need to achieve to reach that? That would be our leading metric. And then when you look at leading metric, it's important to understand if you have control or influence over that. And this is a concept I borrowed from Working Backwards, which was a book written by some guys from Amazon. And in this Working Backward what sounds like it when it's an input metric you have control over. For example, one of the place I worked, we had a problem with conversion rate. It was a massive problem and we wanted to improve the search. There are many ways of improving the search, but what can we control? We control the results with display, but we cannot control what people decide to do with that result. So instead for the first thing we focus on the search conversion. Then we started creating hypothesis. We said if we would show the high runners first, people probably will convert. So we started refactoring our search results to focus on the high runners first, and within that we could see a better conversion. An output metric. So this is what we talked there about developing A mindset that help people understand different metrics and understand what kind of metrics are you focusing on and how you can deal with that. Because i'm not demonizing laggard metrics, I would say I rather prefer having a road map with laggard metrics because from there we can work on the leading metrics and so on. But if if the metric is delivering a feature on time, well, you have only one chance of succeeding the feature on time. What is the feature is wrong, then everyone fails. Yeah. So yeah, start with the, you know, having a road back which is focusing on some of those lagging metrics. At least you know where you're going. And then you can begin to say, OK well, how do we know? How do we build our confidence to know that we're getting there? Those are your leading metrics. And then when we look at all of Part two about overcoming these traps and what we've got here is some good product management tools and techniques, artifacts, some ideas around strategy and measurement and really to help make sure that we can not, I suppose, avoid the traps and also get out of there. So we say over. Yeah so it is overcoming. But there's also a big thing here around avoidance affording into some of these traps for sure correct. And one important thing about Part two is I bring many techniques that are not from me but techniques that I have been using for a while. Because coming from I have tried many different frameworks and not everything helped me. So what I tried to bring in Part two are the techniques and methods that did help me over the way and what I I did differently, how I combined them. Some things I tweaked, some things I adapted here and adapt there and that's what I share in the book. So most of the things are from other authors like there is a Jeff Patton, Ash, Maria and so on. But some things are for me. So the way I organize there, how we structure the product team, but it's about showing you how you can create digital products. And what I tried is following the core of the book, simplify the unintended complexity. Sometimes we think about how can we add something. And in this part, I also say what you can do differently, what you can remove and what you should be achieving instead of what you should be doing. And I say it's that idea of unintended versus necessary complexity. Yeah. So there's some complexity which is necessary in order for us to operate, but some of it is unintended because we never designed it in that way. It gradually emerged. And then we, I said, always accept it as a status quo. And what we've got here in Part two is some ways to challenge that. That status quo help create a new paradigm and a new way for people to view the product and take different types of action. And let's say that we've done that. we've achieved it. we've overcome the traps. How do we remain untrapped, David, which is part three of them? Sure. Before I jump into that one thing you said that's very interesting, many times it's on the floor just doing things. And this is where I ask people to step back and say, how does this contribute to value creation? And now it comes the bad news. If you don't know how to answer that, big chance you're doing bullshit management because you fell prey of something that is distracting you from creating value. So that is one of the core part. If you don't know why you are doing what you're doing and how that connects to value is an opportunity to decide if you want to keep that, if that helps you, which relates to your question of remaining on trap. Because of the part of remaining on trap, one of the key things is the product game is complex and how do you ensure that you are delivering value at the best capacity of the team. it's not by applying all the things I mentioned on Chapter two that will help you, but it's about monitoring key aspects. Are they happening? For example, are teams in power to make decision? Are teams deciding what to do in order to achieve results? Are they just meeting deadlines? So what I did in chapters from eleven to fifteen something like that. It is about. Equiing people to step back and look at the status quo and say there is something here we could do differently. O it's helping you see where you need to act. Because if you just sit down and relax, the traps would just come back and they get you. Yeah, it's annoying, isn't it? I suppose the moment you take your foot off the gas, you, you look back to see what the kids want to show you. Before you know it, you've ended up in a similar place to where before you were before, and you've kind of gone right into one of those traps. Yeah. So there's a section here. Yeah. Which is Chapter twelve around principles. And this is a slightly tangential thing, and it's maybe, I don't know if you're comfortable answering this or not, but how would you describe what a principle is just like generically? Because I know we have the agile principles and people talk about doing things in principle, and I think that we have an odd relationship with the word principle. So i'd love to know how you would define what a principle is. there's an interesting question. I would say principle is the root of our behaviour, so we put attention on what truly matters. For me, principle is something about helping us make decisions that contribute to what is essential. Something like that. Yeah. Now I like that it's there was a quote by Said Petal D Hawk, who was the gentleman who created Visa in his great book that Building the Chaotic Organization. I can't remember the name of it exactly, but he says that principles are what ought to be. Yeah, that's an interesting definition. And I just thought, I know it's stuff, we believe it and we can see it, but yes, that's it. We know that's how it ought to be, but we also know that it's something that we have to keep striving for and try and and try and get there. Otherwise, we just, you know, we just won't be able to probably because principles should be hard and there should be a challenge and there should be something, I would say in most instances which isn't coming naturally to us, maybe in a product perspective, it has to be some of which are challenging us. Otherwise we're just turning up and doing our job. we're not putting the Fort. we're not stretching ourselves. Yeah, that's correct. And I try to set the principles in different levels to make it strategy, collaboration, discovery and delivery. And one of the principles I always notice that people struggle with it is about first beauty learn, then to scale. Core part of this like these are the principles that have helped me in my scenarios. In my challenge, I do encourage people to reflect on what helped them. I do share my principles and I don't say you have to blindly follow my principles. What I say is you can use them if it helps you, but you can tweak to your necessity. I don't say that my principles are the truth, but this example here first build to learn them to scale. Why do I say this is very important to me? Because most place I see there's a lot of discussion on how do we build this right, how to ensure this is scalable, maintainable, and then software engineers want to build something perfect from the beginning, just you realize once you put in the product, actually it doesn't matter if you have ninety eight percent of test coverage if nobody 's going to use that. So the very first version of whatever you are trying to just enable you to test if the users understand how to use it, if delivers value for them, and then you can lately increase the reach and so on. I like saying something that software engineers hate. I encourage deliberate use of technical debt. Yes, you reduce the test cover to the bare minimal and you hack something that you're not proud of, but you can't expose your audience, the small part of your audience, not a hundred percent as fast as possible, so you test it. So that's why I say first you build, then she scale. Because if you learn that this is worthless. you're putting the trash. Yeah. It reminds me of, I don't think it was you. I think it was lady called Tara Wellington, who we've had in the podcast before, and Taras. Yeah, phenomenal. she's coming back on the podcast soon, actually. i'm very much looking forward to it, I think it is, Tara said. The first version of your product should always be the worst. Yes. And I was. And and I thought, oh, actually do. it's one of those statements. he's like, well, hold on a minute. Let me think about that actually. Will that make sense? Because you're building to learn the first version of it holistically. it's probably going to be the worst version. And the if you're learning, then you can make it better. And if you're not making it better, then what the hell are you doing? How much of it is us getting over the, you know, this ridiculous notion we have of release, having this perfect product to begin with? I think it's Yeah, but I also think it's a challenge, right? Because those people that are trying to support people in the roles of creation, discovery, whatever, whatever it may be, who haven't actually done it, who haven't had skin in the game of doing it, I think it's hard to really understand what it's like for people. You know, we can throw out some of this advice, and if you haven't ever done it, then you don't really understand actually, how bloody difficult it is to really prioritize something and accept that you might have to redo it. it's gonna be some rework, but you need to get something up to test. And I think that's what kind of comes out fantastically in your book and always in conversations with you. it's just how much of this is based on experience. Is there any part of the book? Maybe this is a rubbish question, I don't know, but is there any part of the book where you wrote about something that you haven't done but you felt like it was just really good advice that you wanted to share with people thinking very out loud here? The book is purely based on everything that I done and have tested. there's nothing there. I have not tried and used or failed. So let's say it is a summer of my experience. So this book relates pretty much to everything I have done in the product sphere. It doesn't mean that I did everything in the same company or some same place. It means that I did that throughout my journey of sixteen years now and try differently. there's no really advice with things that I didn't do. There are some things indeed that I connect there. I didn't know this technique, but if I had a chance of using that in this scenario, that's how I would do. But I used this technique in the different scenarios. But to make it easier, as I was walking through some examples, I used that in an hypothetical scenario. So in a way, is this book like your resume? it's like your CV I would say it is my make CV Sorry, that just tickles me. It tickles me. So I never considered. If you are recounting your experience and it is, yeah, it must have been quite a cathartic process writing the book. Then if you're able to kind of put all these different experiences and reflect as you went, sure, it was a different experience. So I knew the three parts I wanted to to write. That is one of the few things that didn't change from the very first manuscript. But how I structure that definitely it changed. So how can I help people with this book? Because it's based on my stories and what I have seen. it's not based on the truth. It is my truth that might resonate with other people. So I tried to take lessons. For example, one of the things I introduced, which you probably have seen, is the untrapping lesson. So I share several stories there. I think there are more than thirty stories, so there are thirty untrapping lessons. So every story has one sentence that gives the core of everything. What is the lesson there? So I shared many and many things of that. To help people create value faster. that's it's all about helping people drive value faster when the job is very misunderstood. I think like if you ask what is the job of a product professional? You see i'm not even saying product manager, product owner, product lead. What is the job of a product professional? Even if you try naming product manager, I think if you ask ten people you get ten different answers. If you ask the same ten people a month later, you'll probably get ten different answers again. So you talk about the i'm trapping lessons and what really jumped out to me which i've I just it's it's a problem when organisations get large i've always found which is a product to tech being complementary to each other. One should not report to the other. And I think that is a really hard one for people to get their heads around a little bit when when you're in an organization that has probably relabeled one function as product and that function always controls the budget and make. But and I take reporting into quite broadly, but you end up in this supply and demand model where the products are demanding stuff and then you have to supply it. So you end up putting contracts in place to make sure that and that contract can be requirements talking as an example, which is reading all your time doing bullshit management. And I think that is really a great untrapping lesson. But there's something else on that page as well, which I feel could have been maybe an untrapping lesson, which is the farther the product is from top management, the more mediocre the product becomes. And I think that this kind of cognitive proximity, because I mean the whole essential hierarchies, reporting lines, etcetera, it's stuff we make up. it's all in our own heads. We could absolutely go and talk to the big boss. So maybe or yeah, or the big boss would come and talk to us. Or we absolutely could get our senior people with the customers looking at how the products being used. But because we've got this, these these constructs in our minds that put so much distance between the work. And the and the product or the customer and actually and the upper echelons or whatever it might be then added into the supply and demand product and tech kind of not being partners and and one, but actually being two separate functions. I think it just really can make it incredibly hard for people to escape some of the traps we've been talking about. What advice would you give to people if they find themselves in that situation where they're just like, wow, OK I like these. I understand everything you're saying here, man. But you know, I, i'm not sure what power i've got here. Yeah, that's one of the hardest part of working product because it's not black and white. So the situation matters a lot. But one thing that I realized throughout my life is you should do what is right, not what is easy. There will be many moments that you could do what is easy, just follow the flow, just stay in your bubble, don't talk to anyone. The example of the product person is far from leadership, is far from customer. Just go and talk to customers. Just get out, do something and then what do you get? You get evidence and then you can say, here's what I discovered because in reality is no one will blame someone from from trying to help. If you are trying to foster the business forward, you are, you're trying to bring some value and you are showing what you discovered. it's very unlikely someone will say, hey, that's not your job. I had several scenarios in my life already that I had to talk to customers and they didn't ask for permission. Sometimes I had to beg for forgiveness. It was not so well accepted. But I see that it's necessary for someone to do what is right because falling prey to the process just because the process there, as you said, you know, like all of this is just in our head, it's just imagination and so on. It doesn't really exist. I remember working in a place once I was challenging many things. it's what I was still a soft engineer and my nickname that there was mister Why Because I asked why all the time one high level management came to me and said like, who do you report to? I want to know who you answer to. And then he said this part who you answer to said, well, I answer to those who ask questions. So if you have a question, you ask and then I answer no, I want to know who is your manager, who you answered to. So it doesn't matter. i'm here to contribute to create value. This is what I discovered when I talked to the users and they are telling me this is happening and actually I saw that happening. So i'm just asking, why don't we address a problem that we know that happens? Instead of addressing problems that apparently we only think they happen, I bet you were very popular. Yeah, not everyone like me that much, I remember that. But it's funny that within this persistency and annoyance I always created, we got into conversations of prioritization and trying to understand what was worth our time and what was not. Yes. Sometimes I received the top down saying this is what you were going to do because the boss said so. But other times said, yeah, what you brought to the table is helpful. let's work on that. So it's knowing that sometimes you're going to lose the battle, but at least you brought what you learned to to the table and then you don't regret you didn't say something. Yeah, a lot of courage. Yeah, a lot of courage required to do it. David, we've been chatting for a long time actually. I lost track of where we were, which is awesome. it's been lovely to hear. You kind of pick out some of these highlights. It is a brilliant book and I think it should be on everyone 's bookshelf. It will be on mine because I like a physical copy of books. I will be purchasing it as soon as a print version becomes available. But the digital version is available now. I think it would have come out yesterday so May the first Where can people purchase digital copies of the book So it will be available Amazon Pearson. All the place can use in it from your favorite library. So it say you can check my website. D dot com and just see the untrapping product teams there. All the links are already available and you just choose. But I will give you a hint. If you go to Pearson it will be the cheapest. David, if there was one thing that you would hope people leave with after reading the book, what would you want people to take away? i'd say it is about helping the others see what you see. So there's no scenario that is perfect, but there are always many opportunities to show a genuine interest and helping. So how can you help the others see what they are not seeing? For example, if you are just delivering features, nobody cares, how do you help them see that? If no one is talking to customers with just having, let's say opinion driven road maps, help them see that and have an exchange and so on. So collaborate. This is what the card book all the book. It is one of the lessons that I have as an entrapping lesson. Help others see what you see and then go from there. Because as I said, if you have a genuine interest of helping, people will listen to you. What is important is don't come, empty hands, do your lesson, understand the scenario and bring a suggestion what you could do different. And don't say you need to change everything, just pick one thing at a time. that's what I talk a lot in the book. If you try changing everything at once, you get no support. But if you try one thing at a time and you can try small victories, then you gain some power to do more and more. And then eventually you can untrack your product teams. On that lovely note, we'll end it. As I said, David, thank you for coming. Everyone, thank you very much for listening. This has been a brilliant episode. If you listen to this and you love it, hop on LinkedIn or your social media platform of choice and let us know how much you love the book. Or let us know how much you love this episode, because we would love to know that. So yes, thank you everybody and we need to be back again next week.