Balancing Product Owner Responsibilities with Team Empowerment | Antti Horelli

Summary

Scrum Master Toolbox Podcast: Agile Storytelling from the Trenches Episode Summary: Balancing Product Owner Responsibilities with Team Empowerment | Antti Horelli

Release Date: January 31, 2025
Host: Vasco Duarte
Guest: Antti Horelli, Agile Coach

---

1. Introduction

In this episode, Vasco Duarte welcomes Antti Horelli to discuss the intricate balance between Product Owner (PO) responsibilities and empowering Agile teams. The conversation delves into common pitfalls, the evolution of the PO role, and best practices for fostering collaborative and effective Scrum teams.

---

2. The Anti-Pattern: Absent Product Owner

Antti shares a cautionary tale from his early career, highlighting a prevalent anti-pattern where the Product Owner is minimally present with the team.

Antti Horelli [02:37]: "The PO has to be there. You have to have a PO. That's my number one rule."

In this scenario, the assigned PO juggled multiple managerial duties, limiting their availability to mere hours per week. This scarcity led to significant team struggles, including delayed responses to queries and a general lack of direction.

Antti Horelli [03:51]: "Scrum was not working at all like it should have."

Reflecting on this experience, Antti underscores the critical need for POs to be actively involved throughout the Sprint to ensure seamless communication and ongoing guidance.

---

3. Evolution of the Product Owner Role

Vasco prompts a discussion on how perceptions of the PO role have transformed over time, especially concerning their presence and involvement with the team.

Vasco Duarte [04:43]: "Making the decisions. Because the product owner isn't telling the team what to do, they are making decisions about what not to do and of course, therefore also what to do during the execution of the work."

Antti elaborates on the shift from POs acting merely as requirement setters to being integral participants in the discovery and development process.

Antti Horelli [06:24]: "The work we're doing is so complex, you can't really define the end result... you have to have the Business knowledge inside the team."

This evolution emphasizes that software development thrives on discovery and adaptability, necessitating a more engaged and responsive PO.

---

4. The Importance of Collaboration and Shared Responsibility

The conversation highlights the necessity of distributing PO responsibilities to prevent burnout and enhance team autonomy.

Antti Horelli [09:15]: "The product owner takes care of all of that and then the team can kind of do the tick."

Antti advocates for a collaborative approach where roles like QA, business analysts, and UX designers support the PO, fostering a more resilient and self-sufficient team.

Vasco Duarte [11:20]: "Accountability... is actually a strength, it's a power of the PO to be able to share the responsibility and of course, also motivate others to take it."

This shared responsibility model not only alleviates the burden on the PO but also empowers team members to take ownership of various aspects of the product development process.

---

5. Characteristics of an Effective Product Owner

Drawing from his experiences, Antti outlines the traits that distinguish exceptional POs:

1. Consistent Presence: Being actively involved with the team beyond just formal meetings.
2. Knowledge Sharing: Providing the team with necessary business insights and decision-making support.
3. Collaborative Mindset: Encouraging the distribution of responsibilities across the team to enhance efficiency and ownership.
4. Adaptability: Navigating the complexities of product development through continuous discovery and iterative processes.

Antti Horelli [12:28]: "You have to be able to spread it and kind of make it happen and balance it out as well."

By embodying these characteristics, POs can significantly enhance team performance and product quality.

---

6. Modern Practices in Product Ownership

Vasco and Antti discuss contemporary practices that support effective PO roles, such as:

• Strong Product Discovery: Involving the entire team in understanding and shaping the product's direction.
• Role Diversification: Integrating specialized roles (e.g., UX designers, business analysts) to complement the PO's efforts.
• Empowered Teams: Encouraging team members to take initiative and make informed decisions collaboratively.

Vasco Duarte [08:59]: "In software we must discover what we need to do... it's in the doing of the work that we discover the work that must be done."

These practices reflect a matured understanding of Agile principles, where flexibility and team empowerment drive successful outcomes.

---

7. Conclusion

As the episode wraps up, Antti provides his contact information for listeners interested in further discussions or collaborations.

Antti Horelli [12:54]: "You can find me on LinkedIn... Throw me a message."

Vasco encourages listeners to engage and share the podcast to foster a wider community of effective Scrum Masters and Agile practitioners.

---

Notable Quotes

• Antti Horelli [02:37]: "The PO has to be there. You have to have a PO."
• Vasco Duarte [04:43]: "Making the decisions... about what not to do and of course, therefore also what to do during the execution of the work."
• Antti Horelli [09:15]: "The product owner takes care of all of that and then the team can kind of do the tick."
• Vasco Duarte [08:59]: "In software we must discover what we need to do... it's in the doing of the work that we discover the work that must be done."
• Antti Horelli [12:28]: "You have to be able to spread it and kind of make it happen and balance it out as well."

---

Final Thoughts

This episode offers valuable insights into the dynamic role of Product Owners in Agile environments. By emphasizing presence, collaboration, and shared responsibility, Antti Horelli provides actionable strategies for Scrum Masters and Agile Coaches aiming to enhance their teams' effectiveness and product outcomes.

---

Connect with Antti Horelli:
LinkedIn

---

If you enjoyed this episode, please rate us on Stitcher or iTunes, and share it with fellow Scrum Masters to help them access these valuable insights.

Transcript

[Pasco Duarte]

Hi there, Pasco Duarte here, your host. I wanted to share a story with you. You know how sometimes Agile just feels like following another checklist when like processes and frameworks feel more important than what we are trying to achieve and sometimes even like handcuffs. I was talking to a customer of the Global Agile Summit and he used a term that kind of stuck in my he said, I have Agile fatigue. And I've heard that a lot from people since then. But here's the thing, it doesn't have to be this way. So we started thinking and at the Global Agile Summit, which is happening this May, we're bringing together practitioners who've actually done that, who've broken free from this, you know, install the framework kind of mindset. We want to focus the summit on real life, first person stories of Agile all succeeding that inspire you to action. We're talking real experiences, practical solutions, and of course, amazing insights from leaders like Gojko Adsic, who will be one of the keynote speakers, and Jurgen Apelo, who will be one of the keynote speakers as well. If you're ready to leave the Agile fatigue behind, just join us in Dalit. The early birth tickets are now available@the globalagilesummit.com and mark your calendar. We will have workshops on May 18th, that's a Sunday. And then the conference itself will happen on May 19th and 20th of 2025 in Tallinn, Estonia. So let's make Agile exciting again. And remember, go to agile globalagilesummit.com that is, and get your early birth ticket. Now, it will only be available until early March, so grab it now. And now onto the episode.

[Vaskov]

Hello everybody. Welcome to our TGIF and Proctoner episode this week with Antti Horelli. Hey, Anti. Welcome back.

[Antti Horelli]

Thank you. Ettore Friday. Wow, great to be here.

[Vaskov]

Time flies when you're having fun, doesn't it?

[Antti Horelli]

Indeed.

[Vaskov]

All right, so we'll talk about great product owners at the end. So stick around everybody, to listen the story of a great product owner. But first, let's start with the opposite. What might have been potentially the worst product owner anti pattern you've witnessed in your career?

[Antti Horelli]

All right, well, I'll go a bit back into the earlier part of my career and I guess the worst P.O. i've kind of witnessed actually from a side is the PO who was never there. So there was a product owner assigned to a team, but he had a lot of other managerial work to do as well. And at that point I think the PO being present with the team wasn't really required that much. It wasn't understood how valuable or mandatory that is. So it was kind of an hour a day, hour a week, or a couple hours a week or something like that. And you could really see that the team was struggling to understand what they were supposed to do. Whenever they had a question, there was a really long time to get an answer. And I was kind of more junior at that point. Didn't really realize what an anti pattern this was. But looking back at later on, it was very clear that it was not working. Scrum was not working at all like it should have. So, yeah, the PO has to be there. You have to have a po. That's my number one rule.

[Vaskov]

Absolutely. Okay. But in this particular story, the PO was there. You said something that maybe it's worth exploring. At that time, it wasn't understood how important it is for the PO to be present with the team now. And this is very important. Right, Because I don't know when this happened, but certainly in my earlier career, it was perfectly fine for somebody who wrote the requirements to never show up after the requirements were written. Right. Like, it was understood, it was kind of expected. The requirements are here. Why aren't you coding? As the old song goes. So what has changed when you think about the role of the po, the earlier understanding and the current understanding anti. In your mind, what has changed? Why is it so critical for us now and we understand it, that the PO be always present with the team?

[Antti Horelli]

Yeah, I think what I specifically saw earlier in this kind of bad case was that there was a Sprint planning. The PO was there. And kind of after that, the PO was. The next time he was present was maybe in the Sprint review. And at that point the P.O. kind of came in and gave a thumbs up or a thumbs down. Like, was this what I ordered or not? And that was about it. And the first time after that, when I saw kind of what I now consider a proper PO who sat with the team, was there throughout the sprint, helped the team understand what they were doing, answered all the millions of little questions that pop up during development. That was kind of a real eye opener for me because kind of the original one was how I kind of thought that this is kind of what it's supposed to be. And it was like, wow, okay, I was wrong. I didn't understand my Scrum. So I think. And the main thing behind that is that the work we're doing is so complex, you can't really define the end result, the goal, the. The path there, certainly not beforehand. So you have to have the Business knowledge inside the team, with the team to be able to get the understanding while we're doing the work. Whenever a question pops up, whenever something to learn from pops up, whenever we reach a dead end and might have to pivot to another solution, you have to have the business understanding there, otherwise we can't succeed. And you can't do that with the minimal amount of interaction with the po. That's kind of my bad example.

[Vaskov]

So I really like what you just said. Right. Like the things that we need to do are so complex that it is very hard to define upfront what needs to be delivered in the end. So for me this phrase is very important. It is obvious, for me at least, that it's true. But for me this is very important because it highlights one of the philosophical misunderstandings about software that has been there because of project management as a discipline. Because in project management as a discipline there's this theoretical understanding that the end result needs to be defined up front. So you need to define what you're going to deliver before you start working on it. But that is not possible with software, not possible at all. In fact, one would say that even talking about defining what we need to do is wrong in software. In software we must discover what we need to do. As Woody Zwill, my friend, usually says, it is in the doing of the work that we discover the work that must be done. And accepting that totally transforms the role of the person who is. And here's the key. Making the decisions. Because the product owner isn't telling the team what to do do, they are making decisions about what not to do and of course, therefore also what to do during the execution of the work. And I think that this is incredibly important for us to realize that software deliveries are discovered, not defined.

[Antti Horelli]

Oh yeah, that's a lot of really good wisdom there. I love that quote. You had. One thing I think we're doing pretty well nowadays and the teams I'm working with right now are doing very well, is that we moved away from the idea that the P.O. kind of gives the team what they do, defines them what they do. And we have had this strong product discovery happening which the whole team participates in, at least to some level, so that they get at least the high level understanding of what's happening in the discovery, why the decisions are, they are, why are we eventually choosing to go for this solution to the thing, to the problem we have. And I think that's been a huge shift in kind of the thinking, the way we think about product development and like you said we very concretely discover what we need to do when we start, we only have a goal or a problem or something like that. Then we discover the solution during the work. I think that's big.

[Vaskov]

Yeah, I totally agree. In fact, I think there's a whole episode just on that topic alone. But we don't have time for that because we do need to talk about what great product owners do. So, Antti, share with us the best product owner you've ever worked with. How did they work?

[Antti Horelli]

All right. Well, opposite what I said earlier, they are very much present, very much with the team. They're there to give their knowledge to the whole team as is necessary. But also another aspect I think is that the role of a product owner is pretty tough. When I think about Scrum, sometimes I think that the way Scrum kind of helps the team work is that all the messiness, all the uncertainty about product development is kind of abstracted behind the product owner. The product owner takes care of all of that and then the team can kind of do the tick. Well, as I said earlier, I really like the product discovery and that type of thing. And I do think the PO role can be a bit overwhelming if it's at least in many situations. So I do like if there's a product owner who is able to spread their responsibility, or maybe it's not them doing it, but the team spreads the responsibility so that it's not the PO taking care of everything that you can think of, approached or taken care of. You have your QA who can understand the user quite well. You have a business analyst who can do some things. You have a designer who is a specialist in user interaction, understanding user, all of that can help the po. And having good cooperation with these other roles, or maybe just the developers who are, you know, senior and, or interested in, in the business having all that there and the P.O. being kind of a, how do you say, a mismatch or kind of spread over multiple people taking care of care of that side. I think that's. That's maybe one of the situations where I've seen maybe the best success as a po, and that's attributed to multiple people, not just the product owner. But still, I think that's something to maybe strive for. Of course, again, it's about the situation, what's your product, what's your thing? But still.

[Vaskov]

And another great example of a different perspective that has emerged over time because of course, the original Scrum was very strong on this idea of hiding all the messiness and chaos behind the PO role. Right. Like, the PO was very often referred to as the single ringable neck or the CEO of the product, for example. But when you go into a discovery process, just like what you illustrated with your example, it's not possible to have one person only. And many other roles have come up because of that. Like, for example, the UX person that is coordinating and making sure that we get information coming in from the discovery process. Or sharing the responsibility of defining what to do together with the team, like setting a goal, defining a problem, but then working with the team to define the solution. All of those are great examples of, as you said, sharing the responsibility that is in the po. Accountability, as the Scrum Guide these days call it. And I think it's very important for us to realize that it's actually a strength, it's a power of the PO to be able to share the responsibility and of course, also motivate others to take it. Right. Because responsibility is taken, not given.

[Antti Horelli]

Absolutely. Yeah. That's very, very well said. You have to be able to spread it and kind of make it happen and balance it out as well. Yeah.

[Vaskov]

So, Anthony, that was a great week of episodes. Thank you for all of that, all of the stories that you've shared with us. But we're getting close to the end. Before we go, though, if people want to get in touch with you, know more about what you are doing, where should they go?

[Antti Horelli]

Oh, awesome. If you want to get in touch with me, please do. I would love that. You can find me on LinkedIn, for example. So that's probably the most direct route. Throw me a message. Message there.

[Vaskov]

Absolutely. Everybody, why not send a contact request and share a question in the note or a comment or whatever that is anti. Absolutely. We'll put the link in the show notes so that people can easily find you. Thank you very much for your generosity with your time and your knowledge.

[Antti Horelli]

Thank you. Vaskov, Jaime. This was a blast. And as always, I learned. So that's great.

[Pasco Duarte]

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.

[Vaskov]

Remember that sharing is caring.