#2 David Pereira - Untrapping Product Teams

Speaker A: Welcome to the Product Masterclass podcast. In today's episode we chat with David Pereira about his book Untrapping Product Teams. David shares how organizations can face reality, improve prioritization and shift from output driven to outcome driven product management. We also dive into balancing accountability, avoiding framework overload, the role of vision and mentorship in, in guiding teams. David also shares practical tips. This is one of my favorite, like adding a trash column to Roadmaps. And reflects his unique experience writing while traveling. Tune in to learn how to keep your product teams focused, flexible and most importantly, untracked. I'm super excited that we have um, someone with uh, us today that can uh, be here in person because he's also from Munich. Give a warm applause in the chat, uh, for David Pereira.

Speaker B: Glad to be here and in person. Very different.

Speaker A: It's very different, isn't it? I mean we, we hardly ever do these uh, things anymore. In the beginning we had like a lot of these events with Thomas and me sitting on the couch. But um, I mean to be honest, remote is a lot easier usually. So, um, yeah. Why are we here today? So David wrote this wonderful book and as you can see, um, I have not only read it, but marked it extensively. Um, which is uh, not only for the purpose of the event, but because there were some things and quotes in there, um, that I really, really enjoyed. Um, about the book.

Speaker B: Book. That's cool.

Speaker A: Um, in any case, I think David, David doesn't really need any, any proper introduction anymore. But I, um, I wanted to share a personal story of how, how uh, we met. So I think I just looked it up today. So I think the first time we Talked was in March 22nd.

Speaker B: Mhm.

Speaker A: Um, and it was basically like a, like a lunch meeting at, at 12, I think. Like a remote lunch meeting. And at the time you were head of product at Virtual Identity, right? Yeah.

Speaker B: Yeah.

Speaker A: So, um, uh, maybe a bit of context that it was um, basically an agency building products and you were the head of product, um, and you were basically responsible for the product side of things for all the products you were building for clients.

Speaker B: Right? Correct. Yeah.

Speaker A: And David told me one story. So we were talking and he told me that story about how we looked at um, basically requirements that were in a contract, I don't know if you can remember. And um, he said to me, look, I looked at the requirements and I figured that's not really what they need. So instead of just like building it for them, I went to the client and I basically talked to them about, hey, we can either build exactly what's in the contract, or we can just kind of get to a point where you build something that you can actually use and that actually makes sense. And it's. I think that was the point in time where I thought, wow, it's not like he's not only posting, uh, interesting stuff on LinkedIn, but he's actually putting um, his action where his mouth is. And uh, yeah, that's why I'm super happy, uh, to have him here today.

Speaker B: Thank you. I remember that story. The reason I joined Virtual Identity was to help moving from project to product. And then when I look at the contracts, they were project, all of them. Although we said we were building products, uh, and customers would say, I know what we have to do, and all the same story all the time. And I generally say it's better to regret saying something than to regret staying quiet. And I just said what came to my mind and I had a conversation. And at the agency you are in a tight spot because you have the contract and um, the client is the one calling the shot. And I said, you are going to make the decision. I'm just going to bring you the options. And here's my favorite. If you want the order, I can do. I don't recommend. Have seen that, kind of done that, being there, got several T shirts. Doesn't work. But, uh, yeah, that's how it was my life in the agency world.

Speaker A: I really love that. And by the way, um, during the event, if you have any questions for, for David, just uh, as always put them into the chat and we can bring them on stage also if you like, uh, tell us from where you are joining. That's always, um, interesting to know. Um, so I mean we're talking about this beautiful book today. Um, I think, um, when we talk, I mean when you write a book, I mean this is like, this is actually quite, quite extensive book. So I was. So to be honest, when I read through it, I was surprised how many aspects of product management are actually covered in there and how many things that I also experience in my career are covered here. So it's, it's, it's quite extensive. And I mean, I guess you have been asked that a thousand times. But, but why, like how did you come to that point in time? And you said, I need to write a book about this.

Speaker B: So the point in time specific that King was in the conference, it was Product Tank in Munich actually. And that was I think, 19th of April last year. So until that moment I was like, I'm not going to write a Book. I will keep writing blogs about this, and so on and so on. And I remember that I was really running away from the idea of writing a book, but because it's. It's very complex. But I noticed that as I started blogging, people from different corners of the world start asking me the same questions. And I would point them, um, to some books, like good ones from Marty Kagan, from Teresa Torres, and so on, and say, I like the book, it inspires me, but I often don't know how to move from where I am. I don't know what to do. So many people kept saying, I got a lot of inspiration, but I still said, I'm not sure if I'm the one who can solve that. And then I gave the talk at Product, uh, Inc. And there were a lot of people, like, noding, taking pictures. And the talk was called untrapping product teams. And it was something I was working on, uh, and so on. And after the talk, I remember There were around five to 10 people in a line that want to talk to me, ask questions. And then in the end of the day, 10 people talked to me after that. And out of 10 people, eight asked me the question, when are you writing a book? And then I was, oh, crazy. And then I asked a few people, why do you want a book from me? M. And there was a kind of a trend, like, one of the things, like you can make complex things easy to understand. The way you speak I can relate to. Yeah. So that was one. And the other is you speak in a way that I haven't seen other way. So, uh, like, you know, I. I like sharing my mistakes. I like sharing the things I did wrong. And I'm not afraid of saying that. Well, many companies, they do struggle to create product. And I don't say that companies are bad. I say that they haven't experienced other ways of working, so someone needs to show it on that. So that was the moment that I got into thinking about the book. And Ioana, who also helped me review the book, he said, she said, you have something to say, and people need to listen to that, write the book. And then four days later, I started.

Speaker A: That's brilliant. I mean, there's also, like, kind of this bias to action that you are also describing, um, or like that that I read in a lot of the stories that you share in the book, where you just see something, it's like, that's not right, and then you just go for it. And I really, really enjoyed that, um, while reading it. Um, so I Mean the book is structured in like three different parts. Right. Can you share a bit more about um, the three parts and why these three parts? Uh, specifically.

Speaker B: Yeah, these three parts are related to how I work. So in general, everything I do, I have the first part in mind which is you have to face reality no matter how it is. Maybe you don't like what you see, but you have to face it. So let's understand what it is. That's part one of the book, Face Reality. So it is about understanding the traps you have, how the teams work, what is getting in the way. So you want the send me out. And the second part is taking action. So how can you move from where you are to where you want to be? And then uh, I bring a lot of perspectives and that is the biggest part of the book because that's when we get hands on, on most of the things. And the last part, how do you remain there? Because if you just sit down and relax, big chance that things will just return to what was comfortable for. So that's what happens. So I structured the book and this three part. Face reality, take action in general and then set some things to remain untrapped. Mhm.

Speaker A: What do like when you look at the three parts, what do product managers or like organizations struggle most with?

Speaker B: So the first thing is like there is always like we can't change. Like there are many people involved there. It's complex. I cannot drive the order. So product managers generally will feel like I cannot move the needle. Who am I here to do something? And then we, we keep telling these stories to ourselves and we just accept the status quo. This is one thing that happens and the other is the, the routine like uh, we keep doing things the way we are doing. We're everyone is busy and so on and we don't find time to challenge. So the very first part of facing reality is what people don't do it. Like we just accept the reality. Maybe we don't like it. So instead of taking action, we complain a little bit here, a little bit there. We don't like the roadmap how it is. We don't like how decisions are made. But we are not really trying to find what we could do today for better tomorrow. So that is one of the biggest struggle, understanding the big question, does it make sense what we are doing today? Mhm. We just do it, keep doing it without knowing if it really makes sense. Mhm.

Speaker A: And when, when people get to that. So that's basically the inertia. Right. Of, of every organization out There, I mean, it's like, it's a very common issue. Right. We see that also, um, as well every day that. I mean, change is hard. Change is hard. Yeah. And but once, once people like come to the realization that, that there is something that needs to be changed. Is there. If you think about like also what's in the book and also all the traps that you describe, what would you say are like the top two or top three, uh, things that you see organizations are struggling with.

Speaker B: So the struggle I see the most is prioritization. And prioritization, it is not about giving teams 15 topics to work on in a quarter. Mhm. It's telling them what is the most important thing they need to work right now. Get that done. So leaders struggle to make the decision on what matters most. And telling everyone, like you have to do all of this, that's not decision making.

Speaker A: Ah.

Speaker B: What will happen is then teams will have to juggle topics and uh, consequently silos will be created and there will be a divide and conquer, lack of collaboration, increase of dependency. And then it goes and a very complicated way of working. And that's what I call in the first part a coordinative way of working. So we will be coordinating more and what happens is very simple. We talk a lot about work. We are all the time talking about work. And if you ask who is doing the work, it will be hard because everyone is talking about it. So that is the uh, biggest struggle for me. And the second one is very related to what happened after Covid, which is I call as the hidden frameworks. Um, and this one is the cdr, the Calendar Driven routine. So we do whatever is in the calendar. If a calendar, uh, gets filled, we are going to do that. You may think you are doing scrum, scrum or whatever, but no, what is in the calendar is what you were doing. So we become a victim of the calendar. And why do I say Covid? Well, very simple. Now we are here in person, right. So that's cool. But now how many meeting rooms do you have? The teams have unlimited meeting rooms with unlimited seats. So as a consequence more meetings with more people.

Speaker A: Yeah, that's quite crazy, I think. I love, um, and I always try to go back, uh, to my notes and the post, uh, it's there and then we can figure out whether my system is working. But I believe it was, I think in the first one or two chapters, um, where you basically say prioritization doesn't have to be complex. Right. And I really, really, uh, love that. And I Think one of the things that I really liked is when you were talking also about, um, prioritization and also the fallacy of the feature factory. Um, it says here in the book, the more unclear the company's vision and strategy are, the harder it becomes to decide what to do with Endless ide. And that's essentially in a nutshell, a prioritization. And a prioritization becomes hard.

Speaker B: Exactly. Because many people think that prioritization is about saying yes to everything. And like Steve Jobs saying, uh, it's about saying no. So I like saying like, let's filter things out. So what is our vision? So we have loads of ideas that we want to do. Let's just drop everything, um, related to the vision. Then let's look at ah, our strategy right now. It doesn't help the strategy, so why are we even talking about it? So if you're talking about it, then we need to challenge this strategy. Let's redo this strategy. But what happens is vision strategy, they just get ignored and we talk about everything and, and then we struggle. So it is important to filter things out and then we reduce the choices. Mhm.

Speaker A: And saying no, I mean saying no, you just scratch that. And that's also like a good, uh, it's actually marked, I don't know if you can see it. It says just probably you can't see. It just says no exclamation mark on here, actually on both sides. So I can, can find it again, um, saying um, no without explaining why is a bad strategy. And I really, when I saw that, I really celebrated that tiny, tiny sentence. And um, I'm not sure, um, how, like if, if everybody got it that way or if it's just me like looking at the sentence saying like, oh, that's. Yeah, exactly. Because I think when you, when you as a product manager, you have your certain bubble, maybe LinkedIn, maybe Twitter, uh, who knows? And then, um, in the last three years there was a lot of discussion about this saying no, saying no, you have to say no more, you have to say no more. And what you are essentially saying in the book is yes, you should say no, but you should also explain why you're saying no. Um, so how do you, how you, how do you do that? Because I feel this is also something a lot of people struggle with, like saying no to things.

Speaker B: Sure. So let's say how not to do first. That's one of the things I wrote in the book there. Uh, my first strategy was flawed because I realized that I had to say more notes and it's true. I read in a, um, blog post once the most relevant skill of product manager is the ability of saying oh. I read that. I took how it was written and then I, I had an idea. Whenever stakeholder come to me, I say no once, twice, three times. And if the stakeholder bothers coming the fourth time, I will say maybe yes. So that's what I was doing. I got a nickname, the Business Blocker. What?

Speaker A: That's not a good nickname.

Speaker B: No, it was not. Uh, uh, so let's say the, the more I said no that way the more emails my product director got. And then he started coming to me, said, dave, you're a nice guy, but there's something wrong here. Mhm. And then I, I'm curious. I said, what's wrong? I said, look at these amount of emails. People are saying that you're blocking the business through progress. I said, they are loading me with requests which are unrelated. He looked at me and said, did you help them understand why? And then I realized that actually the challenge is not saying no, it's helping the stakeholders say no to themselves. So the key thing is you need to have them come to the why. It is not relevant to the moment. You may need to do some homework. Most probably you have to what is the vision? What is our goal right now? And then you ask the question like we are trying to achieve a. How does this request enable us together? Help me understand. And then you go to another question. What is the evidence you have supporting this? How do you know what success looks like? And then, uh, as uh, you collaborate with this, you realize that many people don't have the answers. And then they will reflect and say, you're right. And even if they insist you don't commit to a delivery, you say, let's run an experiment, a quick one, let's try learning if this makes any sense at all. So my learning was after making a mistake with a bad strategy, you need to figure out in your scenario how to help the others say no to themselves.

Speaker A: I really love that throughout the book, I gotta say, because there are so many, um, tangible examples just from your own experience, like outlining, um, somewhere where you went wrong even. And that's, I think that that is a huge strength of you and the book, that essentially you are very vulnerable in the book, um, saying, all right, look, I screwed this up, um, but this is what I learned and I really like that because I can first of all relate to a lot of situations, but I also could take away a lot from a lot of situations that you were describing in the book. And, um, I think one of my. We have to put a pin in the whole strategy discussion because I need to share something first. Um, um, that I really like. One of the anecdotes that is in there. Tell me about the first time that your first working day was in the hospital. I found that story hilarious.

Speaker B: So that was like, uh, I couldn't believe that, uh, so there were several things happening that the truth, what is not written in the book, is that that was my last shot to product. I was like, fed up with product. And I had a chance there that moment to become an agile coach. I had an offer and I had another offer for product, and I was pounding. And then I took the product offer, rejected the other, and I would start on money. And it was Sunday. I got a call. Who's calling you on Sunday? And then there was a different number. And hey, David here is the CEO of, uh, in Sahu, your new startup. I said, all right, what happened? He said, I need you in the hospital tomorrow. My wife is sick. So we meet in the lobby at 8am Is it fine for you? I said, yeah, it's fine. Which hospital? Luckily it was closed because it's Sao Paulo, and Sao Paulo, like, uh, could be like two hours to drive there. But then I was wondering that day I started thinking, did I make the right choice going to the hospital my first day of work? I said, all right, it's gonna be fine. And then I start thinking, let's not worry about problems I don't have. Let's just go to the hospital and see what it is. I arrived there, take few minutes. The CEO arrived and he said, uh, let's grab a coffee. I get a coffee, I sit there. And then the CEO starts telling me a lot of things. And he look at me in the eyes and said, we have $10 million. Every month we burn one. Raising cash will take around three months. As of now, we have anything close to market fit. What I need you to do is to figure out how to get at least 30% more engagement with our car dealers so I can convince some investors to put more money. I want you to redesign the app. That's your role. And then I look at him and said, all right, how do they like this app? He said, no, they don't like. They hate it. They hate it. With all their strengths, they hate it. That's why you have to redesign it. But don't worry, I have. Everything started out so you redesign and everything's going to Be fine. You need to have excellent execution. So you have three months to show me you can do it. And, uh, if you show it, then in probably six months, we can get more money. And if we can't, then you should go to the job market, start searching for something. He stood up and said, I want it done. Uh, no excuses. I remember sitting like, I was sitting very straight, and then I was like, oh, my God, that was insane.

Speaker A: And this is. I think that that is what makes the book special, because I've read this and I was like, what? That's insane. On the other hand, what, what I like, I mean, looking at this specific example, and I think, uh, you mentioned in the book. All right, I mean, he gave me a solution to clearly solve, like, a problem. But on the one hand, he also told you exactly what the problem is and what the metric is, that you could measure the success of the problem. Right. And that was. That was good about, uh, that example at least. Right? Um, yeah, sorry, I had to scratch that because I really, really love that story and it would have been a shame not to talk about it. Um, all right, so let's take like, the strategy bit, um, back because, um, so we were talking about saying no and like, strategy. And I think it also relates to that story of the CEO. So, um, I mean, a lot of companies struggle with product vision and strategy. And then you have, um, a product manager reading your book, and, um, she or he comes back into the company and figures out, well, we don't really have a strategy at all. So we don't really have any guardrails that would allow me to filter out certain things. So how. How can you help those companies? So what do these companies need to do? And also how can maybe like, um, an individual contributor, um, help to get the company there?

Speaker B: The individual contributor. See, two chances of acting, and one requires taking action without asking for permission. And the other is about helping the other see the situation. One is talk to the product leader and say, I'm struggling to prioritize. Look at this. How am I supposed to prioritize? I don't know what good looks like. I don't know where we are going. I don't know where we want to land. Help me and the product leader would have the chance of influence more on the strategy and so on. So this is about sharing the scenario, but that won't help the others get something more tangible. It's a discussion. This may take long. So that's why I see two parts. Start with this by elaborating and the second one is what I like the most. Generally, companies, when they lack strategy or vision, they tend to work in a feature factory format. There are a lot of features that they need to deliver day in, day out and so on. So instead of just delivering the feature, look at the assumptions behind it. What are we assuming with this feature? We are assuming that customers will understand how to use it. We are assuming that they will actually use it. And even worse, we are assuming that they wanted. So what could you do to gather evidence if that is true or not? And you can run a few product experiments, create a prototype, an interactive one, do unmoderated sessions, see how customers react to that. And then within the results, you can present to those who prioritize, say, hey, I ran an experiment here with 10 customers. This is what I learned. And then you can show, I learned that they don't understand what it is. They say they are not going to use it because they have another solution. And then you can ask the question, should we continue working this way? I am seeing that if we do that, we are just heading down a cliff. If that's what you want, you are the one making the decision. I, uh, will execute. I'm not recommending. So in these companies, product manager needs to try finding what are the cards I have. And some cards are kind of hidden on the deck. Assumptions you always have. You can just name the assumption and run a product experiment. This, you don't need to ask for permission, can just run it. And the advantage of this, you still remain there saying, I'm going to do everything that is needed. But I'm showing you another perspective. So this, you trigger reflection. And that's when you move from opinion to evidence. You have an evidence here, you ran an experiment. And uh, when I did that few times in my life, people get a bit, uh, shocked. They start. So you're telling me if you invest three months developing this, it's not going to lead to anything? And say, yes, that's what I'm telling you. And that's the moment you start triggering what is needed to craft a strategy, to craft a vision. But you need to help them see something that is painful, that we are not creating useful features, you're not creating value. M. That takes some courage.

Speaker A: So you're basically saying, um, you have to put. So it's like a saying we sometimes use. Just you put the pain where it belongs. So in terms like you point out to the CEO or to the product layer, we can do that, but it will not give us anything in terms of value. Yeah, right, got it. Interesting. Um, there's also, there's also another story in the book that I really enjoyed, uh, because you were just mentioning not um, asking for permission to do things. Um, there was a story that I read and I could hardly believe it. So you got to elaborate a bit on it. So m. It's about an E commerce store that you just launched into production um, without really asking for permission. Is that, is that true?

Speaker B: Well, we had. The E commerce was already running so we had a website there. I think we had around 100 to 150,000 customers using that. It was a running business of uh, four years in a row. When I arrived there, the team was working frenetically on a new version of that MHM for six months and nothing was launched and so on. And yeah, it is true that I gradually release that to all customers because what was the problem there? Someone read this like uh, in God we trust, all others must bring data. And then they start saying like we need to deliver everything in comparison to the uh, to both websites better. I said, not really true. I said we need to deliver more value. So what, let's understand what we want. We wanted same level of basket size, we want some same level of sign up rate, we want this and so on. There were a few metrics that we need to ensure that they were delivering that. And there was so many discussions. I remember there was a dashboard there. I had to scroll three times to read everything because it was three pages.

Speaker A: I know these dashboards, horrible.

Speaker B: And then I was, we are never going to launch this. Um, and I remember running a few tests with users and all of them could get to, to the point of buying the product way faster than before and they liked many aspects of the new one and I couldn't see why it was not live. It was because maybe there was low conversion here or something there and so on. I said I'm just gonna put it live for five uh, percent and see what happens. And I remember when I put there I started seeing sign up rate is higher actually and revenue is higher. I said the two most important are up. Uh, in between there were some things different. But I said what really goes to the bottom line is up and then I start looking where people got lost and so on. A little bit of tweak here and there and then it is working for 5%, maybe it works for 10. And then I did that and I remember when the CEO came, wow, congratulations. We have been trying to launch this for more than two months now. And you arrive here in your second month, you are putting it live. How did you ensure the numbers are correct? And then I said, well, I ensured the most relevant numbers are correct. The others, I couldn't care less about that. And he looked at me how I said why would you care about the number of customers clicking on the logout button? That is irrelevant. And then he looked at me, well, we need to ensure they find the button. Said we need to ensure they buy. We need to ensure they sign up the new ones. We need to ensure they are able to recommend. That's what we need to ensure. I looked at this, they were good. So we moved on.

Speaker A: And that is, that is again. And I mean at the end of the day, like a lot of things when also when I read the book and a lot of the discussions that we have in product at the end of the day always boils down to kind of focus. And what we talked about, like the strategy can kind of give you the focus to work on the right things.

Speaker B: Exactly.

Speaker A: Yeah, it's um, yeah it's, it's, it's quite amazing. I have so many, like I have so many things on my list. So I just looking at the time. So we are already half an hour in. I um, can't really believe it. Um, so one of the things that, that I kept thinking, um, so the first question we have already talked about, like what, what do most people struggle with? But I mean there's a lot of pointers ah, in, in the, especially in the first part about um, spotting these dysfunctional environments.

Speaker B: Right.

Speaker A: Can you elaborate a bit on that? So if you would come m. Into a company, what would you look at first in order to figure out if this environment or if the organization from a product perspective is dysfunctional?

Speaker B: Roadmap.

Speaker A: Roadmap. Clear estate.

Speaker B: Yeah, that's the first thing I would look at. Um, so in the. When I was a product manager it was the backlog, the first thing I would look at. Yeah. Uh, first thing I want to understand how big that is. If I saw more than a few hundred items, I would say, okay, I know what it gets. So I would look at the size, the oldest item and then I would search for placeholders. So I will start finding these things and then I would. But now if you look at Roadmap, that can tell you a lot of things. First, what does it look like? That can tell you if it is a strong feature, a uh, strong output orientation and you can see decision making because it can be strong an output and still have just A few output defined there. Then you say, okay, prioritization, maybe it is not that big of a product can work there. But if you see these extensive roadmaps, uh, then I start panicking there. So I look at roadmap and the next thing is the how. How did they come to the roadmap? Who was involved? Who defined how did the product managers collaborate with that? Were they informed? Were they part of that? Did they create and got approved? So these are the aspects I try looking at. So that will tell me a lot about the maturity on stepping to the unknown, product discovery, collaboration, making decisions and many other aspects. So that is the very first thing I look at.

Speaker A: That's super interesting. So you said like when you look at the roadmap, you're looking especially for how output driven is it and how many items are on there.

Speaker B: Right.

Speaker A: Um, if you look for like the how. So how did it come into existence? What? So you said you're looking for like how were the product managers involved? How did it come into existence? Is there, is there like um, a typical way how it comes into existence where you would say, okay, that's that. If I see this, then I can clearly tell this is a bit dysfunctional.

Speaker B: Throwing over the fence is the most dysfunctional I would say. So someone outside the team that can be different can be like leadership or leadership with sales. Someone decides what the team should work on. So that is a classic service provider relationship. So the team is like executing what the others define to. Uh-huh. So why is it going to be so dysfunctional? That will kill accountability. The team will have no accountability, will say, okay, I'm going to execute. We may do our best, but in the end if it fails, we didn't have a say in that.

Speaker A: Mhm. Accountability. That's also like a good, um, I feel we are kind of sliding through the points, to be honest. Uh, awesome. Really awesome. So because accountability, I mean accountability is such a big topic, I mean it's not only a big topic in product, but I feel that we have been focusing on accountability a lot in the last years. Right. So, um, I'm just gonna share a feeling and uh, maybe you can tell me if I'm completely off about this, but so I have a feeling that there is a tendency, um, in product that people want a lot of responsibility, but they really don't want the accountability for that responsibility. And on the other end we are talking about, um, this concept of empowered teams. Um, so, meaning the teams are not only responsible, but they are also accountable. And I'M just like wondering, um, I mean you write about empower teams also in the book you write, right, about accountability, responsibility, um, and I'm just wondering what's your take on it? So how do you perceive that situation and how can we get from people just want to be responsible but not accountable towards more empowered teams that actually want to be accountable for the outcomes they are.

Speaker B: So that's the thing, um, a lot of people say about outcome over output and so on, but the game is very different. So if you are accountable for output, you deliver what was defined on time and that's it to the next we go. So it's a different level of accountability and that is an easier game to play. But if you want accountability on outcome, it's another league. You are simply playing in another league. And that's a very hard one because why is it so hard to get the accountability? Because you don't know what you don't know and your ideas might be totally off and you need to confront reality and then you cannot achieve value alone. You need the customers to engage with what you're creating and so on. So many people do want to have the accountability, but they don't know what they are asking for. So how do they move? They need a mentor, they need someone who has done that, who can help them. Some organizations try to move from let's say a classic project oriented structure to an outcome oriented, like creating value. And they struggle because they would just play the same game. They don't know how to get there. They need someone who has done that and can lead the way, show them different ways of working. Because for me it's like very unlikely someone can live up to the accountability without knowing what it entails. Because uh, it's a game that requires flexibility and change of plan all the time because you don't know. And for that to work, support from leadership is paramount. Without that then the leadership, uh, without the support from leadership, teams have no chance to succeed. And one of the key things that need to happen is to move from upfront investment to placing bets. Mhm. So everything you're going to do is a bet. So let's say we have a bet that this feature is going to deliver value. How much are we willing to bet on that to create the minimum evidence? Maybe you are willing to bet one week, maybe two weeks, it's a bet. And then you decide if you want to invest further or not. So these aspects need to change. And what I tell in the book a lot is this kind of change. They don't happen from day to night. It is better to start small. Take one team, try running that with one team, see how it runs. And then you can try with another team and then another. And that means like being a product manager, you need to swallow some things you don't like before you can get there. M. It's step by step.

Speaker A: I think that's quite interesting because at the end of the day, what this whole discussion, so what you were just talking about, like moving from output to outcome, completely different game, completely different league. I mean at the end of the day the question is, can a single product manager be made responsible for the outcome?

Speaker B: Well, if it's in a startup with a small product, yes. But if it's in a corporation, uh, gigantic one, no, it's a team game. So it is a collective responsibility. Some teams will be responsible for a very tiny small part of the product. So it's a group that will be responsible for driving the outcome. If you look at Airbnb for example, how would the product manager ensure that you increase the number of hosts offering there? How would a single product manager increase the number of um, stays booked a day? There are many things to happen. You can increase small numbers there, few things, but you depend on the others.

Speaker A: So in these, I mean there's always like this kind of saying that one person must be made accountable for one thing or one person must be responsible because otherwise you kind of have the issue that if 10 people are responsible, no one is really responsible. So in bigger environments, because I mean, um, the startup situation is one bit right? So one team and it's usually also um, let's say a, um, more clear focus on one thing because of limited resources. But so in these big, I'm interested in these big environments, right? How can you ensure that, um, because we have talked about focus, you need to have focus on only a few things, right? How can you ensure that the different teams and uh, like product teams can actually contribute to the metrics we want to increase the outcomes we want to achieve, um, in a way that they still feel accountable for their part of the outcome.

Speaker B: So the more you grow, the more structure needs you have. It's utopic. You think you're not going to have any structure. So I like having, for example in bigger organizations, maybe you're going to have a product lead or a group product manager who will oversee a few teams or head of product. It will vary according to the size. But someone, as you said, if everyone has a responsibility, no one will have someone issue. Have A different flight level so you can oversee how the teams are contributing to that. And then it's when it comes to the conversation like what are the leading metrics? So if the goal is to increase let's say sign up rate but then you have four teams involved in that, what are the metrics leading to that? So are we increasing for example organic traffic are increasing this. So every team should be responsible for something smaller. But then someone looks at the big picture and see how they play out. So that's what I would recommend. You need to give a like a ah, bite size responsibility for each team while someone flies at a higher level and can see and get the teams to collaborate to better.

Speaker A: And I mean one of the things that um, I mean it's been around for a longer time but one of the let's say frameworks and big quotations that became popular around also these issues um, is okrs. But you write in the book you are not necessarily a big fan of okrs. Why is that?

Speaker B: Uh, generally becomes a cascade effect. So there are OKRs for OKRs and OKRs. And it is more confusing to start with OKRs than solving the real problem which is prioritization. So I'm not against okrs but I haven't seen an implementation um from beginning to the end that really solved the problem. What I saw was multiple objectives with 10 key results. So most of the time and then teams take this and they start competing. So what I like is let's solve the problem of naming uh the goal we are achieving and then start from there. It is in the direction of okr but just removing the framework itself so we can have the conversation. I do believe okrs can work but it depends on the maturity of the company because you know if you give a hammer to a kid everything is going to become a nail. Mhm. Because they simply don't know what the hammer is for. And if you give an OKR for a company that is really project oriented, OKR will create quickly move to project style. It will be very hard culture wise. So I say a lot in the book that uh, one of my favorite things is adding by subtracting. So let's not add the framework, let's remove how we do this and focus on a goal and so on.

Speaker A: Is it dangerous that we keep introducing more and more frameworks and product?

Speaker B: Yeah, I think that's one of the challenges. I do speak a lot uh about frameworks but to give example on how we can collaborate. But framework is a means to an end and quickly becomes the objective. That is my fear, because the framework should help the team achieve something and not drive the team. And the more we introduce frameworks, the more we start doing what the framework allows us to. Weird conversations I have seen. How do we do discovery with Scrum? How do we estimate with, um, Scrum? Like, that's the wrong question. It's like, how do we estimate? How do you do discovery? It doesn't matter how they do it with Scrum. Scrum is just supporting you with a few things. But it's not like trying, uh, to see, am I breaking the rules of Scrum? Am I breaking the rules of Kanban? No, if you have to do discovery, even in the question how they do discovery, the thing is like, how do I confront my ideas against reality? How do I learn what is worth building?

Speaker A: Brilliant. So we have about 15 minutes left. So I think I would love to open, uh, the discussion up for questions, but before. So if you have a question for David, just um, put it in the chat. And I know um, a lot of you are on holiday right now and not like a lot of you might have joined, but if you're watching this, uh, or rewatching this, then, um, how can people reach out to you? They have questions.

Speaker B: Sure. I'm very accessible on LinkedIn, so you can connect with me there or can drop a message on my newsletter.

Speaker A: Dpedata.substack.com so you had, so you were talk, just talking about frameworks and um, you had like, you have the Now Next later of Janovasto in the, uh, in the book, but you added another column called Trash. Can you, can you tell me a bit more about that? Why, why does the Now Next later need another column? Trash?

Speaker B: So the Nonex later is something that saved me several times because my roadmaps, initially they work on charts, so that is just uh, a way of transforming any agile work into project management. Classic project management. And then I started using NX later. So we defined what I'm gonna do during the next three months, then six months or. And later after six months, using the now next later, I couldn't bear how long the column later became. And then I realized that anything that we would try running away from discussion would go to later. But then the next session, the next quarter, we would talk about the roadmap. People would start saying, hey, let's look at the later. And then the conversations would just come back all the time, the same conversation. Should we do this? Should we do that? And then said kind of I, we talked about it. Already. And we agreed that no, then someone, okay, let's keep it for later. 1/4 later again, let's keep it for later. And then I realized that we were not making the hard decisions of agreeing on what we are not doing. And I said, how do we do that? This framework here suggests that we can put everything on the lighter. I m said, let me spice it up. And I said, let's put the column trash here. And then we are going to look at the topics we have and say, what are we going to put into the trash? And then I ensure that uh, during the next one they would not be there because trash, you know, you need to recycle the things.

Speaker A: Uh, uh, that's brilliant. So it essentially the trash column became like a decision tracking and alignment tool for you.

Speaker B: Yes.

Speaker A: Brilliant. Yeah, I love that. All right, so I think when we, when we talked about um, what we're going to talk about today, so the, the, the meta meeting, I think you call this, um, we, we, we asked you, is there, is there one question no one has asked about the book yet. And you said you had to think about it a bit. And then you said yes, no one asked me yet where I wrote the book. So David, where did you write the book?

Speaker B: So that's uh, something interesting. Multiple place. Uh, I wrote the book several, uh, times on the move because last year was a very active year for me. So I started leading this startup there. And I didn't have a lot of time for writing as I used to, but I was traveling a lot to Hamburg and on these trips to Hamburg, for example, you know, the connection is not that good. And it was a moment to focus, but I still said, okay, how do I do that? And then I decided that on the trips, for example, I would have three hours straight. So I planned to arrive in Hamburg like at midday. So I would take the train at 6am and then from 6am m to 9am m I would focus on writing, just put some music and then I wrote. Sometimes I was not in the mood of writing at all, but I just needed to get going. So write the first sentence, the second, and then it goes, and it goes. So I did that for six months in a row. That was one aspect. And the other was, let's say we got a bigger car. And my wife said, I'm not going to drive this car. And then I had the problem that I should not have in the first place because my wife is a makeup artist. So she drives to her clients and I stay at home. It was good for me. Uh, but then she said, no, now you need to help me. I said, m. Okay. And she generally goes to the Alps. So one and a half hour driving. I said, okay, I'm going to drive with you. I just need one chair and a nice cup of coffee. That's the only thing you need to offer me. And then I will do that. So we went to different parts of the Alps. And I remember that, uh, one of the chapters was fully born there. I wrote chapter 12 about principles in one of the trips. I remember looking at the Alps and I said, how do I come up with this message? And it was so beautiful. It was a little bit sunny, uh, beginning of the day. And then I went straight on, wrote, uh, the chapter 12 there. Then we had another trip, Then I wrote another chapter and so on. So the book was actually written on the move, most of it. So going to Hamburg. My wife went somewhere and then I helped her. Sat in front of a lake, in front of a mountain and wrote and wrote focus.

Speaker A: That's brilliant. I mean, uh, they say that, like, when you are in the mountains, it's like usually quiet and it's a time for contemplation. I mean, it's usually not a place where you would expect someone to work really hard on a book. But I think, uh, as you describe it, it was probably a very inspiring place.

Speaker B: Yeah, yeah, it was nice. And sometimes I would just look. It was the mountains. Some birds would just come here. I would just sit, observe, and kind of my thoughts start triggering. One will go to the other and so on. I said, oh, I'm going to write about this and this and this. So that's how it happened. Uh, and many people ask me, like, how do you find time to write? I write, uh, even when I don't have the mood for writing. I just need to start. And that's what I've realized with most of the things, it's the starting part that is the hardest. And if you manage to write one sentence, maybe you don't like the sentence, but you write the next and the next. So that's what I did. Uh, and, uh, about writing. I would just go straight on. And then after I would read, I would review, I would remove things and so on. I didn't care that, uh, I didn't care at all about editing. In the beginning. I just used an expression from Portuguese in Brazil, kind of I wanted the content. And then I adapted.

Speaker A: Yeah, yeah, that sounds good. So it's like the first, first iteration was simply just like a brain dump and then you continued writing until it was basically just all out.

Speaker B: Yes, exactly.

Speaker A: Brilliant. Sounds great. Thanks for tuning into the Product Masterclass Podcast podcast. If you enjoyed today's episode, make sure to subscribe and leave us a review. It really helps us reach more product people like you. If you have questions or topics you'd love to hear about, reach out to us on LinkedIn, YouTube, or visit productmasterclass.com.