David Pereira: Product Management or BS Management?

• Slides
• Transcript
• About the Speaker
• Join the BoS community

What’s louder: opinions or evidence? What defines success: meeting deadlines or reaching goals? What matters most: outputs or outcomes? How do you deal with failures: avoid or learn?

David helps you understand how to face reality and uncover opportunities to act immediately to simplify your product game. With candid insights and proven tactics, David empowers you to challenge the status quo and create the space to do work that truly matters. 

You’ll learn how: to simplify what gets unintentionally complicated; product organizations thrive or fail; to apply new insights today for a better tomorrow; to overcome common team traps. Get ready to rethink how your team operates.

Slides

Find out more about BoS

Get details about our next conference, subscribe to our newsletter, and watch more of the great BoS Talks you hear so much about.

Transcript

David Pereira 

Do you know who’s the best friend of product people? You may wonder who that is. It’s not Mark. I will tell you that in a bit. We are going to come to that. But before I tell you who’s the best friend and what it makes the best friend. I want to have a sincere conversation about the product game with you.

The Reality of Meetings & Value Creation

Our fear of the unknown makes this game way more complicated than it should be. How often do you attend meetings, resulting in just more meetings? Or do you prepare for meetings that you already know the result? People attending won’t care, and they will be thinking about something else, because that meeting is the last place on earth they want to be.

Now I want you to answer one question as honest as possible, even if that hurts. Please raise your hand if you ever thought that sometimes you talk more about the work, than you do the work itself. Raise your hand if that ever happened. I want to raise mine too, many times I finish my day and I start thinking about what happened. I didn’t know. I was pretty busy in meetings, discussing everything, discussing the cool new features and all of that. But then when I reflected, how did my work contribute to value? And the question is, who cares about value when features are all that matters, who cares? You care, that’s why you’re here today, isn’t it? But it’s very hard to create value when almost everyone and everything distracts you from it.

The Problem with Feature Roadmaps

I need to show you something. Have you ever seen anything like that? What do you think about it? Too small? This is a beautiful feature roadmap plan. When you look at that, you do know that a lot of people discuss this for aides. They talked a lot about the work. They talked so much that this became the truth. And this roadmap has good intentions. It’s supposed to help you achieve a goal, but on the way, something is going to happen that nobody will ever remember the goal. Then it happens that this roadmap is going to fool us perfectly. Following the plan becomes a goal. And then I ask you, what should you do about it? There are two things you could do. One, you cross your fingers, you hope for the best, and if you’re lucky, everything will be fine, but only if you’re lucky or you can do something else. But to do something else, you need two things: a lot of courage and the pinch of audacity. So what should they do about it?

Introducing “The Trash Bin” – What to Remove

Now, let me introduce you the best friend of product people. It’s a bit unexpected, but this is the best friend, you know, the trash bin. So it should start removing things that distract us from doing what matters. So this feature roadmap is just trash, so we get rid of that, and then we start talking about things that matter. So today I want to help you understand what should be in the trash bin and what should be present in your day. So remember, this is your friend. Whenever one distracts you, you should put more things here. But to talk about this, we must understand the theory and reality, because these are different things. And I like saying that the theory is something like the promised land.

Theory vs Reality: The Promised Land

Let’s start this conversation about the promised land. In the middle of everything, you have the product teams. Of course, this product team will come with different labels. In some place, they will be called as development team. They will be called sometimes as maybe scrum teams or product team, but these are the guys getting shit done. The promised land, one thing that happens is that these people, they can’t make decisions, and they are empowered to choose where to go. And how can they make good decisions? Because they know where they should land. They have a product vision inspiring them. And how do they know which game they’re playing? Because they use a strategy that will help them make decision. They can say yes or no to things. And what is the result of that? The result is that they will uncover something that is worth doing, that will create value for both sides.

Within that, product teams will partner with business. Everyone will be on the same page. Why can’t they partner? Because they have shared objectives. They have an outcome oriented role, not the one, I just threw it away. Because that’s going to distract everybody. They have clarity on what they should be achieving. And we haven’t talked about customers yet, but in this case, you’re going to talk to customers as often as necessary, and the result will be beautiful. You’re going to create value for everybody, for business and customers.

Now, who is in this part? Raise your hand if you’re part of the promised land. Who? I see someone a little bit shy, okay, but great. It’s very hard to be here. It’s really hard. Maybe the next one, I’m going to see more hands raised.

The Harsh Reality

The next one is the harsh reality, and what happens in the harsh reality? In contracts to the promised land, this team here is not going to be empowered to make decision. They are going to follow whatever decision I have outside them, and I had no idea why that happened, but they still have to follow this decision. What about the product vision? Well, that’s something nobody knows, because probably the product is positioned to serve everybody, and we end up serving nobody. And strategy, what happens to it? When they go to sleep, they dream about a strategy. That’s the only thing that will happen. And what will they do? They in and they out. They will cross their fingers and hope for the best because if the features are right, they are going to create great features. Because they are betting on features. They are not trying to solve problems. Create solutions worth building. Other conversations go around features. What about business in this part here? Well, in this case, you have to please the gods, because you are going to do whatever business says. That’s what happens. And remember what is inside here part of this, that’s how your roadmap will look like. Remember where to put it, okay?

What about talking to customers? In this case, you’re not going to talk to customers. You’re going to talk about customers. So what is going to happen? We go to more meetings and we speculate. We talk what customers would do? If I were the customer, I would do that. Because you’re going to talk to business and you’re going to clarify everything that customers should be doing. So talk to business all the time, and what is the result? It’s awesome, right? What happens out of this? You know what could happen. You maximize features nobody needs. Who is here? Raise your hand. Who is part of this? It’s normal to have elements related to that. But the good thing is that here we have a lot of founders and CEOs, and you can change that. Sometimes you arrive here involuntarily.

Moving from Harsh Reality to Promised Land

So I call this the harsh reality. With the first step is recognizing we are here. That’s the first step of everything. So you have the two parts here, the promised land and harsh reality, what do you want to do is to move from harsh reality to promised land. That’s what you would like to do, because if you’re part of the promised land, creating value is more natural. Because you have the elements that will enable you to get there. If you are part of the harsh reality. You’ve got to fight almost every day because things are distracting you. So the very first thing is understanding. I’m going to help you understand how to move from one place to the other. But let’s try figuring out how companies generally work.

How Companies Really Operate

When we look to a company set up, we need to understand how the dynamic is. So if you’re part of a big organization, just imagine that as a department or an area of your company. But what all companies will have will be multiple teams. Leadership defining where to go; customer service, you get all the complaints solved; marketing, to get the word out so people will understand their positioning; have operations, you keep things running; and product team that will come with different labels. You know that. But now I ask you, what do all teams have in common? Any idea? Customer, if they remember, yes that’s true. What else do they have in common? People? And what do people have all the time? Ideas. But not only ideas. They think they have the most brilliant ideas in the world. So everyone will have the most brilliant ideas in the world, right? And where do these ideas go to? That’s it, the backlog. They will go to the backlog, and the product team will have to talk to a lot of people to figure out what to get out of the backlog. And the question is, how do you deal with this scenario? It’s not how do we avoid that. You cannot avoid that, this is going to be part of your day. It’s how you deal with that. And that’s what I want to answer.

Two Ways of Working: Coordinative vs Collaborative

And generally I say that there are two ways of working. One is a coordinative way, and the other is a collaborative way. We will start exploring the coordinated one. The beginning is always the same. There are more ideas than capacity. That’s what happened. And the question is, what are you going to do about it? The most common way is to go in meeting rooms and discuss, and you discuss exhaustively until you find the best idea.

Story: The Dangerous Poker Game of Prioritization

Which reminds me of a situation I had once. We were in Brazil and we are company that we had trainers that will travel all over Brazil to train the Salesforce of brands like Samsung, Philips, Adidas, Nike and so on. And once a business analyst pitch an idea, very well, said, like, you know, every trainer has a different spreadsheet, and then I have to take that, consolidate the data and send the report to customers. And that sucks, takes a lot of time, and customers are annoyed.

And we said, what if we digitalize that? That was our idea that got prioritized. And when this gets prioritized, it’s a dangerous poker game. You go all in, and you say, I’m going to go all in and I’m going to do this. And then we spend a lot of time doing what? Design. But this design is inside out, so you start thinking, how should be this training portal? And we talked a lot inside the organization, what does it look like? What should it be, and so on.

And you know, when we got the right blue tonality and the buttons corners were rounded enough it got approved. Then we could do what? Time to do some user tests, but at this moment, we have already fallen in love with the solution. Then you say, Let’s validate our solution. And guess what happened? If you go with a validation mindset, you’re going to validate your solution. Everything is perfect. We validated the solution. It’s true that we changed one button from the right to the left. We updated a little bit the copy here, and so on and so on.

Then it comes the next thing that happens, you need to throw this thing over the fence to software engineers, and you expect them to receive that with wide open arms. But what happened? There’s a fight. Software Engineers will look at design and say, why on earth did you choose this bloody design? This is way more complicated than it should be. This is going to take me three months. I could do it differently in one month, or maybe even faster. Then, what did I do as a product manager back then? I had to moderate, I had to facilitate the fight. And eventually we made so many compromises that nobody was happy, but we got tired of discussing, so we moved on. So it was time to launch. But when you’re a part of this, you make a big thing out of the launch, because it’s beautiful. Invested a lot of time, so getting from a prioritization to launch takes months.

When Beautiful Solutions Fail

Said, what if we fly to the south of Brazil to present this to our trainers? It will be beautiful. It’s a great solution, a training portal that all of them will use no more manual reports. So it was a room a little bit similar like that, with 70 people, and then I was presenting the solution, and everyone was skeptical. There was no smile in the room, I didn’t get what was going wrong. And then someone said, All right, I understand. It’s a web solution and so on. Looks cool. I said, all right. But came the question, How am I supposed to use that when I’m on the move? Because that’s the only moment I have time when I’m on the bus to another town where the internet sucks and it doesn’t work almost all the time, or when I’m flying, which is the moment that I feel the report, and then I was actually doesn’t work if you don’t have good connection. So then I cannot work with that.

What happened is that we confuse the real jobs, the customers, we didn’t talk to them, and what is the result of that? The result is that you create a very beautiful piece of crap. And funny enough, what is the next thing you do after that? You go back to a meeting, and you prioritize again. You select another thing. And what is the problem here? The real problem is that you’re going to create a lot of features nobody cares before you find something that people would care. When you are part of this situation. Now you might be thinking, I don’t do that. I work with agile. I use agile framework. I will tell you these things happen regardless how you work. Maybe you have seen something like that, or maybe I’m just stupid.

Bullshit Management Defined

But at some point, I was thinking, Am I doing really product management? Am I creating value for users, for the business? Am I doing like this? And I realized I was not doing product management at all. And I didn’t know what I was doing. And I was thinking, who is the antagonist of product management? I didn’t know what was the name. Then I came up with something, because it was very painful and embarrassing. I thought, when I’m part of this situation, what I am really doing is bullshit management.

And now you may wonder, what is bullshit management? Am I doing that or not? Bullshit management is an art. It’s the art of doing things that bring no value but drain your energy. That’s what bullshit management is all about. I see some of you moving on the chair, and you are wondering, Am I doing bullshit management? If you don’t know how what you do contribute to value creation? Anyhow, you already know the answer. And there’s an equation behind it, and you should know this equation. It’s very simple, but very important. The more bullshit you handle, the less value you create. So you need to recognize what is distracting you from creating value and what is helping you. Reality is that bullshit is just all over the place and you can’t escape, but you can deal with it.

The Backlog Problem

Today, I want to talk to you about three common things that are going to distract you. The very first one you already know is this guy, the backlog. The backlog is supposed to be a vehicle to drive value, but generally it becomes a distraction to what really drives value, because it’s just follow whatever is in the backlog instead of asking what matters most right now.

Traditional vs Lean Backlog Management

So there are two ways of handling the backlog. I say one is a traditional way, where you have the backlog in the middle of everything, and you have all the promise in the world – old, new and so on. When you are part of this, what happened is your backlog keeps piling up. Never get smaller.

Which reminds me of a conversation I had with my godson close to Christmas several years ago. He was six years old, and he looked at me and said, You know what I want for Christmas, I want a Marvel cap. Marvel cap, cool. That sounds nice, said, but I also want Captain America socks. Could see the steam, but then he kept going, said, but the other day, I watched that movie Maverick with Tom Cruise, and he had this cool Ray Ban. I want that. I want to be cool like him. I said, All right, stop there, so that I have only two more things, a PlayStation 5 and strawberry jam. And I was just picturing the kid, six years old, wearing the Marvel cap, Captain America socks, Tom Cruise Ray Ban, PlayStation five, and eating strawberry gym.

Then I had an epiphany, when I look at my backlog. It was not only a six year old wishlist, it was a marketing wishlist, operations wishlist, customer service, finances, leadership and everything else. I said, How can I create value with that? Then I came up with a different way of treating backlog. Said, we need to have a lean backlog management. The very first thing is you need to separate the old from the new. And then what do you do? Like whatever is old you say, here it goes. Get rid of that. If the leading is too scary for you, archive at least, but don’t look at that.

And now you may wonder, what is old? That depends on your learning speed. If it takes you a month to learn, then everything that is older than a month is good to go. If it takes you three months, then that’s it. What I like doing is the following. I create a routine, and I instruct all product managers working with me. Every Friday, you create a filter and whatever tool you use, things untouched over the last three months, you just filter them and you say, ciao. But that’s not enough, because you still may have a mix of Christmas wishlist there.

What about the goal? Whatever doesn’t support your goal, here it is, your friend. But did you hear I said goal. One, singular, not plural. And what happens very often is that we have goals, priorities, top 10 priorities that complicates decision making. A team should know what matters most right now, and that is what they are going to say yes to, and then they are going to have a lean backlog manager. So definitely, you don’t want to have a traditional backlog management, otherwise you become a backlog manager.

So you want to have something a bit different, a mindset that will help you is how you treat your backlog items. I know that some people here in the audience like wine, but I would say, don’t treat your backlog like wine, because wine, the older it gets, the better it becomes. But backlog, the older it gets, the more confusion it creates.

Backlog Items Age Like Milk, Not Wine

Now I tell you a brief story, it happened when I arrived in Germany. A few months being there as Senior Product Manager for an E commerce product, a software engineer came back after maternity leave. Two years, two years in maternity leave, she came back. It was a middle of a sprint, and she came to me and said, David, what should I be working on? I don’t like feeding software engineers with tasks. We agree on something to achieve for the time, and then we collaborate towards that. But I didn’t know how to answer that, because the team had already agreed how to move on. I promised her I would come back to her, but then I got stuck in meetings. I didn’t come back to her. The next day, during the daily stand up, she looked at me and said, I took this ticket, I refined two years ago. And I started working on it, and it was about implementing a new transaction of email. And then I just did, like seriously? The problem is that we had a nickname back then, spammers. And she just picked a knight and to implement a new transaction anyway. Why? Because it was in the backlog. She said, I refine that. I can work on that. I know what to do, but you want people to work in the right direction, so what you need to do is to treat the backlog like milk. You know, they spoil very fast, and you get rid of them, if it’s worth.

Calendar-Driven Framework

So the principle you should follow is this one – backlog items age like milk, not wine. That was a principle I co-authored in the Agile product manifesto with people all over the world. It’s very interesting because this product manifesto had people signing from different industries, finance, automobile, cloud, platform and so on, and that was the one thing that everybody could agree that the backlog distracts them a lot. But that’s not the only thing. Sometimes, we think we are following different agile frameworks. But there are frameworks in disguise that they are the reality. Do you know what is the most used framework in the world? At least the one I believe to be the most one. Do you know what it is? I think it’s this, CDF. Have you heard about it? Calendar driven framework. So it’s a calendar driven framework, and it works very easily. Whatever is in your calendar is what you do. So people put meetings in your calendar, the book slots, and then that’s what you follow. You forget about everything else. You just follow what is in your calendar. You become a victim of your calendar. And I want to ask you a few questions. How many hours a week do you invest in meetings? If it less than 20 hours, raise your hand.

Oh, that’s good. Between 20 and 30, I need some prioritization. More than 30? I think that’s getting more serious.

All right, then it’s a different kind of cheating. But what happens in this product game? Like you do need to collaborate with people, so you’re going to have some interactions. And I know the word meeting is getting like a negative connotation. Now we want to have more working sessions, but one thing that we want is like meeting is not the first choice to collaborate with everybody. But if you’re having too much time inside meeting rooms, when do you have time to think deeply? When do you have time to analyze insights? You have to reflect? You do need to have some other type of work.

So what teams think they do, in general, is following different frameworks. It doesn’t matter the framework or whatever they think they’re doing that and what has happened is this, and I have a theory of why this is happening more often today. We need to go back prior to pandemic. When teams work in the office, there were physical limitations. For example, there were a number of meeting rooms you could book. If the meeting room was booked, you would figure out how to get what you wanted in a different way. You would just not book a meeting. And there were also limited chairs. And now what happens? We have virtually unlimited meeting rooms with virtually unlimited chairs, so you have more meetings with more people, very productive, right? And then you have soft engineers cursing a lot the frameworks because has a lot of meetings, it sucks their energy and so on, and meeting is the last place they want to be in. So we need to ensure we don’t become a victim of our calendar.

The Fear of Saying No

The third thing that happens very often is our ratio of saying yes and no. So it’s the fear of saying no to reflect about it. I generally say a good rate is like for every as you say you said no at least nine times. So it’s a balance like that. It’s important to understand the consequences when you say yes and no.

Many people ask me, like, when I’m coaching product people like, what makes a good product professional? Generally say is your ability of saying no while keeping the relationship sustainable, because saying no is one part, but keeping the relationship sustainable is the challenge. Now I give you two strategies, and the very first one is something that doesn’t work at all. And I did that. I realized that I was having too many things to do, so I said, I need to cut that. Said, I’m going to say no three times to everything that comes my way, if the person bothers coming the fourth time, it means it’s important. What happened is I indeed reduced many things I had to do, but then I got a nickname, The business blocker. It’s not a nice nickname you want to have. And the reason that happened was because my boss received too many complaints about me. That was sad.

But how do you get out of this situation? You help people say no to themselves, and you ask questions. For example, someone comes to you with a crazy idea, you start asking, how does this help us achieve this goal? Which problem is this thing trying to solve? What is the expected outcome? How many clients are impacted by that? How much do they care about it? How often do they face that? And how do you know this is the right thing to do? You may help them get the answers. They probably won’t have the answers. You can’t help them, but you should not say yes without having that. It’s like Ryan said yesterday about framing so you want to understand where you’re stepping into before you say yes. And the mindset I recommend is having this – every yes you say is a responsibility you take, while no is a decision to remain focused. This is a thought inspired by James Clear, the author of Atomic Habits.

Bullshit Management Check

So we talked about three common traps that happen. So it’s the extensive product backlog, transforming teams into feature teams, the calendar driven framework, and the fear of saying no, but there are more. So what I like suggesting teams to do is to run a bullshit management check. So for example, if you look at your workflow and you have something called PO or PM approval, just get rid of that step. Software engineers don’t need anybody signing off their work. They need people providing context so they know what they are trying to solve and they can make decisions. And talking about decisions, how do you make them? Do you make them based on opinions instead of evidence? So you want to move towards evidence. And I know that some teams, when they run that they are here on this part, and they start panicking. And I say, that’s the game, and dealing with bullshit is very challenging. It’s more like an art. So you choose one item here that sucks your energy, and you say, I want to do this different. If you’re trapped in a meeting marathon, you say, I want to take over my calendar. I want to be more mindful. I want to regain time. If you have a lot of backlog items, just use this guy here.

What Makes a Good Product

So first thing is, you understand the situation you are in, then we can get out of that. And how do we get out of that? We need to understand what makes a good product, a good product. Had a lot of good conversations about it here already. So my best explanation of a good product comes from Kathy Sierra. You should not upgrade the product. You should upgrade the user. Don’t build better cameras. Build better photographers.

When I think about the products I use, they somehow contribute to make me better at something. I use Grammarly, not because it corrects my typos. I’m not a native English speaker. I come from Brazil, but Grammarly helps me become a better writer. I use Canva, not because it has cool images there and so on. It makes me a better communicator. So that how it upgrades. So you can’t think about the app, the product, which user are you upgrading, and how are you doing that? And then you can get to the question, how do you play this game?

What is Product Discovery?

Now, going back to the ways of working. Remember the collaborative flow, the coordinative flow, which we talked before. You know you are there. When you have a few things, you talk a lot about the work, and there are several handovers between areas. And the collaborative is different. You may start the same way, with more ideas than you can handle. But instead of betting one idea at a time, here you want to understand the most promising ideas. The very first thing you want to do is to filter out distractions. So you want to look at all of your ideas and say, How does this idea relate to our vision, where we want to be, doesn’t relate to get rid of that. How does this idea relate to our strategy? Doesn’t support, out. How does it support our current goal? So you keep this doing this exercise, so you filter out distractions, and then you move to the next. And this exercise is not something that should take you a week. It should take you just a few hours, maybe one or two.

Learning Through Experiments (Including AI Use)

The next thing is about learning. And when it comes to learning, you want to uncover a few things. Do customers want that desirability? How do you know they want that? Start exploring more these you can run customer interviews survey. You can try learning from customers. What about business value? Can you collect value from that? Things that you cannot collect value or customers don’t want, or within the constraints you have, you cannot implement, meaning feasibility, you get rid of them at this moment. And then you remain with fewer ideas, so you make gradual investment. So you move from up front, bad, high investment to gradual investment. First invest a few hours. Then here invest maybe a couple of days.

And then you say, let’s run some experiments, something more robust. And here is where you can use AI, a lot to support you, but you want to test your ideas against reality in different ways. So first you build to learn, then to scale. And you’re going to realize that some ideas, they are not going to deliver the value expected. So you get rid of them, and you keep doing this exercise. But then there will be one or another idea that will survive this part and iteration. Then this is the one you should be launching. And the secret here is about separating the bad ideas from the good ones, so you can invest on the good ones. So that’s the difference. You make gradual investment. But to be part of this, you need to have the fundamentals of Product Management well aligned. And that’s not complicated.

You have three things only that you need to have well in place. The fundamentals of Product Management. First thing is strategy, and the strategy is all about simplified decision making. When people look at something, can they say yes, true or no? I’m coaching a client, and it was very interesting. I did an exercise. I call this the product health check, and I asked people like, how often do they use this strategy to make decisions? Almost everybody told me every day, so that’s cool. Describe this strategy in a few words. 30 people replied to this, and there were 20 variations. So you need to have a unified understanding of strategy. The word might be different, but the meaning should be the same, so they can see yes and no to.

Strategy, Discovery, Delivery – The Three Fundamentals

And then after that, you have discovery, which is all about uncovering what drives value, which problems you want to solve. And then you have delivery, which is not only creating features, it’s about shipping value and these elements are intertwined. It’s not a process. Depending on the maturity of your product, strategy will evolve faster. For example, if you are a startup trying to go to the market, you need to prove market fit, so you may tweak your strategy way faster. But if you are in a mature product market, it’s different, but you still need to learn and receive the sign.

Product Discovery as a Journey

For today, I want to talk more about product discovery, because this is where a lot of opportunities lie. And the product discovery, I say it is a journey, not a process. And as all journeys, we start with the goal, what are you pursuing? But the goal sometimes become a little bit fluffy. For example, we want to increase conversion rate. All right, just drop all the prices then. But what are the trade offs you can make? You need to understand three things where you want to land, the trade offs you can make, and the metrics you need to protect – the guardrail metrics. So you clarify the playing field. Once you have these three, then you start going to talk to customers and understand your audience. Ryan talked a lot about it.

Understanding Customers & Value Drivers

So what are customers trying to achieve in their scenario? I think there was Melissa yesterday talked about nothing happened inside the office, something like that. Nihito, there was a nice part there. So get out of the office and talk to your customers. Because what you want to understand here is what is natural instead of what is rational. Because if you create things inside meeting rooms, they might be very rational, but if consumers don’t get that naturally. It’s not going to work.

Prioritization as a Bet

Within that, you uncover what I call value drivers. Value driver is anything that deserves your attention, a job worth investing time and so on. People use different names for that. Some people use opportunities. The reason I use value driver is because it’s a good reminder for us, if we don’t know how something drives value, it’s a good sign we should not be working on that. But then it comes reality. There’s always more we could do than capacity, even with AI, there’s a lot more we could do. We need to prioritize. And prioritize, for me, is more like a bet. So you can use different frameworks for that, but I like having a better conversation to understand the opportunity we have. Take your ideas, you can use a matrix and so on, but you need to have a conversation on, how often do customers face that? How much do they care? How satisfied are they with the current solution? What are the opportunities you have? How much value could create for them? And so on, and understand your strategy. And within that, you can talk about the future.

Ideation, Assumptions & Evidence

Here’s the moment we start talking about real solutions, and that’s the moment we can also leverage AI. You need to be careful on this part, because it happens very often that we have an ideation session, and then the result is, we decide to go with the most boring idea that everyone can support but no one likes. So I would say, let’s try at least three ideas, within the mindset that we are going to hit reality and learn. And we have assumptions behind our ideas. Assumptions are beliefs we have but lack evidence. The thing is, when we don’t test assumptions, we may have unpleasant surprise. What I like saying is that untested assumptions are the mother of fuck ups. We assume something is going to happen. It doesn’t happen. Then we are all crying. So that’s why we need to confront critical assumptions against reality, and then we decide based on evidence. So you don’t want to decide based on opinion, you want to decide based on evidence. And this is not a process, as I said. It is a journey. And you are the driver, and as a driver, what do you do? You decide when to drive forward, backward, take a left turn or right turn, how long you should stop in each part? It’s your choice, but these elements will increase the odds you create something that matters. What you should avoid is being the passenger and not knowing who is driving that.

Three Health Checks: Strategy, Discovery, Delivery

This game is very hard. We all know that, so what we benefit from is if we are humble enough to step back, reflect and understand our reality. So I’m going to give you three health checks that can help you understand what is going on in your scenario, so you can spot place you could work.

The very first health check relates to your strategy. What is the ownership you give to people? Are they accountable for features or for impact? This will drive different responsibility, different attitude, and what about prioritization? Do you tell them what they should do or what they should achieve? Prioritization is outside the team. They will be decision followers, not decision makers. And when they are deciding, how is it? Do they focus on making the perfect decision which leads to analysis paralysis, or they just focus on progressing, and then they learn and adapt all the time. What about goals? Do you have it clear for your for each of the team, what they’re supposed to reach, and then they can use that day in and day out? And how do they work? Do they work in a coordinated way, handing over activities to each other, like I described in the beginning that you end up with a beautiful piece of crap or more collaborative way? So this is about strategy.And if you are on the red then the first thing you should do is to create a go, give the team a go, and from there you can adapt the other things.

Now comes your discovery. First thing you should know is about the value proposition. Is it clear for everybody, what your product is up for? Because if you have a clear value proposition, people will be empowered to make better decisions, how to get there. If not, it will be very hard. And then it comes customer interviews. You definitely want to talk to customers, but you want to equip your people to getting signs from the conversation. Just talking to them is not enough. You want to learn. What about assumptions? When was the last time we talked about it? Prioritize and then run experiments. And then you run ideations. What is the result of ideation? One solution, the most boring one, everyone can commit, or multiple solutions.

So once you have this, you can move on. But if you think like, I am on the red here. Where should I start? I have a feature roadmap, like the one who threw it away. I don’t know where to start. Start by naming assumptions. You don’t need to ask for permission. Just do it. Name assumptions, test them, and then you talk about what you learned that will give you space to gain experiments.

Delivery Health Check

And the last is the delivery health check. Delivery health check starts with implementation. What is your attitude? You build it right from the beginning, it takes very long for you to learn. Or do you have a mindset a little bit audacious, that you first build to learn, then to scale, meaning that you say, I’m going to use technical debt as a tool that helps me put something in front of a few customers and learn if that makes any sense. If it doesn’t trash bin it is, if doesn’t make sense, I pay the debt off and move on. What about results? If velocity is all that matters, it will be very hard to create impact. And now an important question, when was the last time you removed the feature?

Many times, we keep adding things to the product, but we don’t remove. There are many people who think a great product is the one you have nothing to add because it has all the necessary features. I actually think a great product is the one you have nothing to remove, because it gets a job done very well. So you need to understand if every each feature deserves to be there. What about failures? How do you deal with that? When you have failure, do you avoid at all costs to make your process even more strict? Or do you learn from them?

The best explanation I’ve ever had about failures comes from Alexander Stovallder, who is strategizer CEO and his book The Invincible company, he said, avoid big failures or you’re dead, embrace more failures, or you’re dead.

The last part of the product delivery is the backlog. How do you treat that? If you look at their backlog and you see the picture of my godson wearing the Marvel cap, Captain America socks, Tom Cruise Ray Ban, eating strawberries, and playing Playstation 5. You know what to do with that backlog.

Your Choice

So this game is pretty hard, we all know that. And that’s not going to change, but we can change how we answer to the challenge presented to us. Generally, I say there are two ways you can just complain about everything that happens, or you can take risks. Do things differently, because you always have a choice. You can be the victim of the circumstance. You complain about everything nothing is going to ever happen. Or you can be the hero of your story. It might be that you hit the wall a few times, and that hurts, but then you try it again, and you have a chance of acting today for a better tomorrow. So I leave you with one question, what is your choice? Thank you.

So for those of you who don’t know me, I’m David Pereira. For now, I am a product coach and advisor. Because one thing that happened recently, based on what Bob said, job moves. I have been playing this game for 17 years now, from software engineer to CEO. And then over the last year, I was reflecting what gives me energy. What gives me energy, it is about helping people grow. What gives me energy, it is about transforming this game. And you know what I did, I quit my full time CEO job, and now I’m on my own. So if you want any help moving from the harsh reality to the promised land, just drop me a message. Maybe we could rock together.

Mark Littlewood 

Let’s stick your hand up if you’ve got a question, I’ve got an agenda here as well, not an agenda.

David Pereira 

So as you had the question. Last year, I wrote a book because I was very tired of what was happening in the product game. Many people telling us what we should do and so on, and I realized that I just screwed up product my whole life, and I learned many lessons. So I wrote a book about hope that we could act to do something different. It’s calling Untrapping Product Teams, and today I brought a few copies. If you want to buy a signed one, you can approach me. I have some here. Maybe you enjoy.

Mark Littlewood 

You mentioned Kathy Sierra in your talk. You mentioned Alex Osterwalder in your talk. They’re all very good friends of BoS. If you go to businessofoftware.org/talks there’s probably three or four from Alex from Strategyzer, and there’s certainly three or four from Kathy Sierra. In fact, her whole or her latest book a while ago now, but her last book was inspired by you lovely people at Business of Software, and you are mentioned at the end of it.

Audience Member 

You mentioned using AI and experiment phase to support you. Can you give some examples of how you might do that?

David Pereira 

Sure, like before, we would run experiments, for example, prototypes using different paper prototype. Today, we can just use lovable, bold and so on and create an interactive prototype. It’s actually code and so on. So instead of taking days to prepare something, can do that in minutes, and then you can send a link to somebody and see how they react to that. So there are many other tools coming out and helping do that. Miro is also doing that, as they recently bought Wizard IO, so you can do all integrated. Many other types of tests and so on. There are also, for example, synthetic users, where you can run interviews with different profiles and so on and learn. So there are many tools out there that accelerate us, mainly on the prototyping is fear.

Mark Littlewood 

David, thank you very much. Thank you.

---

---

Upcoming Event

BoS Europe 2026 🇬🇧

13–14 April • Cambridge, UK

First speakers announced.

Get Tickets