
Loading summary
A
Hey there, Agile adventurer, just a quick question. What if, for the price of a fancy coffee or half a pizza, you could unlock over 700 hours of the best agile content on the planet? That's audio, video, E courses, books, presentations, all that you can think of. But you can also join live calls with world class practitioners and hang out in a flame war free and AI slop clean slack with the sharpest minds in the game. Oh, and yes, you get direct access to me, Vasko, your Scrum Master Toolbox podcast. No, this is not a drill. It's this Scrum Master Toolbox membership. And it's your unfair advantage in the Agile world. So if you want to know more, go check out scrummastertoolbox.org membership, that's scrummastertoolbox.org Membership. And check out all the goodies we have for you. Do it now. But if you're not doing it now, let's listen to the podcast.
B
Hello everybody. Welcome to our TGIF and product owner episode this week with Prableen Kaur. Hey Prablin, welcome back.
C
Hi again. Thank you for having me.
B
So product owner is the focus of today because it is, as I usually say, the Batman to our Robin. It's the critical role that we must be able to cooperate with to help our teams succeed. Now there are some amazing product owners out there and we'll explore what that looks like in a minute. But before we need to explore what are some of the anti patterns? So Pravelin, the question for you is what was potentially the worst product owner anti pattern you've witnessed in your career?
C
Sure. I again want to share the experience through an anecdote and that's about understanding the role of the po, because Agile is certainly which is absorbing people as it is. But initially it wasn't the case like that. When I saw the pos, initially they were the people who were coming from the technical background who chose to switch to the space where they are talking to the stakeholders now, just not to the team. So when you have that technical understanding and technical mind with you, we get to a point where we start directing the team that how they should solve the piece of work or the problem which the stakeholder is presenting in the name of the feature. So if I have to simplify it for you, when we have the PO to the team, the whole understanding of the tool is that the peer is going to tell us that what is the priority, what we are meant to deliver, because the PO is talking to the stakeholders. So the PO is the what and the team is the how the team decides that, how do we want to do it? What should be the tech stack? Is it feasible, is it not feasible? So that is the clear understanding of how we can pick up the work. But when POs have the technical understanding or when they switch the role from their technical roles to the conversation with the stakeholder role, it often becomes a problem that they start directing the team about do this this way. And that is the biggest anti pattern I have observed as a Scrum master. Because what happens is if we look it a little closely, the PO start to manage the Sprint backlog. They are not responsible for the Sprint backlog, they are responsible for the product backlog. And this is the reason we see a lot of changes in the backlog. The sprint goal is compromised, the stories keep on adding, being added or removed and then there's a lot of explanation happening that why it is done. But then eventually team ends up delivering nothing because we couldn't focus on anything. Right. So that's the anti pattern which I want to share.
B
Yeah, absolutely. So when you think about that anti pattern, what are some of the practices or approaches that you have learned help to move the product owners closer to that ideal that we want them to be at when working with the teams, what are some of the things you've learned about helping them evolve, helping them develop their skills?
C
I believe it all starts in the backlog refinement because that is the place where we are understanding that what is to be done right. And then whenever we get into the space where we start getting instructions from the PO that okay, do it this way, or if the story directs that, okay, this is to be done in a particular technical fashion, we sit down and talk about the approaches because that is the point where the estimations are going to happen. So when team is estimating, I make sure that we are having a proper conversation about all the numbers we see in the poll or in whatever tool you're utilizing when that happens. And we also start discussing about the possible technical solutions. If we are not being direct about it, we could be indirect about it. That okay, you may have fun, but this is how the team team feels about it. Right? So this really helps. Having a very strong backlog refinement and being very vigilant about where the conversation is going helps get out of this antibattle.
B
Yeah, absolutely. And it's all about conversations, right? It's about creating that space and helping the conversation evolve. Because just like we discussed previously about the teams needing us to help them but not telling them what to do. Right. It's about creating that space where they can work together, where they can learn together.
C
That's true. And we also have to understand that everybody's coming from the right place. Of course that person is giving it the suggestion because he or she thinks that's the best thing to do. We are trying to be the best, but then we have to understand that there are people around us and they should feel the same about whatever you're suggesting. That's a conversation to have.
B
Yeah, absolutely. All right. But there aren't only anti patterns in the product owner space. There are also some amazing people, excellent professionals, who show us what great product owners look like and work like. So share with us the best product owner you've ever worked with. How did they work?
C
So the best product owners I've worked with kind of understood the stakeholders very well. So coming from the space where the team had multiple stakeholders, and when I say multiple, that's a good number, to be very honest. It's not just three, four, five people, it's beyond that. So the CEO I am talking about and the experience I've had with him, he has started to understand the pulse of the stakeholders and what to expect from them, because everybody has their initiative and they wanted to be prioritized, right? And nothing could be done simultaneously. Everything needs time, a proper structure. So for me, the best PO is the person who has the superpower of saying no, and they can deal with the stakeholders with the same prowess that, okay, you want that to happen. And of course, because I understand your need, but then you also have to understand that team has limited time. And then there are other stakeholders as well. So that's the point where the PO can push back and make the other person understand that we need time to fix that. And that pushback cannot be random. There has to be reasons about it. It has to come out of preparation. And that's where having the understanding of stakeholders is really important. But how much they'll compromise, that's the point where you bring up the priority. Right? So since he develops the roadmaps, most of the work which is thrown at us is known. That helps the team to prepare better. Also, it comes down to the user stories. The user stories, he writes, they are very rich in context. And I'm not talking about the business context, about what the story is. He also mentions about who will be impacted. That has really helped us as a team, because when we have multiple stakeholders to deal with or multiple system being affected, it is important to understand that where is the request coming from and who will be impacted out of it. And of course the priority. And generally people use JIRA as the tool. We have the priority as a field which reflects on the board itself. The moment you open the board, the first thing you see is the priority column. And he uses it very, very well. So if I have to talk about the best POI I worked with, he had the power of saying no and he had that power because he has a certain relationship with stakeholders and, and that comes out of his preparation, which ends up in a roadmap which is given to the team and that helps the team prepare. So that's a complete cycle, I believe.
B
Yeah, absolutely. And the ability to help teams prepare is what we really want to focus on. Right. Because at the end of the day the partner is a critical role, but it's the teams that help us succeed as a whole. Right. Like, and that's why I really like the fact that in the latest, not so recent anymore, but in the latest Scrum guide, there's an explicit mention of the product owner being part of the team because originally it wasn't, it was an external role. But now we talk about the product owner being part of the team and it's important to recognize that product owner is a critical role, but it can't make success happen. Only the team together, including the po, of course can make success happen.
C
That's true. And it's not always, always about getting to what is to be done. It is also about the dynamics the PO develops with the team as well. And that's why I believe that the role as a vault should be a team specific role, not an external role. Because that one on one relationship or one to multi relationship is also going to help that how it is distributed and looked at from the team's perspective. So that's, that's a great add on.
B
Yeah, absolutely. Prabhlin, we're getting close to the end. Thank you for sharing all of that with us. But before we go, where can people find out more about you and the work that you're doing?
C
About me? My LinkedIn profile is the best reflection you can come in, check it out. There's all the information available there and the work I'm doing, I'm very vocal about it, of course, on that professional platform. And not only that, if you need anything, just drop a text and I'll probably help you with whatever I have as the understanding.
B
Absolutely. And that's an invitation right there, everybody. Why not check out prableen's profile on LinkedIn the link is in the show notes and ask a few follow up questions. Start the conversation because after all we do learn together as a community. So Prablin, thank you very much for your generosity with your time and your knowledge.
C
Thank you so much. It was an amazing conversation and I'm also taking back things with me and it was one of an experience. Thank you so much.
A
All right, I hope you liked this episode, but before you hit next episode, here's the deal. This podcast is powered by people like you, the members who wanted more than just inspiration. They wanted real tools and real connection to people who are practicing agile. Every day we're talking access to over 700 hours of agile Gold, CTO level Strategy talks, Summit keynotes, live workshops, E courses, Deep Dive interviews, books, and if you're into no Estimates, we got the pioneers of no Estimates in those Deep Dive interviews as well. Agile Business Intelligence, creating product visions, coaching your product owner courses, you name it. You'll get invites to monthly live Q&As with agile pioneers and practitioners, plus a private Slack community which is free of all of that AI slop you see everywhere. And of course without the flame wars. It's a community of practitioners that want to learn and thrive together. It's the best place to connect with community and learn together. So if this podcast has helped you before, imagine what you will get from this podcast membership. So head on over to scrummastertoolbox.org membership and join the community that's shaping the future of Agile. We have so much for you, so check out all the details@scrummastertoolbox.org membership because listening is great, it's important. But doing it together, that's next level. I'll see you in the community. Slack.
B
We really hope you liked our show. And if you did, why not rate this podcast on Stitcher or itunes? Share this podcast and let other Scrum masters know about this valuable resource for their work. Remember that sharing is caring.
Host: Vasco Duarte
Guest: Prabhleen Kaur
Date: February 13, 2026
This episode dives into the pivotal role of Product Owners (POs) within Agile teams, exploring both the common pitfalls and the exemplary characteristics that make for outstanding POs. Vasco Duarte and his guest, Prabhleen Kaur, a seasoned Agile Coach and Scrum Master, focus on the delicate balance Product Owners must maintain between telling the team what to build (not how to build it), the importance of stakeholder management, and the impact of effective collaboration on team success. The conversation is filled with pragmatic tips and real-world anecdotes, offering actionable insights for Agile practitioners looking to foster stronger PO-team dynamics.
On the anti-pattern of POs dictating the “how”:
On backlog refinement and team autonomy:
On the best PO’s superpower:
On POs as team members:
This episode is highly valuable for Agile practitioners seeking practical guidance on elevating the PO role, fostering team autonomy, and achieving true collaboration between product and development teams.