Intro

Curious if your product team is caught in common traps that limit success? Join Brian and David Pereira as they explore how to simplify workflows, make smarter bets with prioritization, and shift from output-driven thinking to delivering real value.

Overview

In this episode of the Agile Mentors Podcast, host Brian Milner chats with David Pereira, author of Untrapping Product Teams. Together, they dive into the common traps product teams face, the differences between project and product management, and practical strategies for prioritization.

David shares insights from his book, offering advice on building healthier backlogs, creating adaptable roadmaps, and moving beyond a feature-obsessed mindset to focus on delivering true value.

References and resources mentioned in the show:

David Pereira
Untrapping Product Teams by David Pereira
Certified Scrum Product Owner® Training
Advanced Certified Scrum Product Owner®
Mountain Goat Software Certified Scrum and Agile Training Schedule
Subscribe to the Agile Mentors Podcast

Want to get involved?

This show is designed for you, and we’d love your input. 

• Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
• Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com

This episode’s presenters are:

Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work.

David Pereira is a seasoned Product Leader with over 15 years of experience guiding Agile teams to deliver real value faster. As CEO of omoqo GmbH and a top writer on product management, David is passionate about helping teams overcome challenges, unlock their potential, and simplify their workflows to drive meaningful outcomes.

Auto-generated Transcript:

Brian (00:00)
Welcome back Agile Mentors. We are here for yet another episode of the Agile Mentors Podcast. I'm with you as always, Brian Milner. And today I have Mr. David Pereira with us. Welcome in, David.

David Pereira (00:12)
Let's be here.

Brian (00:14)
Very excited to have David here with us. David is the author of a new book called, Untrapping Product Teams. So product owners, this is going to be a discussion that I know you're going to find very interesting. We're going to be talking about a lot of things that have to do with product teams and sort of the ins and outs of working with your products. So David, just for starters, what inspired you to write the book? What was the main problem you were trying to address when you sat down to write this?

David Pereira (00:42)
pain. I have worked as a product person for many companies throughout the years, different countries, different sides. And one thing that I realized is that there many things going wrong. And sometimes we just don't know that it's wrong and it hurts. Then when we realize the question is, what are we going to do about it? So I started writing about untrapped products. From this perspective,

Brian (00:43)
Ha ha ha ha.

David Pereira (01:12)
of there's something wrong, we might not see, but let's start from this and then maybe we can transform how we work for the better.

Brian (01:23)
Awesome. Yeah, that's a great take on it. Cause I agree. There's certain times when as a product owner, know I've, you you're kind of chugging along and things are going okay, but then something happens and it's sort of like, wow, this is painful. I don't know where it's, I can't put my finger on what's going wrong, but there's something happening here. And you you try to push through it and just get past it sometimes. And it's, that's not always the best strategy. I know you talk about there being sort of these dangerous traps that are kind of typical traps that product people fall into. Can you share any of those with us? What are some of the dangerous traps you identified here?

David Pereira (02:01)
Sure, there's the classic one called the gigantic backlog. So the team looked at it and we're talking about product owners, but sometimes product owners get demoted to backlog owners and they don't even notice that. So that's one of the most classic traps, but there's also another I call the calendar driven framework. You may think you work with agile, but then you realize that you only do what is in your calendar. So that digitates what you're doing and so on. And you fall prey to what I call as a meeting marathon.

Brian (02:38)
Yeah. I want to go back a little bit to your, to the big backlog kind of, idea there, because I, I know that's a issue I've talked with people about in class a lot. And, I just want to get your take on this. Cause I, one of the things, you know, we'll, we'll discuss in classes sometimes just the idea of having too big of a backlog and, and kind of wrestling with it and trying to get it in shape. But the question always comes up, you know, you what's the. the right number. We ask a question in class and say, how big is your backlog? And you'll see different reactions from people. Some people, less than 50, other people 250, other people 1,000 plus items. Is there a number? Is there a number that beyond which it's all of sudden now too big?

David Pereira (03:24)
Yeah, for sure. So for me, first is understanding what is the backlog about. It is a vehicle to drive whether when you look at the backlog, should be able to tell a story. You should know where you're heading to. But when you look there, if you see a 60 year old Christmas wishlist that has everything in but you cannot connect anything, that's when it starts smelling. So for me, a good backlog will have no more than I would say two, three things ahead of us. There might be some things that are directions that we will continue refine and get it better and so on. But if we would have something that takes us like six months of work to get it through, maybe we are doing project management.

Brian (04:12)
So that's an interesting distinction. if we're moving into product, how would you define that then if we're saying project management versus product management, how do you define that difference?

David Pereira (04:23)
So project management in general, we assume we know what needs to happen. So we start planning on when we do what and how long we're gonna invest in this and so on. Product management is more about starting what is value, what do we want to achieve? And then we start embracing the unknown, facing reality, learning from it. And then the backlog will emerge from our learnings. So it means we know where we want to land, but how we're gonna get there. We know where to start, but not the next 3, 4, 5 steps.

Brian (04:56)
Love that. So that gets us kind of into talking about road mapping a little bit because I know that's one of the things you talk about in your book and kind of the idea of trying to plan a little bit far in advance. So if we have a backlog, it's really more two to three sprints versus six months. Do you recommend the product owners roadmap for longer than two to three sprints or is the roadmap just a two to three sprint roadmap?

David Pereira (05:24)
Sure. So the roadmap for me, it is about a different flight level. So the backlog is the now. What are we doing right now in the next two sprints as we talked about? The roadmap, we're looking at what is the overarching goal we are pursuing. So that could be, for example, a milestone that we aim to achieve for the next two, three months. And then the backlog will march towards that. But for the roadmap, I think it's still important to have something like, what is the direction for six months that maybe we are considering. But the farther we go, the more I would say blurry it becomes. It's more like a direction and we can feel free to adapt that.

Brian (06:13)
So help me understand here, because one of the things I think that I hear a lot of questions about in class is, since 2020, the Scrum Guide has added this idea of a product goal. And we've always traditionally thought about having a vision for the product. So now we have sort of this nested nature of having a vision, a product goal. And of course, we've always had sprinkles. How do you see those things related? relating to some sort of road mapping.

David Pereira (06:45)
Let's take a company here as an example. I like looking at the SpaceX. What is the vision? The vision is something audacious, inspiring, that people can connect with. Might be very hard to achieve, but it gives us guidance. For SpaceX, would say two words, populate Mars. That's the vision. It's very far. And what would be a roadmap goal? For example, something they achieved already. It's a step to get closer to the vision. Build a reusable rocket. That's something they spent a lot of time doing, and that could be a roadmap item. Then when you go to the sprint ghost, it's just a smaller step towards that.

Brian (07:35)
Gotcha. Yeah, that's great way to put it. I like that idea and I appreciate you using kind of a real world example. I think that kind of drives it home for everybody. I think it's obviously one of the things we talk about quite a bit in Agile is that idea of that we don't have any problem with planning. Planning is a good thing. What we have a problem with is plans that are so concrete that they're inflexible. So when we... I've always thought as a product owner, when we try to create these roadmaps, the further we get out from today, the looser, the less defined it is, the more rough the idea is, and the less people should count on there being any date that's going to be met based off of that longer term horizon. Of course, there are exceptions to this. You mentioned SpaceX, mean, SpaceX has a multi-year goal. I mean, they have something that's kind of further out to the future. So I think that there are some exceptions that we probably could make in there. But I think you're right. Think about them in that steps as far as vision to product goal to sprinkle. One of the other things that I found kind of interesting in reading up and thinking about your book is you talk about the difference between coordinated and collaborative workflows. Can you define those? Tell us a little bit about what you meant by that, the difference between those two.

David Pereira (08:31)
Yeah, of course. I start with a question. When we are talking about coordinative development flow, step back and then reflect. Do you talk more about work than you do it? Or you just go and do work on it? If you feel like you are all the time talking about work, everyone is talking about it, you have so many meetings discussing and so on, but then you wonder who is doing the work, then there's a chance you are in the coordinative development flow. The collaborative development flow, it's a little bit chaotic. There are many things happening. Teams are looking at what can we do right now? What can we do next? They are adapting all the time and so on. Plans are actually means to an end. They are not reached. They point a direction. Teams may have a plan, but it's very simple. It is not a predictive thing. When you are in the coordinative development flow, things take long. For example, you may have a lot of ideas in the beginning, then that means you need to find the most promising idea, speculation. So you may use frameworks to have the best scoring and understand what is the idea most promising. Then you invest time and crafting high fidelity prototypes and so on. There's a lot of coordination back on Perf. But if you go to a collaborative, you say, all right, I have all of these ideas here. Which ideas are worth? That's the first question. Then you say, how do they meet our, for example, product vision? How do they relate to our strategy? How do they contribute to our goal? And if you don't have answers to that, you use your friend called trash bin. So you put the things in your trash bin and then you start moving forward. And you say, all right, how do I know this has desirability? It's viable from the business. How do I know we can do it? then start running experiment. And then some things you realize, actually customers don't need it, then you don't pursue. So that's why it looks like chaos because you don't know what will get to the end, because things will fall apart on the way because you learned they don't make sense. On the coordinate, you know what gets to the end. You just don't know if it's the right thing.

Brian (11:18)
That's a great point. And you're right. If we think of this from an experimental mindset, the product development game here as more experimentation, think you're right. There's going to be things that don't, the experiments that don't turn out the way we expected, just like there is in any kind of experimentation. that can be some of the most productive moments actually is when you have those experiments that turn out differently than you anticipated because that can lead you in areas that are surprising and new and have value that you might not have otherwise recognized, I think. So yeah, I love that. I think that's a great way to talk about it. It makes me think a lot about prioritization as well because I know that's a big area for us as product owners and... You know, someone sent me an article the other day that, that I share sometimes with people that's, it's a blog post that someone put out there. was like 127 different ways to prioritize your backlog. It's just, they're all methods, right? They're all the things that you probably, all of us have probably heard and, you know, things like Moscow and, and other things like that, that people are typically use, to prioritize their backlog or rice or. relative weighting or something like that. But one of the things that I find kind of interesting with that, and I want to get your take on this David, is sometimes when I will use something like relative weighting, for example, or rice, very much more of an analytical approach, right? And we're trying to try to analyze it based on several factors and see what the score comes out at the end, which one's higher than the other. but one of the interesting kind of a sideline effects that I've noticed in myself as a product owner is sometimes I'll find that I'll run that kind of a process on several features and I'll get to the end and you know, I've got three features and know, a feature, a, and C and, you know, I'll take a look at the results and look, you know, it looks like feature B is number one feature C is two and, and a is three and Sort of in my head, I kind of feel this dialogue happen where I think, huh, really B is number one. Wow. would have never thought that would have been the case. That's surprising. I can't believe B came out as number one, but maybe I answered those questions incorrectly. Maybe I should go back and change my answers in doing this analysis because that can't be right. B shouldn't be one. B should maybe be two or three. And I kind of call it the the gut instinct, you know, it's kind of that gut instinct moment where you look at the results and it feels wrong, right? And I know you talk in your book kind of about, you know, opinions without evidence and kind of the idea of, know, it made me kind of think about that scenario where sometimes you'll run it through some kind of a prioritization technique and there'll be a definitive answer, but you kind of have that instinctual moment that feels like maybe this is not right. How do you handle those moments, David? Do you have any problem overriding results or do you always take the results of some kind of a prioritization technique that you've tried to use?

David Pereira (14:44)
Mm-hmm. So prioritization is something quite interesting. What I see is many companies search for certainty. We need to ensure that we find what drives value. So we take some time analyzing that. The problem is that we start injecting a lot of speculation. We think what it's right, but we don't. What I see is prioritization is a bet. So I think about placing bets. Say, all right, so there are all of these cool ideas here. I try looking, for example, at potential. As of now, what do we know about it? How many customers would care about it? How much would they care about it? Can we deliver something of that? I say, all right, let's invest one day and see what we can learn about it. Then we can move to the next. And then we can invest maybe two days. And if we don't like what we learn, then we just stop. And if you like what we learned, then we say, let's invest another week. And then we keep going to the point we say, this looks cool. And then we can do something about it. So I say like, let's have a bias toward actions. We can face reality as fast as possible. Then we can learn what makes sense and what doesn't. And I give you a concrete example. When I started about the book, I was thinking, Does it make sense for me to write a book? How do I know that? I got invited to give a keynote. I said, I'm going to speak about something that I would write and I will see how it resonates. I gave this talk 10 times. And then what happens after each talk? Few people would come to me and say, Hey, I like this thing. I like this. I like this. And everything you didn't mention, I started questioning. And then what they like to explore. And after the 10th talk, someone said, when are you writing a book about it? said, aha, now it's coming. I said, I need you to do another experiment. I posted on LinkedIn. said, I'm writing a book. And I had in my mind, if at least 200 people show interest in that, I'm going to interview people to understand their challenge. So I did that. When I decided to write a book, I didn't write the book. I explored. where to write and so on and all of this. Because I was placing bets, small investments that give me information that I can use as evidence. And that's the same what I do with digital products. It is about learning from reality, not from a meeting room.

Brian (17:25)
I love that. Yeah. I think we've, I know that I've heard that language used quite often, the idea of making small bets or making bets on things, but it really is a revolution. And you're worried way to think about it. like your, your concept of, of thinking, is it worth a day? Right. Is it worth a day to do this? Is it worth me betting a day on, on trying to find out more information about this? is that really how you look at prioritization then is, is, is you prioritize it? Is it, is it kind of, Is it worth the effort to do what it's gonna take to do this thing and think of it that way as a bet?

David Pereira (18:01)
Yeah, in this direction, because for example, when we explore what is the potential outcome, how many users would care, how much do they care about it? I say, let's see if that is true or not. Let's start learning about it. Then we can have a better understanding of the expected result. Because the danger is when you start talking about these things, it just do a scoring, like a rise, eyes or something else. then you get false confidence. So I want to move away from the false confidence to get closer to reality because in the end of the day, we don't know what we don't know.

Brian (18:41)
Yeah, I think that's a really good point to make. I know I've run an experiment sometimes in classes where we'll have a couple of different ways of prioritization. I'll give them something complicated like relative weighting or rice. And then I'll give them something, you know, ultra simple, like stack ranking and, you know, have them compare and say how, what's the difference. I know you talking to your book about kind of how important it is to simplify the decision-making process. And so I'm just, what are some of your strategies for that, for trying to simplify that decision making process?

David Pereira (19:19)
So you need to know what is priority right now. So you can filter out things. For example, if your product is scaling, what matters most? Is it retention? Is it growth? Customer satisfaction? Which is the game you are playing? Because if you don't know the game you're playing, everything is a priority. Then you need to discuss everything. So that's the reason I like starting with what matters most. Because then you remove everything else. then you can look at, so if growth is what matters most, let's think about what will contribute to that. Then we go from this.

Brian (19:56)
Yeah, that's a great way to look at it. I think you're right. I it's the outcome that we're trying to drive, right? I mean, we're rebuilding features or we're proposing to build something so that we have this outcome. And if we're not really driving that outcome, then we're wasting our time. We're not really doing what we're trying to do. Yeah, that's a great point. I know one of the other points you talked about in your book is kind of this idea of periodically doing product health checks.

David Pereira (20:12)
Exactly.

Brian (20:23)
And that was kind of an interesting new concept for me. I not heard that really spelled out in any way. Can you help the listeners kind of understand what you mean by a product health check?

David Pereira (20:34)
For me, it's a falling. We may start doing things without challenging them. We don't know if they are good, we don't know if they are bad. We know how to do them. And then that becomes our routine, our habit. On Monday we do this, on Tuesday we do that, on Wednesday we do the other. And we keep doing, and they give some results. But the problem is, is it the right thing? So I like stepping back. and looking at a few aspects so we can say, where do we stand? And then you may uncover something that is, I'm not doing it or something that I'm doing that contributes to a bad result. I always ask teams, when was the last time you retired a feature? And sometimes I hear only crickets. And then I say, when was the last time? I say, we never retired a feature. Said, what is your definition of a good product? And some people tell me, well, a good product is the one you have all features you need. There's nothing else to add. We're not there yet. And then I asked them, can you open Google? How many features do you see in the homepage? For me a good product is the one you have nothing else to remove. It's a bit different. So when you have these health checks, you have the moment of challenging, having a different perspective. And then you have the chance of saying, I want to change. I want to do different. Then you can improve how you work.

Brian (22:10)
Yeah, that's a great way to look at it too, because you're right. we're, you know, I think about this oftentimes when I talk to people about, you know, kind of their vision or even their customers and users. And really, if you can't understand or you can't really define who it is you're targeting or what it is you're trying to achieve, we shouldn't be doing it, right? We should stop and understand those things first before we move forward. I know one of the other things that you'll you talk about in the book is kind the feature obsessed or feature focused mindset. And just kind of wondering, you what kind of practical advice could you give to different product owners, product managers that are struggling in some way with that feature focused mindset?

David Pereira (22:57)
Ask more questions. That's where I start. Whenever you come with a feature, you say, what is that for? What does it enable the user? What would be the other options? Let me give you an example. In one of the places I worked, we realized that we had trouble with signup. And then someone came with an idea. Of course we have a problem. Because, let me do this again. Of course we have a problem. Because... We have to create a login all the time. If we have social login, then it's amazing. And then we put the Google login there. And we said, with Google login, we will simplify the sign up process. Nothing happened. Sign up rate remained the same. Then I started interviewing people who came to our website, but didn't sign up. What I learned from them was, I don't understand your value proposition. And then you asked me to create a user, you're going to load me with emails. Why am I going to do that? I'm not going to do it. And then I realized that the friction was something else. The value proposition was unclear and they didn't want to give their data. So we could put whatever login method, it would not help. We started with the wrong question.

Brian (24:17)
Yeah, that's a great example. I appreciate you sharing that because I think that's a common problem I think we have in the product area is kind of we see a response or we see that something's not going the way that we thought. And I know I can have the inclination at least to jump to what I think is the reason behind it. without actually verifying that that's the reason behind it. And that's a great example, right? mean, hey, we thought if we add a sign up and do it through Google, that's going to remove friction. It'll make it easier for people to sign up and we'll get more signups. Well, not if they don't really understand what your value is and why would I come back to this site? Why do I want to get emails from you? I'm not clicking on the button to go through giving you my Google information if you haven't sold me. Right? Yeah. Yeah, that's a great point to make. Well, the only other thing I'd say is I know one of the kind of time-honored discussion topics here when we talk about this stuff is really people who focus more on the output and getting distracted by outputs versus really focusing on value. What kind of advice would you give to people who either don't really understand the difference or find themselves kind of slipping back into being more focused on output versus value.

David Pereira (25:53)
Talk about assumptions. We all assume something is gonna happen. Sometimes it's just in our subconscious. We need to bring to our conscious level. For example, we say, this feature is gonna be a success because, then come your assumption, because customers want, because customers will understand how to use it, because the business can collect value. These are assumptions. And then you can say, How can I test these assumptions before I invest time into creating the feature? Then you learn.

Brian (26:29)
Yeah, I agree. That's so important. Honestly, that's one of the biggest paradigm shifts I think I went through as a product owner is that kind of shift in understanding these things in my backlog, they're assumptions. They're not requirements. They're not things that have to happen. They are things that could possibly happen. And the idea is to determine if they're the right thing to happen or not. And if not, then we should move on. Well, this is awesome. I think the books, the topic of your book sounds really fascinating and I hope everyone goes to check that out. It's called, Untrapping Product Teams. And again, David Pereira is the author here. We're put links to all this into our show notes. So if you wanna click on that and find out more, we'll put you in the right place so you can find out more. just, I'll give you kind of a sampling here just so you kind of understand my... My own boss here, Mike Cohn, has a quote here about it that says it's his new favorite product management book. So it's just, he's got people like Marty Kagan, Martin Dalmigeon that's kind of weighed in on this. Petra Willie has given quotes about this. So there's lots of big names that have read this and given it good reviews and said this is a really important work in the product area. Really encourage you to check that out. David, I can't thank you enough. Thanks for making time to come on the show.

David Pereira (27:59)
Glad to be here.