Vaskov (3:51)

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 (4:43)

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 (6:24)

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 (7:59)

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 (8:59)

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 (9:15)

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 (11:20)

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 (12:28)

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 (12:38)

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 (12:54)

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 (13:08)

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 (13:25)

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

Pasco Duarte (13:34)

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 (13:47)

Remember that sharing is caring.