[00:00:00] David: Teams face certain level of traps, some they are aware of, and some they are simply unaware.
And I noticed many patterns on the way. So I thought, actually, I have seen many books that are good on what is a state of the art of product management. But I have seen only a few books saying like, how do you address reality, your scenario? What are the things you can do today for a better tomorrow, even if it's a little bit better?
[00:00:26] Michel: Hi everyone and welcome to Growth Leap. I'm your host, Michel Gagnon. We talked to pretty awesome business builders who are designing disruptive and meaningful companies.
[00:00:39] Introduction to David Pereira: A Product Leader's Journey
[00:00:39] Michel_: Hey everyone. Get ready for an inspiring and insightful chat with David Pereira, a product leader with 15 years of experience and currently the CEO of Omoco, a company shaking up the maritime industry. He's got a unique perspective on product discovery, idea validation, prioritization, experimentation, and more, basically everything you need to build a meaningful product that solves a real problem. Is the author of more than 300 articles that have reached over 10 million people. He's the coauthor of the agile product manifesto and more than 15, 000 students have taken his courses on product management. So without further ado, let's get started.
[00:01:23] Michel_: Welcome David.
[00:01:25] David's Background and Role at Omoco
before get into the, The real meat, I, would like you to give us a quick rundown of, of your background. And, what you're doing at Omoco, for the people who may not know you.
[00:01:36] David: Sure So glad to be here a little bit about me. So i've been building digital products for 15 years from software engineer product management also head of product cpo co different angles and Generally, I share a lot what I did wrong because I did a lot of things wrong on the way I learned After hitting the wall.
So I try helping people avoid that. So based on my experience and Adamoko was something surprising. I actually was there as a consultant was an interim CPO and then received a chance of getting the other seat title, which was big challenge for me, but I'm enjoying the journey so far.
[00:02:21] Michel_:
[00:02:21] Simplifying the Maritime Industry with Omoco
[00:02:21] Michel_: And can you tell us a bit about Omoco? What is it that you're doing exactly? What problem you're trying to solve?
[00:02:27] David: Sure. So we're working on the maritime industry, which is B2B. So there's something called Terminal Operating System, known as TOS. So every port in the world needs to run their operations. And this Terminal Operating System is how they operate. Control what goes in what goes out where to put the box where to do that and so on And it turns out that this thing is quite outdated nowadays.
There are some providers that are doing good job But it still is a little bit of the old way of creating software Like you install something you customize and so on what we're trying to do there is to simplify Like why should you take a year to get your terminal to run with a new terminal operating system instead of just a few clicks ahead of you?
So we are simplifying that and avoiding all of this customization and so on. So that's what we're doing there.
[00:03:27] Michel_:
[00:03:27] Transitioning from Product to CEO: A Dual Role
[00:03:27] Michel_: And how, has the transition from product to CEO been going for you?
[00:03:33] David: So it's a little bit different thing because I actually still have the two titles there. The reason is we are small. So as of now, I haven't seen a reason to hire a dedicated CPO. So we are still getting into the market, hitting the first customers. What I learned is I need to be careful with what I say because sometimes what I say becomes like what teams should do and it's not what I meant sometimes I just want to hint what it makes sense and I would like people to challenge but sometimes I don't get a challenge So one of the learnings is like to use more questions when I'm trying to express my ideas and not the statement.
And to ensure also I make clear what is important for the company as a whole and what is unimportant. Because if I don't make that clear, it means that confusion takes place.
[00:04:29] Michel_: Love that.
[00:04:30] Solving Big Problems: Strategy and Customer Focus
[00:04:30] Michel_: entrepreneurs and startups are being told today to work on big problems and create value. And like many other pieces of advice, makes sense conceptually, but it's a lot tougher to implement. What, what's your approach to, you know, uncovering big problems and differentiating customers wants, from their needs.
[00:04:50] David: Yeah, this is something not simple. And in the B2B gets especially more complicated because you have those paying the bill and those using the product. And let's say needs and wants are different for this, two audience. And yet you need both of them to be successful. So one of the things that I have been trying to do at Omoku, is to select a problem that we can do, not trying to take a problem that is too big for us, that we just don't know even where to start.
And what I see is like, when we say the maritime industry, it is something very big. And, And that should be our vision. But where do we start? What is the smallest audience that we can start working with and create a value to them? So my tip is always like, instead of zoom out, let's zoom in as much as possible and try understanding what does this audience care about?
And what can we do for them right now? Let's just think about them. And I say, like, I have one of my principles is solving current problems over future problems, because when you select a small audience, it means you are looking at something staring at you and you might think, Oh, but for a term that's slightly bigger, we may need this.
We may need that. We may need this. And this conversation isn't helpful, not at this stage. So we need to say. Let's focus on what is in front of us and do the best we can and the others come later and may not even come
[00:06:28] Michel_: So if we take a concretely Omoco, as an example of that, I'm In understanding who your customers are. And, you know, when you look at, when you're saying what is in front of you, what is in front of you actually with Omoco? Um, were trying to create something for all the seaport terminals. But when we look at the seaport terminals, what happens? We have different ways of receiving cargo. You have the vessel, we have the truck, the rail, and you have different cargo types. You have the container.
[00:07:04] David: And then you also have something general cargo, like, like wood pulp and so on. And then you also have cars. So, if you say, let's build something that attends all, the problem is too big. And I said, what is the most common way? What is the most natural? Start like, it is a vessel coming in. And then a truck picking the box and doing something with that.
I said, all right, let's now remove complexity. Let's not worry about rails. Let's not worry about other types of cargo. Let's focus on container, vessel and truck. That's what we're going to build right now. And the rest, we don't think about it. And it turns out that there are terminals in the world that have this situation.
They don't have rail, they don't have the other cargo types, and we're focusing on them while remaining open to the others, but going gradually. So it seems like, what can we remove and still create value for somebody? So that is a question I have been trying to answer to Mocha, and that is a part of our strategy, saying like, we know what we want to create.
but let's say what we are not creating right now.
[00:08:13] Product Discovery and Strategy: Learning from Mistakes
[00:08:13] Michel_: you've said in the past, you know, you've talked a lot about product discovery. And, you know, the good questions and the making that difference between good and bad questions, making sure that your assumptions are, clear and in front of you. And this, covers a lot, the, let's say the, the mindset, the skill sets, the reflexes of a team, right? If you. The Toyota way, for instance, it's, you know, it's an approach that was heavily focused on systems, right? And I'm interested in, learning more, you know, with all your experience and everything that you've tried.
And you mentioned, initially everything that you've tried that didn't work. Do you have some systems in place? To make sure that to, to, to, be used a bit like guardrails where you, to make sure that, you know, you ask the right question at the right moment, that the right things are done at the right,moment and by the right people.
[00:09:11] David: This is something tricky. I have something I call as a discovery journey, which are the elements that are part of discovery. But I thought I'm not making that as a system because one of the things that I realize is it depends on the context, the ingredient you need to use will vary. So what am I talking about here?
For example, In the beginning of the discovery, you need to know actually what are you trying to create for the business because otherwise you are looking very broadly. That means it's an explorative discovery, nothing wrong with that, but it's a very expensive one. You need to have money to afford this.
You know, startup where we have a runaway, we need to think what is important for us as a business. Let's see what are the current pains that customers have and what can we solve that it's good for the customer, good for us, and we can do it. So in this case, like I start understanding the audience, looking at what I call is the value drivers.
And then from there you go in a situation where, all right, we have many opportunities here. What is the one that we should invest time right now? Let's focus and leave the others there. And then it goes to identify assumptions and testing. But then it can be that the moment you started, for example, exploring the assumptions, you realize something you didn't realize before that could be a valuable opportunity.
Then maybe you'll go back to that and you challenge your decision and you select something else to work on. And it can be that, for example, while you were exploring The customer space, the problem space, you realize that what you want to achieve for the business Actually, apparently it's not there, but there's something else you could achieve.
Maybe let's challenge the goal we have here So it's about as it's having the elements and knowing where to go and what the elements are for So I say that it's a journey because you are the driver not the passenger and as a driver if it makes sense You go forward If it doesn't make sense, you, you go backward, you take a left or right turn, but you will decide where to go.
So you reach your destination. So this is the kind of system I use, but has a lot to do with sensing and adapting. So what are you sensing and what is happening? Let's adapt. Let's not stick with a process. And if we see it's not helping us get to the goal.
[00:11:40] Michel_: I want to get a bit deeper on this.
[00:11:41] Daily Practices for Effective Product Management
[00:11:41] Michel_: So, I, I've been told in the past, because I've, a bit like you, I've been coaching some young professionals, and sometimes they, ask me, so what am I supposed to do on a daily basis? you know what? And I think product management is a great field because it's I mean, you've been in it for a long time, but it's it's a very it's a relatively new field. And, you know, the terms have evolved. The responsibilities have evolved. There's lots of controversy. But, what have you done in the past? and what are you doing today to like on a daily basis to, manage, your roadmap, run discovery, activities, how do you structure the work, for yourself and for your teams?
[00:12:25] David: So this question is important to step back on what not to do. So it's very common nowadays to become a call as a prison of your calendar. So you wake up, you look at what do you have in your agenda? That's what you're going to do. So if there's a meeting there, you're going to attend the meeting between the meetings, you decide what you're going to do.
So this is something that doesn't help anybody. And I did that as a product manager. So for example, I would say, all right, I have a sprint planning today. The other day I have the refinement. So I have these, I have that, I have that. So I would keep following and then in between I would say, oh, what makes sense right now?
But that is being a prisoner for a calendar. I don't recommend doing that. The other way is, I like, what I like doing is when I start the week, I say, what do I want to achieve by the end of this week? There's something I want to achieve by the end of the week. Say, all right. So what are the actions I need to take to get there?
Okay, maybe to get there, we need to talk to a partner here. I will need to get support from someone. I will need to test several ideas and see what sticks and what I need to drop. So, right. Let's ensure that my actions are related to this. So I would create my calendar dynamically. This is a product manager.
As a leader.
[00:13:46] Aligning Teams and Strategy for Success
[00:13:46] David: It goes a little bit different because I should not tell people what to do and should tell them what to achieve So I try a line with them. We have a quarterly goal. Then I see like, okay, so we have a quarterly goal What are you doing to achieve that? Are you confident? Help me understand what do you need help?
So I try seeing where they need help and then I try Listening and see where I need to intervene and where I don't need to intervene Because sometimes I hear The Teams are moving to what is easy to do, not because they are wrong, because it's easy to do, for example, what is in your backlog. It is there.
You already talked about it, but then I challenge, I say, how does this help us achieve the goal we have right now? Well, it is a little bit connected. I said, is it the best choice you have right now? No, there's another, but that we don't have all the information. I said, all right, so what is holding you back then?
Because I try seeing like a, I imagine like the big picture and say, are the teams like derailing because the day to day is so crowded with distractions that is very easy for you to derail and go to something else because you can do, not because you should be doing that, not at that stage. So in general, as a leader, I try removing as much distractions as possible.
I caused distraction already. I, for example, I am a big fan of OKRs, but I implemented it prematurely or it can be questionable if implemented correctly or not. I think it was premature because we were just a small company with back then when I implemented 19, 20 people, something like that. and then I noticed that the teams were dividing too much between the objectives.
And the teams were actually fighting and, and I realized that it was not getting them together. I said, why do we need OKR? And I said, I'm creating this distraction. So I said, all right. And I got the feedback from the team. So I'm ditching OKR right now. So we are not using anymore. What we are using is product goal.
We have a goal for this quarter and this is the goal. And here what it means success. And then I keep holding the team accountable for that and supporting them. So it's something like when to support, when to intervene, when to coach, when to mentor.
[00:16:08] Michel_: so you're ditching OKRs. And you are both CEO and CPO. currently, I think this is a bit what,Brian Chesky, who's, leading Airbnb doing, or, you know, has been talking about, doing, recently. I agree with you that, you know, you have to be careful not to be run by meetings, right?
Because, sometimes it slows you down and, and I think, it also affects a lot your, execution or your time to, to action, right? Where you're gonna say, yeah, let's talk about it again next week in the next meeting. It slows you down a lot. But, How are you running the business at the moment? you know, do you have product reviews?
do you have important meetings or, you know, are you playing it by ear when you've, as you said, you know, you need to, you feel you need to intervene.
[00:16:56] David: So we have, yes. So for me, there are a few critical meetings we have, of course, with the leadership team to ensure that we are aligned and we are progressing as an organization in the right direction. So this is one we have, weekly alignment on that I call as a tactical alignment and we have a monthly strategy that we go in depth and we invest three hours in person exchange and with the product team we have different setups so I exchange with the product managers all of them together once a week and we go at the critical topics so what are we working out how do we support each other and so on.
And then what I have also is two things. Look, every two weeks we have a product review where the three teams we have present how we progressed. And we always look at the quarter goal and we say, here's the quarter goal and here's what we are progressing. And then we share the results of that. Sometimes we do fail to mention the quarter goal, but then I may remind them.
But we look at the, the continuous progress of the three teams together. So it's not, I don't call it as a sprint review. We call it as a progress update because we are a small organization. I don't want to create like, Oh, there's a sprint review of team one, team two, team three. It's a progress update where the team share how they progress and the other departments will share.
Also, we will share how are we doing in the customer success. We'll share how we're doing the leadership. What is happening? What are we doing? Fully transparent. And this is where we get together and we build alignment. And they always make it open for everyone to ask any questions they would have. And, we ensure that it's transparent.
So we have the sessions together to ensure alignment and another session that is very important. We call it the design critique where the UX designers, they bring what they have, what they are working on. And then we help each other and we ensure that the experience throughout the product is consistent.
So, This is a new meeting introduced and I call it as a working session. It's not about presenting and listening. No, we want to help each other. And the reason we introduce is because I always try to drive empowerment. I want the teams to be empowered and create value on their own. But what we realized is like the teams were perceiving the experience slightly differently.
So if I would look at the product earlier last year, mid last year, it, I could see the cuts between the three teams. And I said, this is not a smooth experience. We need to fix that. We need to ensure it's consistent. And then we said, all right, so let's work on this. but not micromanaging. Let's just get the ones responsible for that to talk and provide feedback.
Now I look at the products very hard to say what is what so it doesn't because that's how it should be. It's a product. It's not a set of products from different teams.
[00:19:55] The Essence of Product Strategy
[00:19:55] Michel_: You said that product strategy is a way of creating the constraints for teams to play the game. A good product strategy will lead to smooth decision making. A bad product strategy will lead to confusion. It's all about decision making, about simplifying. Can you elaborate a bit? because strategy And product strategy, I think our terms that are, have been overused and, you know, mean very different things for very different people.
So what, what is it for you?
[00:20:22] David: It's something quite interesting. you know, when I started writing my book, I put a chapter there about product strategy. And I got one feedback because my chapter about product strategy, it's like 22, 25, eight, something like that. And then someone said, I don't believe you're talking about strategy in such a shallow way.
So kick it out from your book. Ensure that it's not in the book. Better not even to say, but actually, I think what people are missing, the point is strategy It isn't complicated. We are making it complicated because the strategy is how you play the game. You can answer the strategy with a few things. It start like, where are we going?
So where do we want to be in a few years? So I want to be there. All right, who are we serving right now? So you need to look in the short term, who are we serving? And what makes us different? You need to know what makes us different. And then once you say, what makes us different, You say, all right, you know what makes us different.
We know what we're serving. Say, what is the next step we can do? And then you name the things that you are not going to do. And what are we not looking at? Because then you create the guard rails so teams can collaborate and you need to bring the quality aspect. For example, in our case, we say that our product needs to be intuitive so that terminals won't bug about how they train their personnel.
Should be so simple to use that anyone can learn how to use it. It's simple and it's by design. And then other is like We don't want to make it complicated for them to install in their terminals. We want to make it flexible so they have the control of that. So we know this and we know what we don't want to do.
So that is for me. What is the strategy?
[00:22:19] Evolving Product Strategy in Different Stages
[00:22:19] David: It is about aligning on the key aspects of running the business and then you discuss what is out and very important. A strategy is not written in stone. You have assumptions there. And, it's important to understand your product stage. In our case, we are still in the introduction of the product.
So it means that our strategy is very immature. So it's, it needs to hit reality. And as we hit reality, which we are doing right now, integrating the, bringing the product to the early adopters, this strategy will adapt and it is already adapting. But as you grow the product and you go into a stage where you are reaching growth and maturity and so on, then your strategy will become more stable over time.
[00:23:07] The Fluid Nature of Strategy and Its Dependence on Context
[00:23:07] David: But what is important to understand? Some people ask me, like, can you give me a template of a strategy? I say, no, it depends what you're trying to do. So are you trying to go to the market? That's one thing. Are you trying to have retention? That's another. Are you trying to introduce a new product? Because maybe your product is already going down the line.
So. You need to understand your scenario and then you come up with things. So I even think that my 25 pages are overrated. I need to simplify that. I started giving value in the beginning, but I think it's about the critical questions and then people know where to go and where not to.
[00:23:42] Michel_: So basically when you say a good product strategy helps with decision making, you're basically saying, the example that you just gave, which is, it has to be intuitive, you know, because of the audience, because of the context. And because this part of the strategy is clear, it should help you. Manager, backlog, prioritize features, et cetera. Is that, do I understand that correctly?
[00:24:07] David: Yeah, correctly.
[00:24:08] Enhancing User Experience Through Product Innovation
[00:24:08] David: And you need to have something interesting in the strategy, right? To make people think. I said that our product is not just a terminal operating system. So we are not just making a product that is better. Our product will be successful when the result of it is the user becomes a better user.
And I like comparing, for example, with cars. So you can always get from A to B in cars, but if you take a Tesla, the moment you start driving a Tesla, you are a better driver because it has so many things that makes your life so easy driving the car, you become a better driver. But if you're trying to drive my first car that I had in Brazil, Which was, of course, I had to be a good driver because it was manual transmission and everything and so on.
If I would leave the door open, nobody would tell me. I would just hear the So I had to be a good driver. So I told the team, we are upgrading the user. So, and I always ask them, how does this make the Yard Planner a better Yard Planner? And if they don't get the answer, I said, think again.
[00:25:12] Merging Roles for Better Product Management
[00:25:12] Michel_: Another thing that you've talked about, and I'm sure we'll, we'll cover, more about your book, very soon, but, you've talked a lot about the different roles in the product management, space, right. Product managers, product owners. And, if remember correctly, you were, you're advocating for kind of merging these two roles, because, Based on your experience, it tends to lead to a bit to a blame game and other problems. In my experience,what I've seen is, and I think you've mentioned that as well, is that the, you know, sometimes you have P and E teams who deliver features, but we don't care about delivering features, right? care about the outcomes or the value that it creates, with all the years of experience you've had, what are your strategies or your approach to driving that accountability and making sure that, the team is really building something that is going to move the needle.
[00:26:05] Building a Collaborative and Accountable Team Culture
[00:26:05] David: The importance of this is on the size of the responsibility. So the responsibility should be challenging enough to encourage the team to learn and be motivated about it. So, And the team should be is small enough to be able to progress. So what I have seen happening, for example, I worked in a scenario where I was a product owner and there was a product manager and I worked in the vice versa scenario.
I was a product manager and so on. So what happens is in a scenario where the product owner has worked with the product manager, there's a big chance the team is quite big. There might be nine software engineers there and then they're really focused on the delivery. But in this case, your accountability is to ensure you deliver the thing right.
And the product manager has the accountability to find what's the right thing to deliver. But the truth is, delivery and discovery are highly intertwined. So discovery, I say, like, as Martin Kagan points out, it is about separating good and bad ideas. But once you start, you kind of de risk your idea a lot in discovery.
But once you start delivering, you are still figuring out some things. And some things will, wow, actually they don't really work the moment you scale to a bigger audience. So what happens now? With the product owner, go back to the product manager and say, start doing so. I don't think that works. I haven't seen that working at least.
And what I have seen working is instead of having a team with nine soft engineers and so on, quite a big team. What about having one product manager, a maximum of five soft engineers, one UX designer, and this team collaborate very closely. And then they, they need to make peace with something that is uncomfortable.
There will be a dual reality. So part of the team is trying to understand the future. So they leave kind of 80 percent of their time in the future, trying out things and so on. And they don't bother the rest of the team with all the things they have learned. But they bother the team with the things they think is worth pursuing.
And then together as a whole team, they come up with solutions and they try it out, but they are always exploring. It's a balance between problem solution space, present and future. And, this scenario drives accountability and the team is responsible for both sides, their present and their future. But you need to be careful with the size of responsibility you give to them.
Because if you give a too big of a domain. Then the team will be lost. Where do they go? What do they do?
[00:28:47] Fostering Team Spirit Across Departments
[00:28:47] Michel_: In my experience, I've been more on the business side of things, although I'm a lot more involved in product at the moment, and what I've experienced in general is this, normal, I guess, tension between, you know, product engineering and the commercial side. And I, always tell the team that we're on the same team, right?
That the competition is out there. And that, our job is to actually find the best way, to reach our goal or the best strategy and given the constraints we have, what have you tried that, you know, worked or didn't work to be able to navigate that tension and find a, you know, kind of a healthy, team spirit where, you know, engineers. Actually understand, the customers and what we're trying to achieve and also I think in my experiences, if you're on the business side or, or more sales driven, you control a lot the, out the input, the tool you use there, there's not as many unknowns than when you're actually in the developer product. So you also need these people to, walk a miles in the product and the engineering. shoes to, make sure that it's an effective and a healthy team spirit.
[00:30:01] David: Sure.
[00:30:01] Innovative Learning and Growth Initiatives
[00:30:01] David: It's highly important that I have been trying different things But the principle is You need to tear down the walls. There are no walls So treat everyone the same and create moments where they can collaborate. I mentioned already the progress update It is not an update on What the soft engineers have created and the product and so on.
It's an update for the whole company. Everyone is listening to the commercial team. Like what I have achieved, like how is the pipeline? How is it going? What they learn and they can interact with each other in that scenario and vice versa. So we are all in the same room. So this is one example. Another thing that we do also, we call it sharing and learning.
Once a month, every team shares what they learned. With each other. So the product teams will go there and share something that they find insightful and the commercial team will do the same. And then we share and we collaborate with each other. And then it comes something quite interesting. We have, also a growth session because I want people to help each other grow.
So we have a lot of talented people in the company that they could help the others level up. Sometimes we don't need to go to an external training. So we have a catalog. Everyone can teach something to someone. So sometimes commercial said, Hey, let me talk a little bit about inland terminals, how it is.
So they go and they present, they do exercise. What is it to be in a terminal? So, so you understand the users. That is another thing. And then there is an official moment. that once a quarter we meet in person in Hamburg because our teams are remote. So we'll have people spread all over the place. So we go to Hamburg and then we have what we call is get together.
Everyone from the company, all the 25 people that work together are there in person. And then we have exercises and the exercises. I mix all teams. And then it means that there will be a member of a commercial in each team, and the teams will be working with different people. And the more I do that, the more I get feedback.
Keep repeating that. It's very interesting to bring perspective. So there are no walls. We are all together, brainstorming, doing exercise, trying to, rethink the future, what we're going to do. So that's one of the ingredients I try to do. Apart from that, every soft engineer that joins us. In one this event.
We get them to go to a terminal and to see how things are in practice, to visit, to see the reality there. And whenever I have the chance to visit other terminals, and I generally try to get three different people there, a different perspective. So that's the approach I have been doing. I wouldn't say that it has been all the time without tension.
The tension exists. Every area has its intention. Sometimes are some heated up moments. But then we talk it through then we clear that and we learn from the heated up moments and we move on
[00:33:00] Michel_: There's always tension whenever there's more than one person involved in a project.
[00:33:06] Untrapping Product Teams: Insights from an Upcoming Book
[00:33:06] Michel_: Uh, you're writing a book entitled, on trapping product teams. Can you give us a glimpse of, what you cover apart from the 23 pages of strategy that may or may not stay there? And, when you, when are you planning to publish it?
[00:33:21] David: Sure So the reason I start to write in the book is because throughout my career Working full time for 11 companies and consulting more than 50 I realized that no matter where I have been Teams face certain level of traps, some they are aware of, and some they are simply unaware.
And I noticed many patterns on the way. So I thought, actually, I have seen many books that are good on what is a state of the art of product management. But I have seen only a few books saying like, how do you address reality, your scenario? What are the things you can do today for a better tomorrow, even if it's a little bit better?
Then I thought, all right, and then I was brainstorming with my wife. And then we came up with the idea, untrapping product teams. I started with a newsletter and so on. And the idea of the book is you have three parts. The first part is to recognize the dangerous traps. There will be traps. So first you need to recognize, let's look at reality and how do we recognize the dangerous trap.
And then the second is to overcome the dangerous trap. So I prepared the team. I equipped them. to move on from traps to the other. So I bring, for example, what are the key ingredients of product management? How can you mix them? How can you use them? That's the moment where I talk about strategy, discovery, delivery, measuring metric, measuring results and setting the team and so on.
And then it comes the last part of the book. The last part of the book is remaining untrapped because the truth is if we settle. and go to the comfort zone, some random traps will appear all the time. So how do we avoid that? And then I started this part of the book with product principles. How can you set product principles and how can you make them alive?
And then I give my examples of favorite product principles, and then we go to a series of health checks and so on. So that is the idea of the book. And when it comes out, that depends a little bit because I made a decision to go with a major publisher. We are targeting that by end of summer, beginning of fall.
I'm quite optimistic because I have been doing better reading so far and the content is getting rounded. But earliest, somewhere in August, hopefully latest, somewhere in the fall.
[00:35:45] Michel_: Exciting. looking forward to it.
[00:35:48] Prioritization and Backlog Management in Product Development
[00:35:48] Michel_: And you know, you talk about traps. I think back luck management, maybe one of them, but also for me, it's prioritization, as well. And I think you shared recently on LinkedIn. you know, you're using a matrix to prioritize. And, if I remember correctly, you say this is maybe more interesting than using, a model like rice or, the others. Can you tell us a bit about, you know, how you prioritize and also make sure that you keep the back lip clean?
[00:36:15] David: Sure. So prioritization for me, it starts out with, exclusion. So many people think what we should be doing. I like to start thinking what we should not be doing. So I have some anchors, you need anchors. So anchor, strategy, vision, goals. And I say, all right, let's go through here and ask questions. How does this help our vision?
And if the answer is, then ciao, and it's not later because whatever is good will come back. It doesn't matter. It will come back to us in a moment that is appropriate. And then I ask, like, how does this support our strategy? And I keep going on that. So then I will remove the distractions as I call, because things not supporting vision, strategy, and current goals, they shouldn't deserve our attention at this moment.
Then I go to the other part. Let's try understanding where we should invest our attention. And then I like matrix because it can give us categories and say, based on this, what we know right now, let's think on the potential impact of that. And let's think on how much we know about implemented. Because if we say the impact is high and we know little, we need to jump into discovery.
Okay. If we say that the impact is high and we know a lot, well, that seems like a, let's just confirm what we think we know and let's jump to create some value. But then when we look to things that they have low impact and we know little. So I say, just go there if you have no other choice, but start with the top and then you go there after.
So that's what I try saying to categorize and prioritize there and try learning on this. Generally, I pursue a mixture of delivery and discovery. and then we go from there. And the reason I say not to go with rice, ice or the others, It's because what I have seen, these methods can work well, you can say, what are the things we imagine to have to be more impactful?
What are the things we imagine to have a higher reach? But in general, what I say, people start looking at the numbers and they think the numbers reflect reality and they don't. So I say, let's not just invest time into this. Let's simplify because in the end of the day, I like what Ash Morial says, your unfair advantage is the speed of learning.
[00:38:40] The Impact of AI on Product Management and Development
[00:38:40] Michel_: that, I don't want to take too much of your time, but, maybe, a big or not so big question with everything that's happening, or the rapid pace of development with AI, we've been seeing, you know, over the past 12 to 18 months, do you think this will significantly change how you, manage product and develop new products?
Is this something that keeps you up at night or that, you know, keeps you excited.
[00:39:06] David: I don't worry about that. What I I see many opportunities and I see some things that, for example, backlog managers wouldn't have a place with AI. You don't need anyone to write requirements for you. I don't need someone to take care of backlogs and so on. And I can replace that because this is not thinking what I think is like AI will be an empowerment, not a replacement.
So for those who are good, they will become better. And I think I can help you identify where to go can help you. For example, you have loads of data. What are you going to do there? Can you search for opportunities? And I will be able to find this faster. But it's you need to know the questions you're going to ask.
And there is something that I doubt I will be able to replace in the short term, which is real contact with customers. Because one of the ways that I have learned the most and in my career is talking to customers, listening to stories and trying to see where the customers really care about. Other examples are about shadowing, going where the customers are and trying to create something that is natural, not rational, because I will be very good at what is rational and to come up with what is natural.
You need to have the human feeling, and I don't know how long that will take for AI. When I look at the terminals, for example, I remember a situation we had, we were talking about developing an application for one of the operators. And then people were talking about like, how you, how you create the interface.
But a soft engineer looked and said, Hey, but when I was in the terminal, I saw that the person has first is wearing a glove. And So it means that the touch will be impaired. And second, the sun is very strong. So we need to think about a device that will allow that. So this is something that they observed because they were there.
They could see this happening. So this is something that, we need to, the human, the human aspect. But if you are, if you have this combined with AI, that will be a superpower.
[00:41:16] Michel_: I agree. I think meeting in my experience, also meeting with customers has been, I mean, this is where you get the best ideas that you can, work hard and workshop, you know, with your team on the my rule board or in person. But when you actually meet the customers, this is where the. I think the magic happens.
[00:41:34] Advice for Aspiring Product Professionals and Startup Founders
[00:41:34] David: Maybe my last question before I let you go before, the weekend is, if you had to give a, an advice to a, young product, professional in product management or a, a startup founder, Who's, you know, trying to develop, a great product to solve a big problem. What would be your advice in terms of skills development, for startup founders, for people just joining the career. What I say is get hands on as fast as possible. Don't stay behind a computer screen. Don't do excessive mirror boards meetings because the tooth it's hard. You don't know what you don't know and you can only do it. Uncover that once you start getting hands on, because there is something that happens quite often that we start planning, strategizing and doing all of this.
And that, become a problem because it will make us blind to reality. And we, the more we invest into something like that, the more we are trying to prove ourselves right. And the truth is we are wrong to get hands on you. Try out as fast as possible and then let reality help you uncover the direction.
[00:42:54] Michel_: you so much for your time. I wish you all the best with Omoco and, the next couple of months. if we want our audience to follow you, I believe LinkedIn is your channel of choice.
[00:43:06] David: Sure, LinkedIn is a place you'll find there my newsletter and from there you'll go to all places, book and also my website and course. So start with LinkedIn, drop me a message and yeah, go from there.
[00:43:18] Michel_: Thank you so much. And, we'll, be looking forward to see what happens with, Omoco, but also, looking forward to reading the book.
[00:43:28] David: Thank you.
Business and tech news in 5 minutes or less
100% free. We don’t spam. Unsubscribe whenever.
We're a Growth and Product Design company whose mission is to transform businesses into designers of positive change. We offer learning experiences with online courses and coaching, do-for-you growth services, and a community of people who care and share about building growth systems and user-centric products and creating sustainable businesses.