Truth vs. Fiction - The Power of Transparency in Product Ownership | Irene Castagnotto

Summary

---

Podcast Summary: Truth vs. Fiction – The Power of Transparency in Product Ownership

Scrum Master Toolbox Podcast with Vasco Duarte
Guest: Irene Castagnotto
Date: August 22, 2025

---

Episode Overview

This episode explores the critical role of transparency in Product Ownership, examining how honesty, trust, and clear communication between product owners, development teams, and clients can make or break a project. Irene Castagnotto shares experiences from her Agile coaching journey, addressing both anti-patterns (negative behaviors) and standout examples of excellent Product Owners (POs). The discussion also offers actionable insights for Scrum Masters and Agile teams facing client dissatisfaction and highlights best practices for building a culture grounded in trust and learning.

---

Key Discussion Points and Insights

1. Anti-pattern: Lack of Transparency in Product Ownership

(01:21–07:48)

• Scenario Recap:
  Irene describes working with a PO who struggled to be transparent with a client about project limitations. Rather than clearly communicating what was and wasn’t possible, the PO attempted to “make a story” to soften the blow. This led to confusion inside the team and significant client disappointment during the review.

• Key Insight:
  Transparency isn’t about pleasing the client at all costs. There’s a fine line between using diplomatic language and outright withholding or distorting the truth, and failing to be upfront only damages trust long-term.

  "Understand the difference between using good words because you have to negotiate and not being transparent. Because there's a light line of difference..."
  — Irene Castagnotto [03:16]

• The Team’s Dilemma:
  When a PO is not transparent, both the team and stakeholders suffer. The team feels confused and unprepared; the client feels blindsided and frustrated.

• Empathy for Product Owners:
  Irene acknowledges that these situations are tough; sometimes, POs panic or lack the tools and experience to handle upset clients.

2. Managing Client Anger and Protecting the Team

(04:39–07:48)

• Scrum Master’s Perspective:
  Host Vasco highlights the importance of shielding the development team from the direct brunt of client anger to protect morale and psychological safety.

  "...if you reduce the exposure to this anger, you improve the overall environment for the team... But it's different coming from us or coming from a shouting client with a red face, right?"
  — Vasco Duarte [05:28]

• Best Practice:
  Teams benefit when the PO or an intermediary (like an account manager) is the first point of contact for difficult news. However, Irene notes that direct contact with clients can sometimes foster greater responsibility and satisfaction for the team—if handled positively.

3. Moving from Mistakes to Growth

(07:48–08:24)

• The negative experience led to learning for everyone involved: the PO, the team, and even the client. Irene observes that subsequent interactions went more smoothly, showing that transparency leads to healthier relationships and expectations.

4. What Makes a Great Product Owner: Trust and the 'Why'

(08:42–12:29)

• Core Skill: Building Trust
  Excellent POs consistently trust their teams and make team members feel trusted.

  "Sharing the why... when you make the team understand why we are doing this development, why we are here, why I'm asking you to change way..."
  — Irene Castagnotto [09:00]

• Practice: Explain the 'Why'
  When developers understand the reasoning behind product decisions, they feel empowered to give input—and POs must listen and often adjust based on that feedback.

• Teamwide Positive Patterns:
  Agile success depends on good habits not just from the PO, but throughout the team—including Scrum Masters. Creating an environment where questioning and open discussion are welcome is essential.

5. Coaching Product Owners: Embedding the 'Why'

(10:52–12:29)

• Coaching Strategy:
  Irene helps POs internalize the need to explain the ‘why’ by immersing them in situations (sometimes through serious games) that reveal the consequences of poor communication.

  • When a feature fails or doesn’t deliver as expected, use it as a trigger to discuss the underlying purpose and to foster productive dialogue, rather than assigning blame.

    "...when a story doesn't work or when a feature doesn't work as expected, we can use that as a source of energy, as a trigger to figure out: why?"
    — Vasco Duarte [12:29]

6. Creating Opportunities for Open Conversation

(12:29–13:33)

• Even challenging discussions about failure can lead to better understanding and improved team dynamics. The act of dialogue, even if initially unproductive, lays the groundwork for more meaningful conversations later.

  "At least you had a conversation about it. You created the opportunity to discuss the why."
  — Vasco Duarte [13:23]

---

Memorable Quotes & Moments

• On the thin line between diplomacy and dishonesty:

  "There's a light line of difference between being transparent and negotiate."
  — Irene Castagnotto [03:16]

• On exposure to client anger:

  "You need to reduce the amount of exposure to angry clients... But it's different coming from us or coming from a shouting client with a red face, right?"
  — Vasco Duarte [05:28]

• On trust and understanding the why:

  "When you make the team understand why we are doing this... it's really a good moment to understand if we are following the good path."
  — Irene Castagnotto [09:00]

• Learning from failure:

  "When a story doesn't work or when a feature doesn't work as expected... use that as a trigger to figure out why."
  — Vasco Duarte [12:29]

---

Useful Timestamps for Key Segments

• [01:21] — Irene describes the anti-pattern of non-transparent product ownership
• [03:16] — The importance of transparent negotiation vs. “making a story”
• [05:28] — Vasco on protecting the team from client anger
• [08:42] — What makes a great Product Owner: trust and sharing the why
• [10:52] — Coaching Product Owners: techniques and real-life applications
• [12:29] — Reflection: Use failure as a trigger for meaningful discussions

---

Conclusion

This episode delivers a nuanced perspective on the vital role of transparency in product development. Irene Castagnotto’s stories underline both the pitfalls of concealing difficult truths and the immense benefits of trust, shared purpose, and open communication. The actionable advice and real-world examples provide invaluable guidance for Scrum Masters, Product Owners, and Agile teams alike.

---

Find Irene:

• LinkedIn
• Podcast (in Italian): Gen Z in Pulu — stories about Gen Z in the world of work and daily life

---

Transcript

[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 Irene Castagnotto. Hey Irene, welcome back.

[C]

Hi. Happy Friday.

[B]

Happy Friday indeed. So we'll talk about great product owners in a minute, but get us started to get the appetite for the rest of the story of the pos. Let's start with what might be even more interesting. The story of a really difficult product owner. Anti pattern. Share that with us, Irene.

[C]

So one of the most difficult part of the product owner that I have to deal with is the speaking with the client. Speaking, speaking with stakeholder, being transparent, negotiate. So it's everything under the same pot because in the end when you have to face the client, the stakeholder, you have to use a lot of skills which are hard and soft skill and sometimes when you miss some of them could be very hard. So one day I was working with this peel and we had to speak to a client and we didn't have positive information to give to this client because what they were asking was not possible at that moment. So something that I was really shocked about was like that he didn't go to the client and say being transparent, but he was making a story. So I was so confused of the reason why he was trying to not being transparent with the client, of course, with the good words. So when I came home I was like, okay, let's see how it goes. I was very worried about the solution. And in the end we produced something that wasn't what the client was expecting. And, and then when there was the moment of the review, the client was very mad. So one of the Anti partners is understand the difference between using good words because you have to negotiate and not being transparent. Because there's a light line of difference between being transparent and negotiate. So of course you have to work to make your team work in a good way. If you cannot achieve something, you have to deal with the client because the client has to be happy. But you have to tell in a transparent way what is not going to be in the development. So this one was, we were very confused about this situation, but in the end I understood that it was also a deal. It was also because the moment was not good for the pill. In that moment I understood it was a little bit panicking. And if you don't have all the tools or the skills in your hand in that moment, it's very hard to deal with a client that is not happy. So sometimes we judge, but in the end it was not that easy situation.

[B]

It's never easy, but if you think about it, it's. If we just think about it from a mathematical point of view, when the product owner hears the anger from the client, that's one person hearing the anger from the client. But when the whole team hears the anger from the client, is many more people hearing the anger from the client. And I think, like, as Scrum masters, this can even be a very useful kind of rule of thumb is you need to reduce the amount of exposure to angry clients. So how do you do that? And many companies do this very well, right? Like they have what you would call an account manager or a technical project manager or someone who becomes the interface, because you can't predict when that difficult moment will happen. But sooner or later there will be a difficult moment with the client and we need to be ready for that. And as Scrum masters, sometimes we might even need to lie on top of the grenade, as they say, and take it ourselves. But the idea is that if you reduce the exposure to this anger, you improve the overall environment for the team. Now, that is not to say that we don't tell the team that the client is angry. Of course we tell the team that the client is angry. But it's different coming from us or coming from a shouting client with a red face, right? Yeah.

[C]

At that moment we didn't have any way to, like the dev team was there with the peel. So in that case we didn't find a solution in, in this, in, in this topic, about this topic. But if I see what happened in the, in the, in the months after a PO was meeting alone and then the devs, I don't I don't. I'm not saying that this is a good things think because sometimes I think that the devs when they are speaking with the client, they not speaking but when, when they are there and they listen, they get, they have like they feel more responsible and also more happy sometimes because they see the client happy. But of course if the client is not happy then there's a problem. So it's hard to choose honestly.

[B]

Yeah. And. And I'm not arguing that the development team shouldn't talk to the client. I'm arguing for the PO to take the responsibility of knowing that they are going to disappoint the client. Do it first, right? Prepare it, have that conversation before bringing the whole team and getting them exposed to the probably not so nice words even in some countries, I mean I used to work in some countries where it was almost like a national sport to shout at the development team and it's not good for anyone. Right. Like the morale goes down, people feel insecure, they don't want to show up anymore. Like there's a lot of negative side effects that come from that kind of exposure.

[C]

Yeah. Also because sometimes it was, was near, I think near the go Live moment. So everyone was working so many hours and you can see that it was not helpful for them at the moment. See some like a discussion like that one. But of course we learn from mistakes. So I think that at the moment like the team understood, the PO understood as well because nothing happened after and also the client then was not like he behaved in a different way the next the time after.

[B]

And talking about learning from mistakes. Of course not all product owners are falling into this anti pattern. Some product owners are really excellent at the work that they do. So Irene, share with us an example of a great product owner that you've worked with. How did they work?

[C]

One of the most important skill that a product owner I think has to do to work with a team is trust. So trusting the team and at the same time make the team feel trusted. And how you do it, you do it sharing the why. So this is very connected. And when you make the team understand why we are doing this development, why we are here, why I'm asking you to change way because sometimes happen that you have to change path. But if you don't understand the why, it's very hard to deal with. And also the devs, when they understand why we are developing this feature, why we are following this path, they also go to the PO and they say okay, but I think about it and maybe it doesn't make sense. Maybe we should do it this way. And then the PO say, oh, you're right a lot of times. So when you go, when you give up to a person the possibility to think about it and also to make themselves questioning what we are doing, it's really a good moment to understand if we are following the good path and if we are doing the good action, the good steps. If the dev team come to you and say, okay, I think about something different, you have to trust them, because if you don't trust them, it's very hard to deal with. So it's not about just being a PO with good patterns, it's about being a team with good patterns, because PO with a good, with good patterns, but a dev team with negative patterns. And also, and it also goes for the escrow master, of course we cannot work alone, we have to be all together. So being together, creating this kind of environment and sharing the why is something that the peel that I see in the PO that really goes in a good way. So this is one of the best thing I ever seen.

[B]

And when you talk to pos like how do you help them understand why they need to share the why and then also in practice, how do you motivate them and help them actually do that work? Because conveying the why for product owners, it really is everyday work, because there's a lot of things that need to be done and a lot of things that need to be understood before being done.

[C]

It's about making them leave the situation. So sometimes we also did some serious gaming that actually led to understand this topic. But the thing that I understood, it works the most is making themselves inside the situation. So when you see that you are asking to dev something and they are developing it, but it's not working and you go through, and you go through understanding why it's not working. Sometimes. Well, not sometimes, but a lot of time you can guide the developers to asking but why we did it in the first place. So this is something that is very powerful to the P.O. because they understand why. Why you don't need the why I told you now, maybe not. Maybe you didn't told us, or maybe you didn't told us in a way that we understood. So now every time we face something new, I ask, okay, Pio, why we are doing this? And at that moment the devs listen and say, okay, understood, not understood or.

[B]

I don't care or they have feedback or whatever. Right?

[C]

Yeah.

[B]

So I really like that idea that when a story doesn't work or when a feature doesn't work as expected, we can use that as a source of energy, as a trigger to figure out why. Right. Like, why didn't this feature work? And how does this link with the other feature that is coming up and the overall project and so on? I think that's a great tip. Right? Like use that, that, that missing why to trigger the thirst and the need to start discussing the why.

[C]

Yeah. Also because sometimes people are very mad about it because maybe they worked a lot or maybe there's a lot of energy, right? Yeah, there's a lot of energy. Yes. And sometimes it leads to good, good, good actions. Sometimes it leads just for a discussion. But it's okay. At least you understood, you talk about it, you just didn't leave it.

[B]

Yeah. At least you had a conversation about it. You created the opportunity to discuss the why. And if it doesn't happen that time, maybe it will happen next time, right?

[C]

Yeah.

[B]

We need to keep on trying. Irene, this was a wonderful week. Thank you very much for shar of those stories with us. But we're, we're getting close to the end. Before we go though, where can people find out more about you and the work that you're doing?

[C]

You can find me on LinkedIn and if you're an Italian person, if you want. I also have my own podcast which is called Gen Z in Pulu and it's talk about Gen Z in the world of work and also in the world of life every day. But yeah, mostly on LinkedIn. And you can find me, text me and send questions if you want.

[B]

And we'll put the link to the LinkedIn profile as well as the podcast that Irene hosts. Irene, it's been a pleasure. Thank you very much for being with us and for your generosity with your time and your knowledge.

[C]

Thank you. It has been an amazing week with you.

[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 [e-mail] 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.

[A]

We really hope you liked our show.

[B]

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.