
Loading summary
A
Hey there Agile Adventurer, Just a quick question.
B
What if, for the price of a.
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 Friday DGIF and Product owner episode of course, this week with Mohini Kisoon. Hey Mohini, welcome back.
C
Hey Vasco, it's been a great week.
B
Absolutely. It's about to get better because it's a product owner day here on the podcast and we'll talk about great product owners in a minute. But before that, share a story with us that exemplifies what you think might be the worst product owner anti pattern you've witnessed in your career.
C
The PEO anti patterns I've come across was mainly due to the fact that the POS were not well supported. Some were handed the role without the tools to succeed and sometimes without a Scrum Master to guide them if that was their first role. First time doing a product owner role. And as a Scrum Master, part of the job is coaching the product owners to own the product, not just manage the request. And sometimes that means creating that space and structure for them that they need to step into that ownership. So that reminds me of a product owner from a previous organization who appeared to be doing everything right on paper, like attending ceremonies, responding to questions, being present for the team, and working closely with the stakeholders as well. But the team was constantly quite frustrated with the level of scope creep. The anti pattern was that the product owner was mainly operating as a messenger, not a decision maker. So she would bring requests from stakeholders directly into the JIRA backlog with no prioritization based on value and no pushback. And when the team would ask so why are we building this? So the answer would be oh, because sales ask for it or because they want it. So there was not that triaging happening or there was not that habit of really challenging the stakeholders, but just saying yes. So. And each time the team would be surprised that at the sprint planning there would be some major new work that you would bring in that they haven't discussed before and not even elaborated during backlog refinement sessions. So this team could only manage to have a two hour sprint planning session for a two week sprint. So the backlog refinement was really crucial for them to have those conversations upfront before coming to a sprint planning. It could have a few things, sometimes new, but majority of the time was really big things that hasn't been well written or even elaborated. So what looked like the day to day was really chaotic and the team were getting demotivated and the priorities were being changed, sprints after sprints and they were not meeting their, their sprint goals as well. So and at some point the they started to our stakeholders started to be unhappy because they were not getting the things that they were promised. And that's when the manager of that product owner reached out to me and connected the two of us for me to help her in terms of the prioritization and coaching her as well in terms of the conversations that she was having with stakeholders. So initially there was a bit of a pushback from her because she wouldn't understand, like, you know, why I was coming in to help around. But one of the questions that I asked her and then she immediately kind of thought I'd, oh, I haven't thought of that was I asked her so what was the vision for her product? And that was something that she couldn't answer because nobody has asked her before. And it was just that simple thing that she felt that she as a product owner should know. So what I did was run a product vision workshop with her and some key stakeholders and we created a one page strategy as well where she we identified what were the target users, the core problems that they were having, and some success metrics as well. And we also set together a working agreement and one of the items in that working agreement was you can only bring backlog items which actually fit within those goals that we have identified here. Anything else, we'll have to defer them. And I also introduced a session where I prioritize that prioritization session between her and some key stakeholders to start prioritizing on some bigger initiatives, so involving the stakeholders in those conversations as well. And ultimately what changed was she was more comfortable to be saying no because then she was saying no with an informed material which says that, okay, I can't do this now because of XYZ reason. So. And yeah, that was how it worked through.
B
And how did you feel in that process? Right, because for me, what strikes me is that what you said in the beginning, like, on the surface, this product owner looked like they were doing everything that they should be doing, right? And for all I know, the first few days you were there, you probably thought that, right, they're doing everything that they should be doing. There's no problem here. But then the realization comes later that, okay, maybe this is not really what needs to happen in this specific team at this specific time, because let's not forget that the context is king, as they say. So how did it land for you the understanding that, oh, actually I need to do a lot of work here.
C
So I started, the team was using story points, so I kept using the same estimates with them and started looking at the first sprints. They were doing way less than what they were committing to and the same thing happened. So it's just an example of they were committing to, let's say, 100 points, but at the end of the sprint, they were able to do only 40 points. And then a lot of things were just carried over to the next sprint and it was just a habit. And it just came across like, okay, so we're bringing more, more items, let's do however we can. But ultimately I was still pushing back to the product owner that we won't be able to do all this. And the answer was like, but the, the stakeholders need this, so we need to be working on those. So eventually, when that came as two or more free sprints with the same pattern, and then having stakeholders giving like negative feedback or not being able to get the their products and their features, that was when there was that realization for her that, okay, we need to do something about this.
B
Yeah, absolutely. And that's also a great tip, right? Like, use the feedback, create opportunities for feedback so that the product owner needs to face what's not working. Yes, but there aren't only anti patterns when we work with product owners. There are some product owners who really, in fact do a great job. So share with us a story of potentially the best product owner you've ever worked with. Mohini.
C
Well, I had the privilege of working with many, many great product owners and I have learned so much from each one of them as well. But one who stood out for me was someone with his calm demeanor. He was able to navigate through complex situations. So Whatever people were throwing at him, he remained professional, calm, and never took it on on the team. And I think that's what you, you mentioned in week earlier, that being calm is also a great asset as well. And that was one of his key assets as a product owner. He also built strong relationships with his stakeholders and he was the go to person for all of them. And he was someone who was highly respected as well. So if the stakeholders demanded a feature that did not align with our goals, he would acknowledge the request, but he would also explain the trade off and offer to revisit it once we have validated our current direction. And he said no often. So he did it with such clarity that people respected it as well. So it's not just no, but giving the reason why as well. And I would also say that as a po, he also shielded the team from stakeholders because some of the stakeholders sometimes will just bypass some of the process and reached out to the developers trade and it does impact their focus. So he would handle those ad hoc requests and he would only bring it to the team if it's something which is very urgent, like a compliance issue issue, for example. And he also had that helicopter view, so which means that anything that's coming towards the team, he would know what's being impacted, which stakeholders will be impacted, which part of the business. And he was really good at communicating that to the stakeholders as well. Another thing I'll add, like, as a product owner, he was also a good listener and always gave the team the space to grow, to experiment, while he would also challenge them in a constructive manner as well. And as for my collaboration with him, we work very closely together, we bounce off ideas, each other in order to support the team. And also keeping the backlog well maintained.
B
Yeah, absolutely. I really like that he was able to listen to the team because it's not just about accepting feedback or being open for questions during the refinement and sprint planning, but being able to listen, at least in my mind, is about getting the best out of the team, because the team brings into the process the technical innovation. The product owner can think about features, business model, customers and so on, but the team is in the technical details. They know what is possible and they can bring up ideas that amplify what the product owner is trying to achieve. So that part for me is really important and I'm glad that you mentioned it because we very often forget it, that listening to the team is actually a core skill that product owners can bring and therefore make the teams better.
C
Yeah, definitely. And having A product owner that backs up the team like that, it just makes things so much easier for the team. And then for Scrum Master as well.
B
Absolutely. So, Mohini, we're almost at the end, but before we go, if people want to connect with you and know more about the work that you're doing, where could they go?
C
You could share my LinkedIn profile. So that would be the best way to reach out to me?
B
Absolutely. I'll put the LinkedIn profile in the show notes and everybody out there if you have questions, if you have a follow up story to share, why not reach out to Mohini on LinkedIn and share your stories? We learn as a community. Mohini, it's been a pleasure. Thank you very much for joining us and for being so generous with your time and your knowledge.
C
Thank you, Vasco, for having me. It was a really great experience. Thank you so much for that.
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.
C
Because.
A
Listening is great, it's important. But doing it together, that's next level. I'll see you in the community.
B
Slack. 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.
Podcast Title: Scrum Master Toolbox Podcast
Episode: Coaching Product Owners From Messenger to Decision Maker—A Scrum Master's Guide | Mohini Kissoon
Host: Vasco Duarte
Guest: Mohini Kissoon
Date: January 16, 2026
In this insightful episode, Agile Coach and Scrum Master Mohini Kissoon joins host Vasco Duarte to dissect one of the most common—and damaging—Product Owner (PO) anti-patterns: the PO as a passive messenger rather than a true decision maker. Through firsthand stories, Mohini discusses techniques for transforming POs from simple conduits for stakeholder requests into empowered leaders who own product vision and prioritization. The episode balances real-life challenges with practical coaching strategies and concludes with a portrait of an exemplary Product Owner.
[01:24–06:49]
Notable Quote:
"The anti-pattern was that the product owner was mainly operating as a messenger, not a decision maker. So she would bring requests from stakeholders directly into the JIRA backlog with no prioritization based on value and no pushback."
—Mohini Kissoon ([02:22])
[04:00–06:49]
Intervention:
Action Steps:
Memorable Quote:
"One of the questions I asked her... was, what was the vision for her product? And that was something she couldn't answer because nobody has asked her before."
—Mohini Kissoon ([05:17])
[06:49–08:56]
Host Analysis:
“Create opportunities for feedback so that the product owner needs to face what's not working.”
—Vasco Duarte ([08:56])
[09:26–13:04]
Key Attributes:
Collaboration with Scrum Master: Mohini and the exemplary PO "bounced off ideas" together and worked closely to keep the backlog disciplined and transparent.
Notable Quote:
"As a PO, he also shielded the team from stakeholders... He would handle those ad hoc requests and only bring it to the team if it’s something which is very urgent, like a compliance issue."
—Mohini Kissoon ([10:32])
“Listening to the team is actually a core skill that product owners can bring and therefore make the teams better.”
—Vasco Duarte ([12:14])
| Timestamp | Speaker | Quote | |------------|---------------|-------------------------------------------------------------------------------------------------------| | 02:22 | Mohini | "The anti-pattern was that the product owner was mainly operating as a messenger, not a decision maker." | | 05:17 | Mohini | "What was the vision for her product? And that was something she couldn't answer because nobody has asked her before." | | 06:38 | Mohini | "She was more comfortable saying no, because then she was saying no with an informed material..." | | 07:41 | Mohini | "They were committing to, let's say, 100 points, but at the end of the sprint, they were able to do only 40 points ..." | | 09:33 | Mohini | "He remained professional, calm, and never took it out on the team." | | 10:32 | Mohini | "He would handle those ad hoc requests and only bring it to the team if it’s something very urgent..."| | 12:14 | Vasco Duarte | "Listening to the team is actually a core skill that product owners can bring and therefore make the teams better." |
This episode offers a candid look at the PO’s journey from order-taker to empowered decision maker, serving as a valuable guide for Scrum Masters and Agile practitioners looking to coach Product Owners toward success.