 Is this thing on? Yeah, it is. I can hear myself. I'm not sure whether that's a good thing that I can hear myself, but let's try that. So you already know what I'm going to talk about. My name is Jan Zoni. I'm an engineering manager at Red Hat, but I'm also part product owner. Been there for quite some time, and I would like to share some of my experience with you. Hopefully, that will help some of you. But first, by the show of hands, do we have any product owners in the audience or product managers? Okay, we've got couple there, couple there, couple there. Excellent. Do we have someone who wants to be a product owner and is not product owner? Okay, we have one, maybe two, three candidates. This is good. So for those of you who are product owners or wish to be product owners, hopefully this will show you what the role is like. For the rest of you, I hope this presentation will help you understand why product owners are the way they are. Okay, so as I said, for the product owners in the audience, this is not a comprehensive guideline. This is not a guide how to do your job. This is to show you that you are not alone. The challenges are transferable. I've been in multiple teams where I was a product owner, and the challenges are pretty much the same. They often appear different, but they are very similar. You should know that you should not panic. It gets better. If your team is starting, there are some very unique challenges, but they do get better in time. And the purpose of the presentation is hopefully to help you understand. I wanna say two things. First, this presentation will be somewhat in contrast to what Jen was talking about in the previous presentation. Because, okay, so let me ask you this. Have you been in a situation where somebody was supposed to make a decision and they didn't, and they were hiding behind, I don't know, a consensus or I don't know, somebody else making a decision or a collective decision? Any hands? Yes, okay, cool. So, that's one thing which I will try to illustrate how to deal with that and what you can expect there. And I also wanna make a note here that this presentation talks about the challenges of product owners, which means it might illustrate the job, illustrate the role in a slightly negative light. Please take that into account because the role is really not that bad. It's just that the presentation is really focused on only one side of the job, not only the good things. Okay, so let's take a look at the definition of product owner. This is what Wikipedia says, or at least Luslim. So, product owner represents product stakeholders and the voice of customer. Makes sense, right? Product owner is responsible for the product backlog, at least partially. There are other people who can help you with product backlog, but it is product owner. Responsibility to make sure that the backlog is in a good shape. And product owner is accountable for maximizing the value that the team delivers. That's the theory. However, when a new team is forming, it gets slightly different. Let's take a look at the reality. In the real world of a starting project, the first two are still pretty much the same. The third one, however, is slightly different in my experience. You, as a product owner, are not accountable just for maximizing the value your team delivers. You are accountable for the success of the product. You are accountable for the survival of the product and the team. And if you, as a product owner, have just one thing to take away from this presentation, let it be this one. You own the product. And in a good way. I don't mean it like you should control what happens in the product, but you are the person who is ultimately accountable for anything that happens. If every other instance, if everything else fails in the team or in the product, you are the one to make decisions if they need to be done. Let's take a look at what does it mean to start a project. Every project starts with an idea, every single one. And I was kind of thinking about how do you define the project being started? Like, where's the end of the start phase? When I thought about that, and what I wanna talk about today is the first release as the milestone, which kind of ends this, the starting of the project. So, and yeah, there is this red section on the left-hand side. Between the first idea and the first people on the project, I'm not gonna talk about that because it may or may not be you to convince all the stakeholders, the sponsors, to give you someone to work on that. It is effectively this point where the project gets started. So, this is what I wanna talk about. Between each two milestones, there are different phases. So, I wanna talk about those and the challenges specific to those and we'll end with the first release of the product. So, you get your first people or you were assigned to a team that works on a specific project and you were asked to be a product owner. So, what's first? Research. We're not talking about academic research here. We are talking about the state of the art. In this phase, you wanna know whether the idea is even technically feasible because whoever came up with the idea might or might not know or they might think it's feasible but you need to be sure before you start working on it. It's also about the state of the art and whether you can reuse the state of the art because obviously you don't wanna reinvent the wheel. So, you want the team to first spend some time exploring the field and what's out there, what they can use, what they can build on. All this ultimately leads to initial implementation. The first code that you can push into a Git repository and the team can start working on it. Let's take a look at some of the challenges. The first one being motivation of the team. Why motivation is or can be a challenge? The thing is that this research phase, it doesn't have to be one day, two day, two weeks. It can be as long as couple months or half a year or something like that depending on how challenging your project is or how big of an idea at the beginning was created. And in this research phase, you're basically trying to solve one problem but from slightly different angles. It might feel, to the engineers, it might feel like they're beating a dead horse just with slightly different sticks. That's not what you want, right? That's not what the engineers want. They want some variety in their job and sometimes it's just not happening here. In this case, what you can do as a product owner, you can give them the sense moving forward. By moving forward, they need to realize that the work that they're doing, even though they're still at the same place, just looking at it from different angles, just use your creativity, do whatever it takes to show them that they are in fact moving forward. You can do a checklist, to-do list where they can check off things that they have done. At one point, I came up with a very creative idea that I unfortunately wasn't able to put in place because I lack of time, but I had the idea of creating a battle map, right? So if you imagine, well, I don't know what computer game is cool these days, I don't know, StarCraft, right? So at the beginning, it's not cool, StarCraft wasn't cool anymore? Right, okay. So if you imagine that you start with a small base, that's where you are at the very beginning of the project, and as you move forward, you explore different areas, and you can draw the map, and then as you go down that path and explore whether it is something that is feasible or something that you should not pursue, you can somehow mark that on the map, and the team will see the maps growing. So that's one of the ideas I had at one point. So really, the message here is do whatever it takes, use your creativity to make sure that the team has the sense that they're moving forward. But there is another thing about motivation. In this phase, a lot of work gets dropped because that's what you do, that's what research of the state of the art is all about. You know, scientists say that even negative results are still results, even 20,000 of them. Engineers often don't like that. If they do something, if they work on something, and then you say, okay, so we're gonna drop this work, and we're gonna go in a different direction, it is not exactly motivating. So what you can do here is to teach them with their managers, preferably, that it is okay to fail if you learn. And by the show of hands, how many engineers do we have in the room? All right, so the engineers in the room, and everyone in the room, stand up, we're gonna stretch a little bit, and I want all of you, there will be three lines here on this slide, and I want you to read them with me. It's okay to fail. It's okay to fail. It's okay to fail. Thank you, you can sit down. To let it sink for a little while, I will add one more thing. Again, I will repeat, if you learn, if you learn from it, it's okay to fail. The reason why it's okay to fail, especially in agile projects, in agile projects, when you fail, when you discover a word which you should not pursue, you waste two weeks of your time, not two months, not two years. It is easier to just try something and go back than spend two months exploring and analyzing something. So another challenge that you can face as a product owner, you can face like a progress when the engineers don't feel that they're making progress, and they can get paralyzed by analysis. You remember what the previous slide said? Kind of ironic, isn't it? Because this is actually a vicious circle, because when your team, when they are not motivated because they're analyzing the same thing just with slightly different directions, you motivate them to keep doing that. Eventually, they can get to this place. They can really get paralyzed by analysis because they lose the big picture and they keep focusing on the problem and they analyze it from different directions. And well, guess where that leads? They get demotivated because they're paralyzed by analysis. So you're back to square one and it's really a vicious circle. So you really need to break it on two sides. I already told you how to break it on one side, how to break it on this particular side is to give the team the guidance. And I will go back to what Jen said in a previous session where I was here. In this case, the best thing you can do and the best thing for the team is to have strong technical leader who can guide a team, who can make the decision, who can make the decisions if they need to be done. In case the team can't make the decision themselves. But if there is no such person, if there is no strong leader among the engineers, guess what? You're the owner. You represent the voice of the customer. So you can be the leader. You can give them the guidance. Obviously I'm talking about guidance, not directions. You can use directions as the last resort. If the team is really paralyzed and needs to move forward, you can make the decision but with anything before that, you must give them the guidance. That's what you do. And by guidance, it can be bringing perspective to the table, which was not seen. You know, something like that. That's what you do. That's what your role. So don't be afraid in participating. Don't be afraid to participate in decisions. That's the message here. So as I said, this is ultimately where it leads. The research phase leads to some code. Somebody needs to write the initial prototype. And if you're lucky, if you're really lucky, the team will do it collaboratively. If you're a little less lucky, the team will do all the research. They will connect all the dots and somebody else, like one person, one single guy or one single one, will take the lead and write the code. And here, this spot, I need to thank to all the Over the Weekend heroes who just go ahead, sit down, drink a ton of coffee, and write it. No matter how ugly the initial code is, they just push it to the repository so that the team can move forward and they can get the job done. They can build on the code, they can improve it, they can refactor it, whatever it takes. In my previous couple teams, I have worked with a few of those and I don't know how they do it. They just do, the rest of the team, they keep arguing, they keep doing more designs, but these people just throw themselves at the problem. They write the code, it's like, okay, now we can work. So if you're listening to this presentation, thank you. So now you have the code. That means you have the first prototype. What starts is early development because now the team can do, the developers can do what they do the best and what is usually the most fun for them. They write code. However, for you, your job now becomes intense because now you need to take care of the backlog. I mean, really care about the backlog because you need to write the acceptance criteria, the user stories, all those things. And some of these things, some of these challenges that we'll see here are not specific to this, to this stage of the development, but they start here. Challenge number one, teamwork. Because what can sometimes happen, especially in a team that is just forming, is that the team is not actually working as a team. I always say that there is a big difference between a team and a group of individuals who coincidentally work on the same project. They don't share the purpose. They must learn that. What you can do here, obviously, you're going to work with their managers, with your scrum master or agile practitioner, whoever you have assigned to your team. Thank you, Fernando. And what you can do as a product owner is push for higher effectivity. And here is what I mean by that. As a product owner, you are an impartial person who can observe and who can point out the implications of the decisions that the people on the team make. As an example, I once was in a situation where one of the engineers, a rather junior person, he spotted, he was working on something in a code, right? And he spotted, while working on that code, he spotted something that needed to be fixed or refactored or changed dramatically. And he realized that it would take about a week to do that. So he went ahead and consulted with his more senior colleague, one of the most senior people on the team. And together they agreed that it's a good idea and that it should be done straight away because it would block them in the next sprint. So they went ahead and did that or the junior developer did that. However, at the end of the sprint, I came to a meeting and some of the deliverables, they were supposed to hand over at the end of the sprint, they were supposed to show at the end of the sprint, they were not done. However, there was a ton of this other work that was done and nobody in the team, except for these two, knew that this work was being done. Guess what? As Jen said previously, I didn't hold the individuals accountable. I held the team accountable because they, as the team, didn't deliver. And I pointed out to them and that's exactly what I said. I said that I would hold them accountable as a team for what they deliver, not just as a group of individuals. And at that point, they started to realize that they really must work together because guess what? The worst case scenario is, somebody else could have spotted the same issue in the code and two people could have been working on resolving that, each one from a slightly different angle because, well, guess what? They didn't talk to each other. So as a product owner, this is what you can do. This is what you can tell them. Show them what it leads to and don't be afraid to take it to absurd dimensions to really prove your point kind of. Okay, so commitment, that's a big one. There are actually several different parts of commitment. What I wanna talk about first is part-time commitment. It happens a lot on teams that are new because what often happens is that your stakeholders, your sponsors, they give you some people you can work with but they don't assign them to your team full-time, maybe like 50% if you're lucky. I witnessed a manager who assigned a person to my team to work there for 5% of their time. It's like, no, thank you. Really, that doesn't even cover the meetings. So what you can do here is regular planning and communication with your sponsors. Mutual respect is what you absolutely need to keep in mind. You respect the sponsors and that they have their lives and they have their decisions to make about capacity planning. And they must respect you as a product owner. They must understand that you are here to deliver something and that you are accountable for the success of the product and the project. So as a specific example, in one of my teams what we did there was at the beginning of each sprint, there was a meeting where we planned the work that we were supposed to do in the sprint. At the very beginning of each such meeting, we did a quick round and each person in the meeting would say for how much they can commit to the project in the next two or three weeks, depending on how long the sprint is. And they just worked because you kind of know what you can expect in the next two weeks. Obviously not in 100% of cases because if CVE comes your way you need to drop everything and you need to work on that CVE. So that still happens but even with those in mind you can plan up to 90% of your time and you can work with that as a product owner. You know what the capacity of the team will be. Overcommitment, that doesn't have to do anything with sponsors that has to do with the people on the team. So there are two types of engineers at least in my experience. Those that tend to overcommit themselves by underestimating complexity of the tasks at hand or well and or overestimating their capabilities or well their capacity. And the other one is the exact opposite. I will talk about that on the next slide. So in case you have a team that tends to overcommit themselves put more things on their place that they can handle what you can do there obviously is a capacity planning and this is a long run. You need to start by collecting data. And in my experience the team typically doesn't like that because well they need to do some work on estimating and they need to be consistent in their estimations and they need to keep it doing for weeks and months. But in time you will get some real numbers that will show you what is the real capacity of the team. And if they keep being consistent they eventually start doing the estimates right. Or like if they don't the estimates are still relative to the capacity of the team. So you as a product owner can do some real planning. Under commitment that's the second type of engineers that I have worked with. In this case the engineers try to well not try to they unknowingly mostly unknowingly overestimate the complexity of the tasks at hand or they underestimate themselves their capacity to do work. So what you can do here is have solid backlog. If you remember one of the responsibilities of product owner is to build backlog. If you don't do that or especially at the beginning it is difficult at the beginning of the project because you as a product owner don't know what's going to happen exactly. The product, the project is still fresh. You should ask for help. And by help I mean help of the engineers because at this stage at the early development what happens what typically happens is that the team is building foundation on top of which the functions will be built. And building the foundation that's mostly technical problem you know that there are technical challenges. So it very often happens that the team knows much better than you what needs to be done in the next four, five, six weeks. Ask them ask them ahead of the time it is much better than not doing them and experiencing what I have experienced once or twice. That the sprint starts halfway through the sprint your team doesn't have anything to do because you know the sprint whatever was planned for the sprint is done. Okay what comes next? The backlog and there are some things in the backlog that are not exactly specified. So guess what they do the engineers do what do they think is best for the team and for the project. At Red Hat we have an expression for that. Pizza we didn't order. Product managers like to use that. And that's exactly what will happen to you if your backlog is empty. And you know asking engineers to help you with the backlog it will help you with one more thing which I will talk in a little while and that is like general communication between yourself and the team because you as a product owner also need to understand what's going on in the team what technical challenges do they face because that will help you understand their capacity. So now you arrive to the first demo something that you can actually show to your sponsors and to your stakeholders. Hopefully it went well. So you must now push for the release. Your development continues but you have one more responsibility right now and that is communication with the stakeholders because for the first demo you can still do that it still makes sense. However it is only after the first demo when you have something to talk to them about something very specific something that you can have conversation about how to improve it. And also you need to start prioritizing more because at this point it's this point where the requirements start coming from the outside hopefully which is exactly what the first challenge is at this point. Feedback, getting feedback. That's the risk is that you will not get any feedback or that you will get too much feedback. And when you're getting feedback in my experience what you in the challenging situations if everything goes well you don't need to be too assertive but in challenging situations this is the best answer. I will talk about three specific scenarios that I have seen. Self-appointed stakeholders that's the first one. So by the show of hands how many of you encountered people who just you presented something or you were in a meeting and suddenly there was this one person who raised hands like okay we definitely need to talk because we're gonna use that or we're gonna depend on that or we wanna participate in this or something like that. So who has that experience? Okay so about quarter that's not as bad as I thought. So yeah self-appointed stakeholders the danger there is that many of them just wanna be in everything. It happens. Now the question, the real question is whether they have some real stakes in your project. You know being assertive here meaning means calling their bluff. Ask them tough questions. Why are you my stakeholder? What exactly do you wanna do with this project? Why are you gonna depend on this? What do you wanna build on top of this? You wanna participate? Great how are you gonna participate? You know ask these questions to make sure that people who say that they're your stakeholders are actually your stakeholders. There is another group of stakeholders. The group that you know that they are actually your stakeholders but they don't talk to you. They don't give you any requirements they don't tell you what they want you to do. What you can do here being assertive nag them. Keep asking them for feedback. Keep contacting them, emailing them, texting them. I don't care having meetings with them. Whatever works. Make sure that they understand that you need their feedback. And there is a third group which is kind of similar to this one. Those are the people who give you their ideas. And I have at least one specific person in mind. This group will give you their ideas but then disappear. Anyone experience those? Right. And again, what you can do there, communication over communication basically. Talk to them. Try to get in touch with them as much as you can. And if they still don't communicate any of these two groups warn them that they will be ignored if they don't respond because it is not up to you to fly blindfolded. You must have a direction. If they want to be your stakeholders they must be active. It's a two way street. But if all that works for you you should be careful what you wish for. Because you might get just that. I get a ton of feedback, ton of priorities. And I like what Jen says it is always awesome to have just one priority number one. Doesn't happen that often, right? So there are two things here or three things here. Obviously you need a team to follow priorities. What can happen here? Either they have too many priorities or they have no priorities. Or they're not sure what their priorities are. So obviously expectations. You must set your expectations with the team. You must keep communicating the expectations. In my current team what I do every two weeks I sit down with a bunch of people from the team and we review sprint high level goals. Not like those are not specific like what needs to be done in every sprint but what I expect to see at the end of the sprint because there are dependencies on something else outside of the team for example. So make sure that the team understands what the expectations are and these expectations can be built up front. We're not talking like what is the expectation just for the next sprint but even for the next one, the one after that. You can really go as much into the future as you want as long as the team understands that these priorities can change every two weeks. That's why you're agile, right? Also having capacity buffer helps because as I said in some cases your team will not follow the priorities because they see something that needs to be done to unblock them. Can be for example, a story of this week in my team broken CI and you kind of must fix broken CI because if you build your process around that if your CI is broken you will not get any commits in because it gates your commits. So obviously you need to fix that. The key there is that the team must tell you first and foremost that something's broken and they need to work for it so that you can adjust your plans. And as a product owner when you plan you can do better capacity planning. Plan only 80% of team's time to work on things that you want them to do. Leave those other 20% to these things such as broken CI or CVE coming in. Those things that you cannot predict. So the first change in direction. That's not exactly optimistic but it happens. It happened to me every single time in my starting project. At one point the stakeholders came, the sponsors came and they basically said, we don't want you to work on this anymore. You should refocus on something else. It does happen. Guess what? You're still getting to release. There is no way out of it because your team hopefully continues, right? And now it depends on how big the change of direction was. You may end up at the beginning because the direction changes really dramatically but I'm not revinding my slides. So let's assume that does not happen. And let's consider that the direction moves only a little or moderately that you don't need to drop all your work. So you're still pursuing the first release. However, your risk now is that the team loses motivation because many engineers are on your team because they wanted to work on that specific project. It happens, it happens very often. It can also happen that the team is demotivated by the change in direction itself because again it means that some code needs to be dropped or some research needs to be dropped or something like that. Or they don't buy the change of direction. So there are two things that you can do here and that you should do here. Work with managers first and foremost because whatever you do at this point you will be stepping outside of your role a little bit. So if you work with the managers to make sure that you need to understand how the team feels. If the change of direction is a problem or not. If it is then work with your managers, work with people managers so that you understand why they are upset. What you can do as a product owner is show them value. Communicate why did it happen? Why the change of direction? What's the value in the new direction? What's the purpose? What's the new purpose of the team? They must understand the team's purpose so that they can align with that purpose and hopefully stay on the team if they buy that purpose. Obviously, in many cases many engineers move away from the project because they just don't share that purpose and that is okay because you typically want engineers who believe that purpose. So make sure that you communicate that. What's the value? What's the new value? What is it that you're gonna deliver? So you got to your first release. You did it. It's out. You must now get your customers. But as I said, at this point, hopefully your team is well established. You know what your goals are. The team works like a well-oiled machine. In which case, I can only say congratulations and good luck finding customers for your project. Thank you very much. Any questions? Yes? I'm sorry. So the question was if I had the customers before or when I started the project, right? So in those cases, it can be customers but I would more classify them as sponsors. Sometimes you do have the customers because you're creating the project for someone specific in mind. So it can happen. But typically my experience is that you have like certain type of customer in mind. You know, some target group. You don't have any specific customers. You just know who they are and who will you talk to when the first release is out or when the first demo is out. But it is always a good idea to keep an eye on those and to make sure that you still keep in mind who the target audience is and who are you going to talk to and basically talk to them as soon as it does make sense. You know, many other customers, they don't want to see, you know, sometimes they want to hear about the first idea. Sometimes they want to see the first demo. Sometimes they're only interested in your first release so it kind of depends. And if you know who your target audience is, you know, being in touch with them is generally a good idea. Any other questions? Yes. Right. Great question. The question was, how do you decide as a project or product owner when it's time to call the project itself failure? So two things. I was talking about mostly about like, it's okay for engineers to fail in meaning finding a path which not to take, right? So that's one thing. That is absolutely okay to fail if you learn from it. Like I said, as the scientists say, negative results are still results. However, to your question, I guess I would say that it's never fully up to you because ultimately you have some sponsors, you have some stakeholders. So it is at this point, it is about collective decision. However, obviously you are in position where you can give them guidance, where you can communicate what your position is. So when I don't see any path forward, and I actually did that about a year ago or two years ago, we had this project basically extracting applications into containers. We call them like giant macro containers, basically like a VM, like a container. And so what I did there, I talked to a bunch of potential customers, and all of them unanimously said that this would have been cool if it came like two years ago, now we don't need it. At that point, I talked to my stakeholders, I talked to my customers, well, sponsors, sorry. And I basically told them like, hey, so I got this feedback, I think it's time to focus on something else or invest in that particular case, not in macro containers, but go back to the drawing board and figure out how do you split up an application into microservices. So that's basically how I did that, but it's never fully your decision. So the question was, what are the difficulties of, well, my specific case is that I'm a people manager of the team as well as the product owner of the team. So what are the challenges of that? Yeah, so I would say there are mostly advantages because obviously you have, well, yeah, you have more influence over the team. Obviously it's more difficult to stay away from being the authoritative leader because, well, you have authority of two different roles, so not to misuse that, that's a huge challenge. And other than that, I guess the time because both people manager and product owner, those are full-time roles, and me being in two of them doesn't make it easy. So time is the most difficult one. And in my case, how I handle it is just that I try to delegate. So I'm not the one responsible, so they're responsible for the product backlog. I partially delegate it to the team and I let them decide. I basically give them the high level goals for sprints and it's up to them to decide how to get there. So from that perspective, it actually kind of helps not to be the authoritative leader. When you don't have the time to be authoritative leader, you don't have a chance. Okay, any other questions? Seems there are none, so thank you very much.