Join Murray Robinson and Shane Gibson in a conversation with David Pereira about Product Leaders. Successful Product Leaders don’t write requirements; they define the problem, set a goal and empower the team to get the job done.  Be curious about customers’ problems but don’t take their word on the solution. Constantly test your assumptions with prototypes. Get your ideas in front of a customer early. Start with low fidelity and only enhance it when it shows value.  Focus on outcomes, not deliverables. Measure value with leading indicators not lagging ones. Empower your team to solve your customers problems better than anyone else

Read along you will

Shane: Welcome to the no nonsense agile podcast. I’m Shane Gibson. 

Murray: And I’m Murray Robinson. 

David: And I’m Dave Pereira  

Murray: Hi, David. Thanks for coming on. Um, so we want to talk to you about agile product management today. 

Um, but first maybe you could tell us a little bit about who you are and what your experience is.

David: Okay. So let’s say I am a passionate product leader. I have been, and this era for 10 years now, 

and before that I 

was just a software developer. I have been in different scenarios from startups should be corporations like from 30 people to a hundred thousand different business model, different countries, Brazil, Columbia, Dominican Republic, and now, and Germany.

So I’m leading a team of product managers. And trying to deliver value. That’s who I am. 

Murray: Great. And, um, I read your article about, uh, calling for a product manifesto 

and it just triggered a few, few 

questions for me. So, um, first of all, I mean, you’ve been working in agile for quite a long time. Haven’t you?

David: Yeah. I have endured. But at least 15 years in total.

Murray: and you write for serious scrum. So you’re, you seem pretty involved 

in scrum.

David: Yeah. Um, I have been working with scrum since 2011 2011 and, uh, Let’s say kind of a giant, a little bit before when I was software developer and, uh, regarding to, uh, writing a writer to series is grant list once a week, since 2020 and also UX collective and some other publications. 

Murray: Oh, great. Okay. So what’s the problem with scrum from a product managers point of view. 

David: At scene complete by design. The problem is who is driving the car, right? So it’s crime can be great, but if you 

don’t apply product 

management techniques there, you won’t be able to deliver value. 

Murray: Okay, but can you be more specific? What are the gaps? 

David: It’s crunch tell you what to achieve, not how to do it. For example, product owner is responsible for maximizing the value 

resulting from the 

work of discounting. But how you’re going to do that. Well, you’re on your own if you’re not off, so inspect and adapt, but it doesn’t tell you what outcome is. It.

Doesn’t tell you how you can measure the results or how to prioritize it. Even doesn’t use the word, prioritize it, or use the word sorting. So it leaves a lot of space for interpretation. And that is the danger of. 

Murray: Yeah. Well, you certainly say a lot of people using scrum as a feature factory. Diane. 

David: Yeah, exactly. Because for example, the name, uh, Agile is quite tricky because like 

people 

connect with speed and then scrum brings the sprint and then that goes to more speed and then maximizing the value for some stakeholders. For example, it’ll be maximizing the amount. Features develop. So it means that we start doing squat and then means we start doing more features, right?

More velocity, more star points at the end of its sprint. And that’s it. And then product teams are trapped. Um, stakeholders, tell them what to do. And then they implement for me. This is something kind of weird. So the specialist, uh, is receiving the solution to implement without knowing the problem to solve 

Murray: Yeah. And I hear people talking about tickets all the time. Have you written a ticket? Have you done the ticket? Where’s the ticket at? How many tickets did we do in JIRA? Usually?

Shane: That’s because everybody’s using JIRA, right? So that’s a help desk system. Yeah. You know how I feel about JIRA? It’s one of my, 

uh,

mini dislikes of the agile world

is that we treat the work to be done as I hope these tickets. And so we have a 

piece of software that supports that paradigm. That’s ridiculous.

Murray: I don’t 

David: Yes. Uh, 

Murray: actually go on you tell us what you think about Gera.

David: I think it’s a great two, depending how you use it. So at can, uh, help us progress. Uh, for example, organizing 

our work, just having a backlog and so on But it can get quite complex. For example, with the workflow I I’ve written about Dera and I’ve seen some workflows. I have used some of them that are quite complex and then Dera gets in the way of collaboration because people, uh, fall in love with the process and.

Whenever there’s a problem. For example, ah, we had an issue with, uh, quality assurance. So let’s create a new status in JIRA, and then let’s ensure that we do that instead of addressing the root cause. So this is all what I fear about JIRA. And there is certain resistance from team, because at some point in time, I said, let’s just stop using juror.

Let’s just use a bar to create a Bard. And then we put the Delaine’s you do doing, uh, and then done that. That is what we need. We don’t need more than that. And I faced some lot of resistance people, uh, developers, no, we need JIRA because then we can comment on the ticket and put everything. And then the process becomes more important than actually delivering value.

So this is what a scary. 

Yeah 

Shane: I’ve got a grant. So that’s, we, we try and use the tool to fix the process problem, you know, working with a team, a group of people at the moment we, um, uh, my role is to be on the team for a change. Um, and we have a problem with dependencies across the squad. So the handoff between you and so we shouldn’t have handoffs.

Right. But we do. And, uh, so the handles aren’t working, so we raised it. Uh, we all had a great chat about it and somebody’s answer was, well, we should all be using JIRA and we can link out tickets. And as I said to them, well, we probably want to get our way of working, get our process, sorted food. And then when it’s working, we can automate it with a tool like JIRA, but forcing everybody to create tickets and link them is not going to solve the root cause of the problem we have, which is we’re not handing off our work properly in a way that we understand what we 

need to deliver to which squad wins. So I’m with you, right? We tend 

to jump to tools rather than 

process and, and ways of working, uh, as our default way of trying to fix problems.

David: And do you know, there’s another thing about this pattern You’ve mentioned the word ticket. Let’s say there’s a problem production and then someone. 

Uh, creates a ticket. And then the developer said, this is not a bug, that there was an expected behavior. And then the conversation goes and arguing whether that is a bug, it’s a task or, and you store it.

But the problem, like, I feel like the house is burning and we’re talking, what is this? Is it fire? Or is it what is happening? Nobody’s taking it action Like to take care of a fire that is a red happening. So this is what scared me. No, this is not a bug. We cannot report a bug, but we need to put as a request change and then we will deal with that.

So I think this, this, this, uh, behavior is against a giant product. Management is all about delivering value. It’s about following a process. 

Murray: Yeah, I think the agile manifesto itself has, has some responsibility here, not just scrum, um, because agile manifest, I mean, it has one line in it which, which talks about delivering value to customers. What is it about the first principle is. Um, Al highest value is delivering. I can’t remember, but delivering value to customers early and often something like that, but then everything else in it is, um, 

you know, it it’s really about software development and it’s assuming that the people were delivering value to, are Stakeholders business people within the company?

I think so. I think because it was written by a software developers, they just assumed that business 

people knew what had to 

be built. And so we just need to make sure we work closely with them, but you know, this is, they can be wrong and they

David: Yeah, and that is it. That’s what I think as well. 

The problem we had in 2002 is 

different than the one we have now, like developers 

struggle, um, to, to create software with quality, but, and collaboration of stakeholders was more like a service provider, um, relationship. So I own the solution and new implemented.

So this is the problem they trying to dress the tusk created by developers for developers. I think.

it did a good job back then it changed a lot at increased collaboration. But when I look now, I see many teams trapped. You take one of the principles of a German festival. Working software is the primary measure of success, uh, progress or success, something like this.

And does it lines software can be working and can still be not used by anyone. For example, we are not delivering value at all. And this is what scares me. If you follow that blindly. Yeah. You may not get what you need. 

Murray: Well, you might’ve seen the research by the Standish group, which, which shows that, um, something like two-thirds of product features are used rarely or never. And also there was some recent research by a company called Pendo who, uh, Run applications in the cloud for other companies. And they’ve found very similar things that in something like 70 or 80% of the features in their customer’s products were hardly ever used.

So we seem to be still even today, building huge 

numbers of features that people don’t use.

David: Yeah. Um, and this is because of how the decision process happened. So executives define prescriptive roadmaps, and then teams implement that the, uh, teams may collaborate very close to executives and stakeholders, but it’s on the solution level. So the problem is unclear what to deliver. It’s a feature, not an outcome.

And then the deliver. And what I have observed is a fear, a fear of. Um, for example, losing work. So you, you put the feature, uh, live on a product and then nobody use.

but you put your energy there. You’ve worked hard for that, but nobody is brave enough to remove that to duplicate. So, and, and, uh, for not like, for example, I think it’s, um, people perceive a great product as a product that has nothing else to add.

And for me, this is a faulty perception. I think a great product is one that has nothing else to remote. Just look at a Google. What do you have there? You have a text input and then you hit enter and you’ll get your results. So they try to make it as simple as possible. But what I observed. is people think that you need more to get more results.

And I think more cause more confusion, distractions. And then, and users will question, what is the need for me? I don’t know. I see so many features and they get puzzled they quit 

Murray: Yeah, that’s certainly true. The other problem, I see, I wonder if you could comment on. Um, if you talk to people, who’ve come up through product management, um, in marketing and who really haven’t had any exposure to agile. There is a, um, a very siloed mentality. I think, you know, you have a. You’ll have, uh, a research product DNA, you have a technical product.

So I’ll start again. So you have, you, you typically have product management divided up into a product manager who does customer research and marketing, and then a technical project manager who does delivery, um, of a product spec So even today I’ve seen, um, there’s on white and I mean, but there’s somebody who claims to be a champion and thought later, 

product management, who, who has a book that talks about how there must be this separation between product managers and developers.

And I was wondering what you thought about that.

David: I have a very strong opinion about it. I think it’s, uh, one 

person must be responsible for entering. From the discover process until, 

uh, creating value. I mean, to, to the delivery. So what do I say like that? Uh, I think it’s one bus, one driver you cannot have kind of have two people drive the bus to, create confusion.

And the more people you add, uh, and delay, it created lack of responsibility to stick an example. Someone is responsible for that scope. Let go this as a product manager. This person defines what to do, find the right things to do. And then a product owner will be responsible for the execution. And then he will ensure that the thing is done, right?

This is what safe claims, what I think is faulted. And the reason I think this is not working right. If the product owner fails to get the value say, well, the other guy made 

the wrong decision. So we deliver what he claimed. And then the product manager can say, well, the team implemented incorrectly. It’s not what I wanted.

And instead it’s a lack of responsibility And the focus is a kind of attitude. I do what I’m a told, and I have a reduced responsibility or segmented responsibility I’m responsible for what while the others responsible for the, how I don’t think this works well. I think a great team is one that has, uh, is empowered to identify problems that are worth solving Validating assumptions and so on. And then once that is proven to create value, then implement a solution and then you grow the solution, but it’s the cycle from the beginning to the end. And then you repeat that. So I call that as empowered teams instead of feature teams. 

Murray: Yeah, I think the, you know, the problem with handing over a product spec to a product owner is also that, um, the team. Doesn’t really have the knowledge. You have a knowledge transference problem then like, how does the team understand what the customer really wants and needs? Um, and they need to understand that because when they’re developing software or any sort of product, they constantly having to make trade off decisions about how am I going to do this?

Or how am I, so the how and the what, and I cannot, cannot be separated. So I have a goal and. You know, there’s a million different ways to achieve that goal. Some of them will change parts of the goal. Some will trades the others. Some of it all do prioritize one thing or another. And I 

think as you start going through, you have constant trade off decisions.

So if you’re so separated, you know, you could end up producing a bad product quite easily. I think. 

David: Yeah. exactly. Uh, and that, uh, reminded 

me of a situation I had several times and one was in Brazil. We were building, let’s say a recommendation system, never met a get member. You bring a friend and then you’ll get the reward. And we did a kind of a discover process. And I remember, uh, developers were saying, ah, we know how to set.

They were talking about customer without knowing the customer said, let’s just, hold on. Let’s make something here to validate our assumptions. And once we are doing the real user test, I want you to be in the room with me because there’s a difference when I tell them something. And when they see and observe something, because.

Uh, before that, I used to share what I at the feedback I got from the end users and developers start questioning me. Why is that? Uh, Are They stupid or what They couldn’t get it so simple. And in this case, when I invited them to, to be part of the user interview and user task, the users were confused. They couldn’t get to the end.

And so. And developers who are looking, have you noticed that he was confused? He didn’t find that maybe the message is not clear. Maybe he’s not getting the point. I think we are communicating in a way that doesn’t resonate with our user. And then they start talking about user and a difficult Katie. They said, no, I saw that.

I saw that with three different people. It doesn’t work with them. We need to do something. I didn’t need to tell them they made their conclusions because they pick and also the, the felt accountable for solving a problem, not for implementing a feature. So that changed. 

Murray: So, how do you even cooperate? Oh, now I, we’re not putting our hands up shine. You got first.

Shane: so when we talk about a product manager handing over a speak, how’s it any different to a BA writing, a big requirements 

document upfront and handing it over to developers, right? I mean, isn’t that a classic example of 

documentation over conversation over collaboration.

David: Yeah, this is something like, which is the level of documentation we should. I think we just, uh, for me, I need just a sentence. It’s a reminder of a conversation. I sit down with the developers and say, here is what I got to know. There’s this problem here. And then that’s why it’s important. Users, uh, value that, and we could for them would help progressing in this direction.

And for us, we could get this businessman, but do you think of it? And then we try to get a problem understanding and see the road from the same lenses. And we come with a solution. And what is the documentation we write down? What we agreed upon like our acceptance criteria. So I don’t bring requirements for them.

I bring problems. And then we figured out, can we just solve this problem? And if so, which direction do we take? I, I used to be a business Ellis also, and I, I wrote 30 page documentation already. And you know what. Didn’t help at all because people were not thinking they were implementing exactly what I wrote there.

And that thinking upfront is, you know, it’s the validity illusion. I think that, uh, when you look at the plan, you say, that’s it. I know how to get there. And then people will follow the plan. You may get what you want, but not what you need. And then you are surprised when the users look at us, eh, I cannot use this.

It doesn’t bring value to me. 

Shane: Yeah. And for me, that’s the same behavior as when a product is. Right. So all the stories before they turn up with a team, right. And the team don’t have a conversation about the outcome that we want to achieve the customer or the persona that we are actually delivering something for. They just go through all the user stories and go, you know, user wants to be able to log in with a login button that’s at the top.

Right. And then blue. Yeah. We as humans, we tend to like to write detail. We like to problem solve. So, you know, product owners tend to over time get really good at being descriptive 

about what they want built because they want to solve the problem, not actually describing the problem that they want the team to help them solve.

So I’m with you on that.

Murray: Um, so I want to ask you, 

how do you incorporate that sort of research and discovery, customer 

research and customer discovery into the process so that you’re doing it all the way through. Cause I presume that’s what you’re talking about. Continuous research and discovery.

David: Yes. So I think ever thing, we would start with a clear go So that 

can have different names. That can be a product. Vision can be a product, go, can be OKR. It needs to have a direction. And then once you have the direction, then you can start thinking, how can we solve that? Um, do you make it more concrete?

Once I was in Brazil and we were in, um, second hand car market and we were connecting car owners with dealers and we help them sell their cars. In one hour, it was an auction platform and our challenge was dealers were not engaging. So we needed to figure out how to increase dealers engagement so that we will get a good offer for the car owner.

And then our goal was Dealers are engaged in our platform so that we get a good offer. There’s no, uh, what here. And we needed to figure out and incorporating that with the team. I brought this problem to the team and we did the brainstorm together. And then we figured out this is a problem. What would it do for that?

We just threw up ideas and then we try to cluster the ideas and we do the prioritization, very simple one to cluster the ideas. And I use what I call as a value metrics. It was in one acts like the potential. outcome course, it’s a guess, but it’s to have an idea and the effort of making that happen. And, uh, and for this, we could see where we have the low hanging fruit, where we have bets like high effort and potential outcome and where I have things that are just time-waster, we don’t see a potential there and they can be like, whoa, they can take a lot of time.

So what we did, we came up with certain ideas and then said, how do we get to validate ourselves? What does need to happen to prove the solution will work. And then if the team has said, let’s start as small as possible and validate with our real dealers. And then our our initial sprints would be validating ideas and we buld like a low fidelity prototype.

Sometimes some broken features within the idea of validating specific thing. And once we validated. Then we would start scaling up and then it comes a secret that I like doing. If my teams said for now, we are going to increase the technical debt because we want to scale the solution and prove it works and generate value.

So we are not looking at perfection or to proper implementation. We’re looking to creating value. And once we prove it creates value We will pay off the technical debt and ensure it is scalable. And then we pick the next idea. So one idea at a time, it, of course, one idea per team, in this case, I had one team.

Um, but what, what helped quite a lot is some ideas didn’t work. And we invested low time, a little time on that, and they were not properly implemented. And instead. Just continue with them. We dropped, we said, okay, let’s remove this from our product. We don’t need to invest more. We know enough. It’s not going to work.

We need to pick another idea and do the same process. Again, it was the same team.

Murray: So most people assume that in the scrum model, you build the feature, you deploy it and you see if people like it or not. Right. But that’s very expensive to build a full working feature. So I’m glad you talked about. Prototypes there, but it sounds like you’re still talking about releasing real things to real people to see whether they use it or not.

And that still sounds quite expensive to me compared to bringing people 

in and showing them and, um, visual mock-ups. So I was wondering if you could talk about that a bit.

David: Sure. And, uh, that’s the three key of the word prototype and what I mean by prototype the initial prototype was exactly. 

Um, mocked wireframe. So there were possibilities of clicking and so on. So let’s say we start to relieve very low fidelity and see if users would understand that at all. And then we integrated, and this I’m not talking of a process that takes weeks every day, we were doing something. 

Murray: So this is through bringing customers in and interviewing them. 

David: Exactly. So we had constant exchange with our real dealers in this case and validated with them as often as 

possible and important to say I was not bridging communication between developers and users. Sometimes I was watching developers were presenting to the Euro, real users, not me. And because I don’t think product managers need to breach community.

The neutral set the direction and help the team get there. That’s what I think.

Shane: So shouldn’t we rename them to be product leaders. You know, as an isn’t the word manager, just bring all that behavior of command and control. I’ll talk to them and then I’ll tell you what to do. I mean, like we should just call them product leaders. Right? That’s what it is. Because as you see it, sit the vision, see the goal, enable the team to get the job done.

Yeah, watch and observe and tweak where, where we need to speak to an adapt and help the team do things in a better way where it makes sense and then get out of the way of the experts to 

build a product, right. To meet that goal. And then that’s our, that’s our role as leaders, right? We’re not managers. We should be leaders in that 

space.

David: It totally resonated with me. And actually I’m mining here because I’ve worked at virtual identity and what we did there, we moved from project management to product management So that’s why I joined the company to implement product manager. And you know what we decided project management to product management is one word different.

And he said, It can still go in the same direction because people still see the word management. And we said, what if we change it, the name of our team instead of product management team to product leadership. And this is what we call our team. And our people are not product managers. They are product leads.

So we changed the name inside the organization. And to say, we don’t manage, we lead, we set direction when powerful. And if we are managing, then we are falling into old patterns and that’s not what we want to do because actually what I see the product manager, it’s something, uh, hardest, like imagine like on our Kestra and there is the conductor, they’re just playing the music.

And so, uh, but the conductor help the musicians. Connect and make the mutual pitiful, but the conductor is not playing any music at all. So that is a challenge. You need to have the guys plate together and beautiful, but you don’t touch an instrument, but you help them. 

Murray: Yeah. So, um, I saw you wrote 

about, um, product donor anti-patterns. So I was wondering if you could 

tell us. What is, um, what does weak product management look like? And you know, how common is it?

David: Well coming is very common from, I don’t know, out of 10 companies, I would say I can see many signs 

and at least seven eight companies from what happened with product management for me is first is a focus on command and control. It’s the focus on the output and not the outcome. So with. Creating roadmaps and creating plans for that.

And the print plans are prescriptive. We know what to deliver, but we don’t know what to achieve. So this is one of the signs that scares me the most. And also, um, it is about what do you do when you measure the outcome? Because then when some teams come to the next level, they, then they focus on the outcome.

But then they it’s, it’s like an investment, you know, if you are investing in a company and then it’s going down, what do you do? Do you wait until it recovers? Or do you sell that? And then you put on the winners. I think you should double down on the winners and then the losers, you just kick them off. So weak product management is not being brave.

You are not courageous to remove from your product. What is not. Because you need to be courageous and product management. Some things are just not going to work and we need to remove them. And this connects to another sign of weakness, a weak product management for me is like the speed of learning. How fast do you learn?

How fast do you validate yourself? So do you make decisions based on opinions are based on evidence and evidence? I’m not trying to make it? complicated and evidence can be like, we just talked a low fidelity prototype. You show to a re a chose a set of real users, and it just needs six, six users to just show.

And then you get an idea and you find patterns. So it’s speed of learning is another for me. And, uh, I know pressure or like I know what to get from money. So they want results and sometimes results for them is related to more output and product managers when Bo to this. Pressure. I would say they fail and you know, it’s like, uh, uh, something from the U S get-go garbage in garbage out. 

Murray: So I should product managers, do whatever customers. 

David: No, I don’t think so. Uh, I think product managers should find the intersection. Not all problems 

are worse, uh, are worth solving. For example, there are a lot of problems in the road. customers. have a lot of problems, some problems, they care more, some problems they careless and what we need to find is the problems they care and that would generate value.

Uh, on both. sides For the end users for the customers, for the business, and we have the technology to solve this problem. So I think this is the magic, and sometimes we can make trade-offs and say, this is exclusively good for the customer for the business will not bring something, but then we are making an investment to get, uh, to engage with the customer.

And we know that in the future, we can do something, but it’s about being mindful in your decision and. Problems that you can benefit from as a company and you know, that huge generate value for the user. Not because the user asks you should do. That’s not product management. That’s like being a waiter.

You know, you go there and then go to a restaurant to say, uh, the waiter comes what we did like Twitter. And then you said like some burger and then the waiter said, oh, would you like to have some French fries? Then you put something on top and then the way to goes and give to the kitchen. But actually you shouldn’t eat the burger in the first place because you are on a diet and the waiter is just giving you what you are asking for, but it’s not to what.

Product managers need to go beyond what users say. 

Murray: Um, can customers actually tell you what they need? Cause, 

um, quite often when you talk to 

customers, they’ll still tell you what solution they want Um,

David: Yeah, this is a, what 

I call the solution and problems here. Um, it’s like simple example. Jeff Patton wrote in his book, user SAR mapping. Um, I started map, sorry, when you go to a doctor, do you tell the doctor? I came here because today I want you to prescribe me this magazine and that, and then the dah dah, or you go to the doctor and say, I have a stomachache here.

And it’s, it’s less than four days now. And that, that worries me. And then doctor who say, what did you eat last? When did it start? The thing is you are the patient. When you go to your doctor and then you give the symptoms and the doctor is a specialist, the doctor knows the solution better, but he needs to know the symptoms of the problem.

And then he will be able to provide the proper solution for you. And what happens quite often with customers, they come to us as a specialist and they tell you exactly the feature they want. But they are the best ones to tell us which problems they have. So we need to say, oh, you need that. I think it’s about going back when the customer say, I want this solution and then say, interesting, tell me what would that help you?

Like, what do you need to solve? Let’s let me understand more. Why is that important for you and how do you solve that right now? Because they may solve that right now in a different. And how is that? So I think product manager should be super curious and understand the reason behind the request of customers.

Shane: So it isn’t one of the reasons we see that happen is because often our teams aren’t talking to a real customer And you’re talking to a proxy. Yeah. They’re talking to a person who is a specialist or a technologists or a product person. And so, you know, they’re able to provide a solution cause that’s their domain.

Whereas if you talk to the actual customer, the customer’s like I’ve got this problem. I got no idea how to fix it, but if you could do that, Hey, you 

know, that’s great. That’s, that’s solving a problem for 

me. I’ll I’ll give you money for it. Cause I want it to go away. It’s been annoying me. So for me, a lot of the 

times it’s because we use proxies instead of using.

customers 

David: Filigree. Um, I think it’s a student mindset of talking to stakeholders, engaging with them and understand what stakeholders 

want and then, um, doing exactly what they want to provide solutions and so on. But for me, 

this is like flying blind. We talk a lot about the customers many times, but the customer is never in the room and this is fine. If we validate the assumptions, we can talk about the customers, but we should validate everything we think they may need are not because only customers know what they need. And I think this, uh, I really actually, I hate the word stakeholders because you put everything in the same way. So stakeholder is a word that fits it’s one size fits all.

Stakeholder is a business. A partner is an accountant. It’s a system is a financial advisor and it’s the end user also. So I try to use stakeholders for business partners, but, uh, Customers as the ones who use our product, but stakeholders for me, they are not the enemies, but they are also not the customers.

They are partners. They enable us to deliver value to the end user. And that’s what I try to do as a product manager and help my teams understand that you don’t deliver solutions for your stakeholders. You collaborate with them and find solutions for the customers. 

Murray: I wanted to ask you, how do we measure value now? I know you already said. We’re going to do prototypes and see what customers think about it. But when I look at different features that we could be building, some of them are a lot more expensive than others. And I want to know if a particular change or a particular feature 

is twice as valuable or 10 times as valuable.

How can I 

determine that? So I can make those trade-off decisions. Okay.

David: Yeah, this is, uh, an important question to ask. And I think it’s about doing AB testing, for example. Uh, but it’s about the finding the right metric. Because for example, if you take a heavy metric like revenue, this is super, uh, let’s say there’s low to measure. It takes a while to measure revenue. Many decisions have, uh, have been made.

Until you can see the revenue. So this is a laggard metric, a metric and product managers should find the leading metrics. So what is your ultimate goal? Thinking, going back to the example of the car dealers in Brazil, the ultimate go is we’ll make a deal. So the, um, the offer will be good enough so that the car owner we will accept.

So that is the ultimate goal, but what would lead to that? And we had a problem with engagement and the first, very first. It’s the dealer opening our platform and click on a car, and then we can measure this and we start addressing that and try with different solutions and a prototype in a low level.

Fidelity can be an AB test and see what is helping the dealers and observe. Then also sometimes in Rio example, and then you can find the solution, but it’s important to have a metric that is actionable and actionable. It’s a debt is what, what I have been trying to do. And it has helped me quite a lot.

Shane: So if we look at something like, yeah, there’s a bunch of ways we can prioritize the work to be done. Yeah. A bunch of. I wouldn’t say frameworks, but a bunch of patents and one that interests me is the Kaino pattern. And what interests me about that is it talks about, uh, exciters versus satisfies. And, um, an example I typically use just lately for me was I upgraded my iPhone.

Uh, 25 13. And last time I upgraded my phone, I had to get my old phone. I had to back it up to iCloud or to my Mac, and then I had to get the new phone and plug it in and wait for it to restore. And this time I took the new phone out of the box, all shiny, you know, and turns it on. And it said, Hey, there’s another thought in it.

Once I signed up with my apple ID, it said, Hey, you’re on the phones. Do you want to copy it? And I went, who are you? And it just did it for me now, you know, it’s not as satisfying because the other process would have worked for me. But man, that was an exciter, you know, that was like, wow, that was a wow moment.

That was the sprinkles on top of my Sunday, you know, I didn’t know. But I really enjoyed it. And so I struggle with the, you know, once we get past minimum viable product, right? Once we get past something that allows the customer to do the minimum tasks that we want them, we need them to do, or we probably want to solve, how do we prioritize 

between too many well moments or 

none?

You know, what do you do when you are prioritizing, you know, options for the work that can be done?

David: That is part of the company’s strategy, I would say. Uh, and for me it’s like, do you 

want to be another product in the market? Are we want to stand there? Because if you want to, to, to be the one, like we’re top a bit, top of mind, you need to do things different. And by doing the things different, it’s not about delivering features.

And then you need to forget about MVP. And if you go to MLP, like it’s a minimum lovable product, and then you focus on creating a great experience for a small set of users. But like, if you think on net promoter score, you will only progress to the next level when you are, when you realize that you have a great net promoter score. 

Murray: I’m wanting to talk to you about scaling. Like how do you, how do you scale up the, the product owner or product leader function? Because, you know, in agile we say each team of say six to 10, people should have a product owner. Okay, well, you want to call it a product later. Um, but then, you know, many products will, will have, they just need 50 people let’s say to work on the mall or a thousand people because they’re big complex products.

So I was wondering, what are your thoughts on 

scaling up do to just have a product leader or 

have at the next level up and then another one that likes level up and so on. And wha what do you recommend.

David: Yeah, there’s this. Something. That is the answer for me is always a big 

depend, but I think an experienced product lead can lead. I would say sustainably three teams, Martin that can get quite complex and three teams. I mean this two pizza size, like from six to eight people, I have seen that working now with me.

It got quite stressful in, the beginning, but actually it helped me move from an output output driven to outcome because when I had three teams, I had no choice, but to empower them. And then I had no time to write stories, to write tickets, but I had time to set goals and to think, what do we want to achieve?

What is important? And to talk to the team about it and. And figure out, uh, what the problem is and then empower the team to, to do that on our, on their own. But this isn’t a case of, uh, three teams and I was, it was a startup, you and we were growing. And, uh, we went into three, but I don’t, when it comes to scaling with more teams, what I think could be sustainable is to avoid the segmented responsibility and the challenges.

When teams become confident teams. And what I mean here is I’ve worked in many online shops already. And one of the online shops, there was a team for Kartra checkout and other team for PR uh, product information management, and then another team for service desk. And then the roadmaps were done based on what could this team do?

Even if it didn’t make any sense for the product. For example, we have a good product information management, so we didn’t need to do anything, but then they said, but this team is unable to work in the other initiatives. Then let’s do a full refactor here and review, uh, create a new interface. So that’s what the guys started doing, but I liked another initiative.

Uh, I’ve had in another. We were a group of seven people, seven pro product managers that say, and then we agreed on the initiatives that we wanted to tackle. And then we said, who want to join that? And each developer could for per quarter or semester decide which team they would go. And then we would have a team focus on initiatives and the teams would be dynamic.

And that was quite interesting because. The product leads on the initiative and then the developers would come to the initiative. Of course, there will be something like a semi initiatives are more interesting than the others. And then people don’t want to do that. But then the developers would say, this month I will take the bar initiative, but next time I will go to the Goodwill and then you go to the bottom.

Okay. So they started being self-organizing, but the thing. We empower them to make the decision. We didn’t tell them you come to this team and you do that. I think in the scaling, it is about having clarity of where you want to go and then, uh, empower your team to do that. Of course, this is, uh, something that doesn’t create a lot of context, knowledge when you need the main for cart and checkout and so on, but inspires the team to take the next step and go extra.

Murray: I think in, you know, in, um, scrum, you’ve got scrum nexus from scrum.org and you’ve got, um, in less you’ve you’ve got, um, you know, a kind of team of teams approach. So there’s this, it’s common to see this pattern where there is a leadership team or an integration team. So somebody in that team would be a product.

owner for a program of 

work, which might have several teams in it that each has a product owner. Have you, uh, that’s that’s what I’ve seen work. I was wondering what you thought about that. 

David: Yeah. When it comes to scaling, uh, teams, uh, less is my favourite It’s not that prescriptive. You have an IRA 

product owner who oversees that, and then you have the product owners. So 

these, I think it’s a good way of 

spelling.

Murray: we’ve got best, best food coming on, actually

from less 

shine shine. Doesn’t know that’s what it is. Sorry to 

interrupt you. I’ll I’ll cut out my interruption. 

David: Uh, better when it comes to scaling. Uh, I also think it’s important to keep it 

simple because scaling 

doesn’t mean you. need to add strong and robust processes, because if you do that most probably we will come back to a waterfall behavior example for me, safe scale, the gyro framework. I feel a debt frightened me quite a lot.

And for me, I perceive as safe as like just our fake waterfall because it’s, it’s challenging. 

Shane: Agree with you on that one. In fact, actually I’m surprised nobody’s come out with the Kissimmee is 

the doji right? The old, keep it simple, stupid agile methodology. We should, uh, we should, uh, copyright that and release it. Yeah. 

David: That’s great. Yes. 

Murray: I got one more question related to scaling and they might all go to 

summaries cause shine gave me the wrap up. 

So it’s common to see product owners getting burnt out, you know, because, and working 60 or 80 hours a week. And I think it’s because teams expect them to write all the requirements for them as well as interface with all of the.

Other stakeholders in the organization and talk to customers and users and make all the product design decisions. And then, you know, those stakeholders also expect them to update the business case and produce the marketing plan and work with the salespeople. So you get this issue where product owners are just expected to do this huge amount of work.

And I’m wondering. What’s the best way to 

help them to, to take some of that burden off them. What’s the best way 

to support the product owner.

David: To be an enabler and not to be a manager. So what do I mean by that? For example, I manage the product backlog for a team for two teams. For example, if in four hours a week, I don’t take more time than that, but my store is a completely broken. They are a sentence And I know I’m going to refine it if the team and they are the best people to find the solutions for that.

So I just write a problem and scribe them. And I see the product owner, not as a technical role, that’s focused on execution, more strategic and setting directions. And so on what I learned and helped me to reduce the burden, because that was one of these guys working 60 to eight hours a week. Coming back to the startup.

I said, when we went from one team to three teams, it was like, I was the only product owner.

And we went from eight developers to twenty-five that frightened me and I was in Brazil and the team was located in Dominican Republic. And when we got this announcement, I was, uh, talking to the guy in Dominican Republic and we sat by the beach and he’d look at me.

Hey buddy, how are you doing, uh, dealing with that? I don’t know, I think I’m fucked up. And then he looked at me and said, well, it depends. Maybe if you keep your strategy of writing precise stars to us. Yes you are. Because then you want to be able to do everything you do for, for eight people. You cannot do that for 25 anymore.

However, if you decide to trust us and point the monster And then you just let us figure out how to slate is busy now that’s it. Then we can help you, but we need to, to be more connected and it just point the right monster trust, find the one that we should queue, and then we go down and kill it. And I reflect for that.

That’s it. Yeah. I’m not being a real product owner. I’m just being here like a project manager to build on this, uh, are a mixture of project manager and business analyst, writing requirements, and then managing the scope and the time and so on. And then I stepped back and I started being more like a focus on strategic decisions and empowering the others.

I don’t make. For example, I, you know, once one anti-pattern do you have a PO approval on your gyro board? So do you need to sign off all the items? So if you need to sign off all the items, it is already a problem because you should focus on what is the sprint go and let the team achieved that. And then you let the team present it to you.

And in the end you can decide either you want to add to write that again or so on. So it’s about. Letting the best person on the job make the decision, the wax persons, the best to make decisions on user experience the UI, the best to make a decision on the product design and developer the best to make a Derrick texture.

But what a product owner could do is like this problem is a problem that is worth investing a sprint because it doesn’t work Martin that, so in times of effort we can put a sprint on it. What can we do in a sprint? And then you ask these questions, you bring them like some challenge and you have them to get. 

Murray: That’s good. All right. I think we better go to summaries Shane what do you think 

Shane: Yep. Sounds good. Uh, so I’ll go first. Right. He’s going to got so, um, I love the idea of one bus has one bus. driver I think that’s a, that’s a beautiful sentence. Um, because it means the more people in charge of list, accountability, we’ve all seen it, right. You know, three people by driving the bus that does not go well.

Um, I like the idea that, you know, as a product leader, you start with a clear goal. You may use a vision statement. You may use goals, you may use OKR. There’s lots of patterns, how you can articulate the goal to the team and the vision to the team. So do that and let them get on with it. Um, and that, you know, we really are talking about product leaders, not product managers, you know, the people who I see who are the most successful in these roles are leaders by the way, they act and behave, not managers.

Um, and I love the idea of you’re the conductor, not the player. Yeah. There is no instrument in your hand. You’re, you’re doing the hard job of getting everybody to work together. So I thought that was a quite, quite a good idea. Um, it made me think that we often. Teach or train people to be product owners, but we don’t teach them the product leadership skills.

Right. We teach them scrum. We teach them how to be a product owner and scrum. We don’t teach them how to be a product leader and how to understand value, how to understand what the customer may want, understand that go. So I think we should change how we actually educate and train people. Um, I think, you know, that idea of start with low fidelity and only enhance it when it shows value.

Yeah. So whatever the way you can get it in front of a customer early, um, even if it’s ugly and then see if it’s with continuing investment or are you on the right track? Um, Usually the outcome, you know, and then use that as feedback on what to add and what to remove. And I struggle with that one because, um, I find it hard to figure out how I’m going to measure whether that value has been achieved, you know, apart from I like it.

Um, which isn’t a great measurement technique. Um, I love the idea of, we go to the doctor with a symptom, not a solution. Well, some of us Google it first just to see if he’s doing it right. But anyway, um, but often our customers in our stakeholders come to us with solutions, not problems. Um, so that’s, that’s an interesting thing for me.

And your stakeholder has become the new term for the business. It’s one size fit all for a group of people who aren’t as it geeks. Um, so we need to change that terminology if again, um, I love the idea of get yourself too busy to do the work. Because then you have no choice, but to enable you and empower the team to do it for you because you just won’t get it done.

Um, and last one for me, minimum viable product, minimum viable product versus minimum lovable product. Look at it with a lens of what’s your product. Yeah, I think you lose, you used, are you just another product in the market or I use something that’s unique and you have to 

pick one of those, um, 

and go for it.

And that changes everything 

you do within your products. So some really good points for me that came out of, uh, this concept of 

product leaders.

Murray: Uh, I think, um, for me, the big, the big reminder is that, um, a product leader doesn’t need to write all the requirements. Um, because that’s a very common thing. I see that, um, product leaders are expected to write detailed business requirements for developers and testers who will then go off and, and do it.

And, uh, it’s still very common pattern and. We need to try and move people away from that. Cause it’s too much for the, for the product and that distracts them from, you know, talking to the customer and user about what’s really important. So I dunno, maybe we get a business analyst on the team to help them, or we get somebody else in the team to help them or distribute it.

But, uh, I think we do need to, um, I know. I think we need to help them so that they’re not focused on the, the implementation all the time. 

Cause I see that as, as being a very common thing.

Yeah. Any final thoughts from you, David? How can people find you?

David: People can find me LinkedIn, mediam, David Pereira, or my website D minus the data that call I’m available. I always love exchanging with people and final thoughts. Empower people. That’s what I think it’s the bottom line product owners and our managers. You need a product that whatever the name is, I think it’s very important is there is a discussion, the difference between product owner, product manager and so on.

I think it doesn’t matter. I need to be accountable for end to end. And the only way for me to succeed is empower people,