
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.
B
Do it now.
A
But if you're not doing it now, let's listen to the podcast.
B
Hello everybody. Welcome to our Friday TGIF episode about product owners of course this week with Natalia Kurusi. Hey Natalia, welcome back.
C
Hello Vasco. Hello.
B
Pleasure to have you and to have this final podcast of the week about such an important role in Scrum, which is the product owner. We'll talk about what great product owners do and how they act in a minute. But first Natalia, share with us potentially the worst product owner anti pattern that you've witnessed in your career.
C
That's a funny one. Actually that was one particular situation that was pretty recently. So I worked with one person that is a great subject matter expert. So she, that person was a very, very good domain knowledge. So she was very, very knowledgeable in what she was doing. The thing is that the organization decided to adopt agility and to move everybody into that agile space. So that person got assigned the product owner role without her willingness. So she didn't volunteer for being a bio product owner. That role was just assigned like a sticky note to her. The fact is that she had another responsibilities as well. So about she was like loaded about 80% of her time. She was doing another stuff and on top of that she was asked to do like a product ownership for us as well. So in addition to that that person didn't receive any kind of formal training or certification on product ownership. Nobody understood or set up the expectations of what a product owner means. So that was she was coming from the place of very big frustration about the fact that she need to do product ownership on the top of what she was already doing. She didn't understand what the expectation so he understanding was that she need to do kind of traditional project management role. So she need to do command control, I don't know, to measure the schedules, to measure the budgets and other stuff. So despite the fact that she had a great, great domain knowledge, she didn't understand the dynamic of the team. So we actually, we had a very funny situation. So when we just started working on that project, that person that was a product owner, she brought us like a huge spreadsheet with all the requirements that she wanted. So that spreadsheet was elaborated by another company. So that was another consultancy company that just delivered that kind of requirements to have. I have a big spreadsheet and I say okay, this is what you need to implement. Our team, we had product persons, we had developers, we have testers and they decided to approach the situation a different way. So they wanted to do UI ux, they wanted to do the users feedback, the users interviews, they wanted to do to understand what the problem is before going to the solution now space, solution space. So we did that. The product owner didn't stop us. We did discovery, we did inception, we did a huge amount of story already in the backlog and features and so on. And then at some point when we were almost ready to release, she remembered about that spreadsheet. She just said look, it's all very good, I don't understand why I need to approve. Can you please map what you just did in your user stories with my spreadsheet? And that was like after two or three months of working. So before she was not working on spreadsheet, she was still working on a spreadsheet. So that was not very pleasant situation.
B
They were working, the team and the PO were working in completely different directions.
C
In completely different directions, right? So she was trying to map what we are doing in JIRA with what she's doing on spreadsheet. And she was very silent. Like if at some point she told us, look, I'm going to map back into the spreadsheet, maybe B can help her. But the fact is that she was very silent and that was an explosion after three months to say, look guys, I really need to map it back to my spreadsheet. We took a weekend off so our team just sitting and mapping back to her spreadsheet. Uh, it seems that it was about, I don't know, 50% of the things mapped. She was not very happy about that because she want that we are working just on that spreadsheet. So that was a huge misunderstanding, that was a big miscommunication and I think that was probably the worst situation that I had with a product owner in all my career.
B
So how did you solve the situation? Because I imagine this might have been very difficult to handle afterwards. Right. Like, because they were working team and po were working in different directions. Missed expectations, confusion. What happened next?
C
Yeah, first of all, for me was very, very interesting and strange. Why she did not communicate back the expectations because she was participating in all the review sessions, in everything. But then we understood that once again, we need to meet the client where he is, and we decided to meet the product owner where she is. So. So we did what she wanted. Like, we mapped back. She was happy about that. In a couple of months, she just left the company and we had another amazing product owner instead. But she was happy at that moment. So we just did what she asked. We didn't see any kind of value in that, but we did what she asked. And that make.
B
Basically you decided to kind of manage the relationship instead of creating a conflict to put.
C
Yeah, to put the relationship upper. So you see, sometimes you need, as a Scrum master, as a coach, you need to choose your battles. And that was a battle not to choose. From my point of view, she was so much frustrated that we just. Okay, what you need? We need a spreadsheet. We are going to give you a spreadsheet.
B
Yeah, absolutely. And that's incredibly important to realize what you just said. Right. Like, we need to choose our battles and sometimes it's not a good idea to fight battles that you already know.
A
Are going to lose.
B
All right, that was a great story. But not all product owners are bad. Some are amazing. Incredible. So, Natalia, share with us the best product owner you've ever worked with.
A
How did they work?
C
Yeah, that's a great question. Actually, I have. When you ask myself about the best product owner, I remember one person very clearly. That was back in 2010. I was working in one of my first Agile teams. We was working on a big learning platform for UK schools. So that person was hired recently. So that was a new product owner. But he was very knowledgeable. He had all the domain knowledge. He had the technical background as well. Amazing domain expertise, excellent stakeholder management and communication skills. And one thing that we cannot expect from a product owner, but he had coaching skills as well. So at some point he started to coach myself. So I was a Scrum Master and he was starting to coach myself. That was amazing. So I was a junior Scrum Master at that point. So he told me some of the things that I never thought and that was amazing. So that was a person. I completely understand that we cannot have all the product owners that have both technical background, communication skills, coaching skills, stakeholder management. So that's a very hard kind of blend of skills to find on the market. But that person had them all. So no wonder that after that he was promoted in the last five years like several times. He's not a product owner anymore. He's kind of general global director of product or something like that. Still working on that company. I'm not working with them anymore, but I look at that person and say, okay, this is how a product owner should look like and have full empowerment and ownership and decision making and take the risk when he need to take the risk. So he didn't like go and ask for the higher management all the time. He have that kind of. He can risk, he can take the courage to risk and to take the decision himself. I also.
A
Ownership, right?
B
Like the ability to take ownership. Yeah.
C
So that was an amazing case. And to be honest, I probably after that I worked with one or two other product owners that are similar to that, but never like that, let's say like that.
B
When I think about what you just answered, I'm thinking of course, understanding the domain. Right. Like the previous PO was great subject matter expert, so that's important. But then you also said two things that are really key for me which is great communication skills and the ability to coach. Not necessarily to coach us, although that's also helpful because we always can learn from each other. But I'm thinking that when you work with stakeholders and you need to help them make decisions, sometimes you can bring them a decision, other times you can only bring options and they need to make the decision. That requires a lot of coaching. Right? Like that, that requires not only the clarity that comes with great communication skills, but the ability to shepherd decisions to allow others to bring in their expertise and their knowledge and help make decisions. So I'm thinking that if I would go to, if I would have to design a product owner course, I would start there. I would start with the ability to communicate effectively and the ability to coach. That is in this case very specifically it means the ability to guide decision making processes without necessarily being the one making all of the decisions. Because as a product owner you will need to have others to agree, including the team.
A
Right?
B
What do you think about that?
C
Yeah, agree. I agree. I think you don't need to be a coach to have a formal role of coach or scrum master to be to have coaching skills. And I think coaching skills, skills is useful. For any team members, for product owner, for developers, even for testers, I think for everybody in the team, I think this is a very, very important stuff. But especially for the product owner because product owner, as you say, he need to coach the stakeholders, he need to bring them on the same page. So sometimes the scrum master can help that, but sometimes the scrum master is not participating in that discussions. In this case, product owner will take leads and will coach the stakeholders will bring them. You know, there are a lot of kind of misleading willingness of stakeholders. So one have one black button, another one want a white button. So there should be kind of person that will put them together and say okay, no, we are going to do a red button.
B
Now that's an easy one. I'm thinking, for example, sometimes stakeholders have a different business model in mind which would completely change the direction of the product. And the PO needs to be able to bring those stakeholders together and get a decision because otherwise it's impossible to go forward.
C
Yeah, that's right. And just imagine that you need to say no to very powerful person. So you as a product owner, if you see that CTO is going crazy, like you have a crazy idea that is not going to succeed or is not going to bring us value, you need to say no to a very kind of high level person in a nice way. So that kind of hippo thing, that not very highest level person is right all the time. That's a power of product owner because you need to have courage to say no sometimes when you could be afraid to say no.
B
Absolutely, absolutely. That's a great point. We do need to be able, as product owners, we need to be able to talk to people that are way above our heads in terms of power and we need to still be able to say no. Natalia, it's been a great week, filled with insights and great stories. So thank you very much for sharing all of that knowledge with us. But we're almost, almost done with the week before we do go do share with us. Where can people find out more about you and the work that you're doing?
C
Okay. So I think it will be very easy to find myself on LinkedIn. So I'm very active on LinkedIn. By the way, I'm very active in the ABAC space. So if people are here in apac, I'm speaking at different conferences here in Australia and New Zealand. I will speak at the ag, the big beach conference in March that will happen in New Zealand. So with my connection that people that would like to meet myself, I will be happy to see them in New Zealand. For other people that are in Australia or in Brisbane, you can ping me. I will be all the time ready to meet for a coffee, for a drink, for a chat, online offline. So yeah, absolutely going.
B
Absolutely. And thank you for being so open and everybody out there. Do reach out to Natalia. I'm sure you have some follow up questions. Why not just start the conversation on LinkedIn and continue to share your experiences. We are a community. We learn as a community. Natalia, to you we say thank you very much for your generosity with your time and your knowledge.
C
Thank you Vasco.
A
Alright, 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.
B
Dive interviews as well.
A
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.
B
I'll see you in the community.
C
Slack.
B
We really hope you liked our show. And if you did, why not rate.
A
This podcast on Stitcher or itunes, Share.
B
This podcast and let other Scrum masters.
A
Know about this valuable resource for their work.
B
Remember that check Sharing is caring.
Scrum Master Toolbox Podcast: Agile storytelling from the trenches
Host: Vasco Duarte
Guest: Natalia Curusi
Date: December 19, 2025
This episode delves deep into the complexities and evolution of the Product Owner (PO) role, focusing on real-world anti-patterns and exemplary behaviors observed by Agile Coach and Scrum Master Natalia Curusi. Through storytelling and reflection, Natalia and host Vasco Duarte explore what makes and breaks great product ownership, sharing lessons learned about stakeholder management, team alignment, communication, and the importance of coaching skills within Agile teams.
[01:23–07:12]
Notable Quote:
"She brought us like a huge spreadsheet with all the requirements... The team wanted to do UI/UX, user feedback, interviews, discovery... She didn't stop us, but at the end, she wanted everything mapped back to her spreadsheet."
— Natalia Curusi ([04:13])
[06:11–07:12]
Notable Quotes:
"Sometimes you need, as a Scrum Master, as a coach, you need to choose your battles. And that was a battle not to choose."
— Natalia Curusi ([06:54])
"We decided to kind of manage the relationship instead of creating a conflict."
— Vasco Duarte ([06:48])
[07:37–09:36]
Notable Quote:
"He had all the domain knowledge, technical background... excellent stakeholder management and communication skills... coaching skills as well. At some point, he started to coach myself. That was amazing."
— Natalia Curusi ([08:04])
"He can take the courage to risk and to take the decision himself... the ability to take ownership."
— Vasco Duarte & Natalia Curusi ([09:33])
[09:47–12:10]
Notable Quote:
"If I would have to design a product owner course, I would start there: the ability to communicate effectively and the ability to coach... to guide decision making processes without necessarily being the one making all of the decisions."
— Vasco Duarte ([10:41])
"You don't need to be a coach to have coaching skills. I think it's useful for any team members... but especially for the product owner because he needs to coach stakeholders, bring them on the same page."
— Natalia Curusi ([11:17])
[12:10–13:02]
Notable Quote:
"Just imagine that you need to say no to a very powerful person... you need to have courage to say no sometimes when you could be afraid to."
— Natalia Curusi ([12:27])
On legacy documentation:
"Before she was not working on the spreadsheet, she was still working on a spreadsheet. So that was not very pleasant."
— Natalia Curusi ([04:50])
On empowerment:
"Have full empowerment and ownership and decision-making and take the risk when he need to take the risk."
— Natalia Curusi ([09:16])
On coaching as an essential Agile skill:
"Coaching skills are useful for any team member... especially for the product owner because he need[s] to coach the stakeholders."
— Natalia Curusi ([11:17])
This episode highlights the spectrum of PO effectiveness, from misaligned, overburdened legacy roles to empowered, communicative, and coaching-oriented product leaders. Natalia and Vasco converge on the message that while subject matter expertise is important, it’s communication, guiding decisions, and the courage to own outcomes that define a truly great Product Owner.
For more Agile insights and to connect with Natalia Curusi, find her on LinkedIn or catch her at upcoming conferences in Australia and New Zealand.