Should the Product Owner delegate?

Should the Product Owner Delegate?

[00:00:00.570] - Pawel Felinski

Hello. Welcome to Agile Encounters. Today's topic is should the product owner delegate? We will cover the following topics. First of all, we will start with product owners accountabilities, how it looks like in theory, but also and that's very important, what's the practise then? Which of accountability of the product owner could be delegated? Which should be delegated? When? Are there any conditions over here? And a special topic at the end. Is the product owner alone, single, fully accountable for the success of the product or actually not? Together with me. Michael Murphy, VP of Product Management in Cybersecurity Industry. My name is Pawel Felinski, I'm director at Meirik and we will talk about it for some time. If you have any questions, don't hesitate to write them down in the chat window. There will be also a space for Q and A at the end. So let's roll. The first topic that I would like to start with is actually the fury. So what are the accountabilities of the role of the product owner? As it is written in the Scrum Guide, the product owner is one of the roles or nowadays we say accountabilities in the framework.

‍

[00:01:20.340] - Michael Murphy

And the latest update to the Scrum Guide took place in 2020. According to the book. Well, the major accountability of the product owner is to maximise the value of the product. That's above and everything else. However, it's also about effective management of the main artefact of the framework, the product backlog. And what does it mean? It's first of all crafting, but also communicating the product goal, clearly communicating what's inside the product backlog when ordering the items in the backlog and ensuring that the backlog is understood, it's transparent and visible, but that's fury. Michael, how does it look like in Practise?

‍

[00:02:01.510] - Pawel Felinski

Well, I actually think, I think about this beforehand and I actually don't think there's too much difference, but I break it down as this. I think that from my perspective, the most important thing that the product owner has to have is the vision. Here it's described as the product goal and the vision should of course speak about the value. I mean, if you haven't got a vision which describes to people why it's worthwhile doing what you're doing, then you should be asking yourself what's the point of the product vision is really important. I think having really clear vision, being able to communicate that vision, making sure you can bring everybody along with you, that's really a really important accountability of the product owner.

‍

[00:02:42.050] - Michael Murphy

If I may suffain. Typically people think vision is what you would care about at the very beginning or even before you start. Is it so? Or there are any activities that you see product owners have to make during the interlength of the product development.

‍

[00:02:57.540] - Pawel Felinski

Yeah, I mean the vision is constantly evolving and there should be no qualms about that. Things change, environments change, stakeholders come and go. We learn more about the product once it's out there with customers, of course the vision will change as time goes on. So no, for me the vision, the development of the vision is clearly an ongoing activity.

‍

[00:03:19.310] - Michael Murphy

Fair enough. What else?

‍

[00:03:21.630] - Pawel Felinski

I think the other big thing that you're responsible for is the scope. If you left the scope often up to the rest of the team, it's very likely to be much larger than it needs to be. I think one of the things that I find myself doing most often is trying to restrict the scope as carefully and defining it as carefully as possible. So it's really about defining what's important to be there in the product and what's not. I would say for the most part I'm talking about big picture and we'll talk a bit more about this, I think, in the next section. But I think there are parts of scope that certainly the bigger parts of the scope is what the product owner is very accountable for. Some of the smaller things that the kind of fine detail of the scope maybe is the bit that a product owner can be less accountable for. Certainly when it comes to very deep technical details that you're probably not going to be expert enough to be able to decide upon but certainly in the big grand scheme of things, what's in and what's out, that's a very important accountability.

‍

[00:04:18.050] - Michael Murphy

And I'm happy to hear that because apparently the Practise is as it was designed by the book so the backlog the scope and division to comment what you've just said, it's a story that is very old but years ago when I was a very young trainer it was before Pandemic, definitely. So in the classroom, not remotely, I was drawing avatars of different Scrum rolls and my product owners avatar was always said and very often people ask me why the programmers said and I said well, wait till the end of the training could learn because of the number of accountabilities but was something else. I thought that one of the key accountabilities or maybe skills of a product owner is the ability to say no because there's always too much scope for resources that you had, budget and so on. In your Practise, do you see there are other major accountabilities of product owners or people in the role of product owners beyond that list that Scrum provides?

‍

[00:05:26.340] - Pawel Felinski

Yeah, I think whether it's right or not, often the product owner tends to be accountable or if you like, they tend to be the font of all knowledge when it comes to how things work and what it's for. It's a little bit about the vision but it goes a bit further than that. As a product owner you typically sit at this intersection between lots of different disciplines, you have lots of different stakeholders you talk to and they rely on you to be able to answer questions why does it work this way? Or remind me how this feature is supposed to work or tell me what's coming in three months’ time. And those are things that I think very often you're seen as the person who's supposed to have all those answers, whether you have them or not. So I think that's another whether or not it's kind of an official role, it's one that I often find myself filling, having to know everything almost about what the product is and what it does.

‍

[00:06:19.210] - Michael Murphy

I have to ask these questions at this moment because I receive it so frequently during different encounters actually. So should the product owner be technical?

‍

[00:06:32.210] - Pawel Felinski

Whatever it means, it's hard for me to answer because I am technical, so it's difficult to know what it would be like if they weren't. I mean, I have worked with other product managers and product owners who have been less technical. I think that the product owner role is very broad and you have to be somewhat of an expert in many different areas you have to be somewhat of an expert in the technology and in the business side and in the marketing side and in the communication side and in the design side. Breadth, I think, is very, very important to the role. Do I expect you as a product owner or would I expect a product owner to know every fine detail technically of how something works? Of course not. But you have to be competent enough to talk about and to understand when you're in the room talking with the team about how things are going to be made and how things are going to work, you have to be able to follow along and to be able to make judgments about things. Because if you can't, you're going to miss out on important scoping questions and you're going to miss out when scope creep is happening because you're not going to necessarily understand something that's being said and something that's being proposed as a solution.

‍

[00:07:40.570] - Pawel Felinski

So I think it is very important, but it's easy for me to say because I come from that background and so I find it a bit more natural maybe than others how much the.

‍

[00:07:49.430] - Michael Murphy

Product owner should be in control, for instance, of the scope.

‍

[00:07:55.030] - Pawel Felinski

I think this is something that I've evolved my understanding of over time. I would say when I first started as a product owner I was convinced that I had to really make decisions about everything and control everything. I think as I've gone on in my career, I've realised that not only is that a bad idea in terms of my own sanity and time, I think it also ends up being a really bad idea for the product because I think we might get onto this in the next section. But there are things about the scope and what can and can't be done that you are not in always the best position to really understand and maybe you can still help make the final decision on those things. But I think you can start to get more input from people around you about elements of scope that you would not have considered yourself as a product owner. So I do think, big picture, I think it's important for the product owner to make decisions around that. But certainly when it comes down to very small scale elements of implementation and features, I think it's actually quite important to give that away and saying, you know what?

‍

[00:09:01.420] - Pawel Felinski

I'm going to empower you to be able to make that decision as you go along, whether you're going to be able to put that feature in or tweak that element or whatever else it might be.

‍

[00:09:12.510] - Michael Murphy

I hear you. So let me try to recap if we take a look at that slide again. So apparently in Practise, the product nor covers these accountabilities. There's something about the vision of the product but evolves, and it's not a onetime activity, as far as I can hear. There's a lot about scope, but also many other activities design, communication, understanding your domain, your product. I think with the product owner, because we are to talk about delegating work and I know that you can delegate down there to your team, maybe to your stakeholders as well. So before we go into delegation itself, I just wonder again in your Practise, because I'm pretty sure you met excellent, fabulous product owners and those that have to learn a lot still, how much time the effective ones spent working with stakeholders versus with developers, maybe, versus something else, maybe third layer or fourth even layer of time that you need to spend. How does it look like?

‍

[00:10:13.250] - Pawel Felinski

Oh, yeah, that's a good question. I think in Practise, you're obviously going to spend much more time with your team. I think that's really important because the majority of the time is spent communicating downwards, breaking things up, going through stories in detail, explaining acceptance criteria, getting feedback, iterating with the team, reviewing the work that's been done. So the majority of the time, I think, is naturally spent with the team. That's not to say, of course, that it's not also important to constantly be checking in with stakeholders. That's why in Scrum you have things like Sprint reviews, et cetera, where it's really important to get your stakeholders along and listen to what's been going on. So, I mean, maybe in an ideal world, it might be something like 20% of the time with stakeholders, 80% of the time with the team. I guess in Practise, to be honest, it's very easy, and I've seen it happen for product owners to really bury their head in the teams and forget about the fact that they have customers they have to make happy. So if you can aim for that kind of 2080 split, maybe that's a good line to go across.

‍

[00:11:17.350] - Pawel Felinski

I'm in a lucky position right now because I have a team of product managers that I work with, and I get a lot more time now to focus on the stakeholder piece. But the flip side is then you're further away from the product itself, so you've got to be even better at communicating downwards, I think.

‍

[00:11:36.110] - Michael Murphy

All right, so the question, which of these accountabilities the product owner should which could which should delegate? Are there any patterns here, in your opinion?

‍

[00:11:50.690] - Pawel Felinski

I certainly think you should not, and I actually don't think you can delegate. Probably the most important one to me, which is the vision. I think the product owner's job primarily is to own that vision. And it's back to what you were saying about from the Scrum guide about making sure that you create value. I do think that really the product owner is the only one in the position to be able to create the vision and to articulate the vision. And it's because of that unique position they have in the business, I think. So that one, having that single voice, that repetitive voice, that clear voice about the vision, I think is really important. I've never delegated it. And I was thinking back to my previous roles that I've had. I used to present things like what I used to call product forum, where we would get up every six weeks and go through what we're doing and what's coming next. And I just can't imagine anybody else being able to deliver that presentation. I mean, it just has to come from product, from the product owner.

‍

[00:12:49.350] - Michael Murphy

If you're keen to listen to my perspective, because hearing you, I just thought the vision actually not so independent, but separate topics. Very often coaches or trainers focus on the first one only. So how to craft the vision, what templates, what canvases that help you create the vision? Write it down. But I think even more important part of working with vision is the ability of communicating. It putting in words that are motivating, that are understood. And here, if this is indeed one person doing it, the communication, the communicate would be the same today, tomorrow and that and day after tomorrow, if I have three or more people communicating, same visit, always slightly different, nuanced accents might be different. All right, what else? If not the product vision, what else would you delegate?

‍

[00:13:47.690] - Pawel Felinski

Yeah, I think, as I said earlier, I think one of the things that you definitely can delegate more of, and you should be looking to delegate is some of the scope. If you tried to go down to the minute scope of every single feature, you could be there for a very long time. And I think depending on whether you think this is a good idea or not, many businesses have particular roles, like business analyst, for example, who live to kind of get into that detail as well and who can really help you and support you as the product owner in breaking down aspects of features into very fine grained detail. So I think that side of it, that the real detail of the scope can be delegated and probably should be delegated in some places. I also think particularly when it comes to giving the engineering team as well a bit more freedom about the way that they can implement features as well. I think that's also really important. So there are some things that you should, I think, delegate in that space and say, actually, let's let the experts in on this a bit more and let them make a bit more decisions about how things can be done.

‍

[00:14:56.430] - Michael Murphy

I'd like to understand it a little bit more. So is that that I have scope and part of the scope is delegated to my team to BA in my team? Or is that that some of your scope is yours, some of scope is developers or is it that for all items in the product backlog. You just originate them and to some extent. And then the rest of the job is done by the team. How do you see it?

‍

[00:15:24.600] - Pawel Felinski

Yeah, so in Practise, the way I often do it is I will kind of go in with my here's my initial proposal for what the scope should be. But it's a discussion, it's a debate, it's an attempt to reach consensus. That's really what that scoping session is all about. So I often will say, look, I put this thing in here and I think it's an important thing, but let's talk about it. You tell me, you tell me as the engineering expert or as the quality expert or the design expert. Maybe you tell me whether that you think that's going to be difficult to achieve, whether you think it's going to reach the goal that I have, et cetera. So I think those things definitely need to be part of the discussion. And that's a bit where I think, again, I don't know whether delegate is the right word, but it certainly should be something that's discussed and it should be something that you can work on together as a team when it comes down to the finer detail of the scope. For sure.

‍

[00:16:24.410] - Michael Murphy

All right. Is there anything else you would delegate?

‍

[00:16:31.310] - Pawel Felinski

I think, again, maybe I'm too controlling the product owner, but I find it very hard to give those. The other one that you have, I think, which is really important is the determining the priority of things. I think that's a very important accountability of the product owner. I think what you had there is ordering the backlog is another way of saying that that I think, again, you need to be aware of all of the moving parts that are going on around you in the business. And the PO is uniquely positioned to be able to do that. And you also have to be able to take the feedback from the team back to the stakeholders and say, that isn't going to work in the way that you think it is, we're going to have to move these priorities around. So it also works in both directions. And that, I think, again, in my experience, has been very difficult to delegate. In fact, if you try and delegate and say to your stakeholders, you decide what we're going to do next, often you get yourself to a very difficult position. Counterproductive.

‍

[00:17:28.730] - Michael Murphy

Totally.

‍

[00:17:29.220] - Pawel Felinski

Yeah. I think there is an important skill in being able to make people feel as though they're part of that process and not just to make them feel it, but actually to take their comments on board. And of course, stakeholders have an important part to play in deciding priority, or at least feeding into priority. But I think, again, the ultimate decision has to come down to the product owner. I was really lucky in my last role. I worked with the CEO very closely and he completely trusted me as the product leader to make those priority decisions. And sometimes he didn't agree with them. And he would even say to me, I'm a bit worried about this, that we're not looking at this thing over here, which is really big and scary and is flashing at me, but I'm going to trust you, you're making the right decision. And you know what? Maybe I didn't always get it right, but the fact that he trusted me to do that, I think that was really important. And if you don't have that as a product owner, I think you'll find it really hard to do the job.

‍

[00:18:21.360] - Michael Murphy

Absolutely. I just wonder, would you delegate? I'm not saying delegate to the team elsewhere, such accountability as stakeholders management, for instance.

‍

[00:18:35.510] - Pawel Felinski

I think that's maybe something that's, again, a little bit difficult to delegate, partly because having the relationship with the stakeholders I think is so important. You never want to be the second person that the stakeholder goes to. You want to be the person that they think of coming to first. And the more that you delegate that, I think the more difficult it is to maintain that relationship. I think what is worth pointing out, certainly from my experience, is I've worked a lot in very small companies, so perhaps when you get to a certain scale, you're maybe just not able to manage the number of different inputs that you have. And maybe that's where it becomes time to think more about that. But I think as long as you can hold on to it, you really should.

‍

[00:19:17.810] - Michael Murphy

I think that's a very bold statement. You don't want to be the second person or stakeholders who go to I brought this one up for a reason. I know a bunch of product owners, pretty junior in their role. They were quite comfortable working with the team, but not necessarily working with very senior stakeholders. And the best, in their opinion, thing they can do, they can delegate it. Let my colleague or my fellow project manager deal with that. And they are still in there, what I would call, although I don't like this phrase, comfort zone. Well, actually, perhaps becoming the second person to go, they're actually leading to something absolutely counterproductive for the product also for them. All right, I think we are ready to move on to the last part. Let's take a look at it. Very often, product owner is visualised, if you want, as a person or a role that is alone. Of course, the product owner is a part of the Scrum team. We have developers of Scrum Master with everything, the Scrum framework. There's the golden rule one product equals one product owner. We don't have more of them. But does it mean in Practise that product owner is absolutely alone and there's nobody else except for the rest of the Scrum team that help them in the role?

‍

[00:20:42.910] - Pawel Felinski

Yeah, I think it's a really good question and actually one that I hadn't thought about before you posed it. I think to some degree, being a product owner can feel like a very lonely role because you are ultimately, as we talked about, accountable for some very big things. Scope, priority, vision. These are things which sometimes it feels like you're carrying that mantle alone. Personally, in my experience, though, I've always really relied heavily and have forged very strong relationships with senior people in my team. So I always have made an effort to forge really strong relationships with the senior engineers, the senior architects, et cetera, because they're the ones who will be able to help you through some of those decisions that ultimately you are the one that needs to make. But you don't have to feel like you necessarily have to make it alone. I think I said as well, the relationship I had in my last business with the CEO was incredibly important to me. And we talked about lots of priority decisions, lots of decisions about what we were going to do next and where the product was going to go in the business.

‍

[00:21:47.730] - Pawel Felinski

And it was never a feeling like I was out there on my own. I always felt like I was definitely supported. And that's also really important, I think, as well. So I think, again, it can feel that way sometimes. But ultimately you need to make sure that you're fostering strong relationships with the wider team, whether that's the engineering team, whether it's your stakeholders. And I think that's a really important part of the job to make sure that you don't feel unsupported, you don't feel alone, and that the decisions that you're making will get that wide support from the rest of your colleagues.

‍

[00:22:25.070] - Michael Murphy

One of the pieces of advice that I heard once a senior product manager that was giving to her, her junior product manager was that if it's overwhelming, is it too much to think about communication, design, engineering and so on? Stop thinking in details about all of that, because at the end of the day. Your major job is to make decisions only you don't have to collect all the information. So my advice perhaps to product owners would be you're not alone. You can have even external companies working for you, providing your data, providing information and you're just making decision about it. Would it make sense?

‍

[00:23:06.280] - Pawel Felinski

I think that's a really good way of thinking about it. I think that is as well. That's probably the most important job that I have is to make decisions. I've been amazed actually at how difficult even very senior stakeholders seem to find it to make decisions. And often I think one of the things you have to be really good at as a product owner is being comfortable making decisions in an environment where you do not have all the data. And if you can do that, you are very far along the way to being a very good product owner. Because we always work in that environment, we're always in an imperfect world, we never have all the answers and you still have to be able to make decisions that move the business forward. And sometimes you'll get it wrong. But I think that's absolutely fine. It's better than not making any decision at all and leading to a lot of chaos and confusion and people ultimately losing faith in your ability to do the job. It's a really good point. Decision making is really critical.

‍

[00:24:00.350] - Michael Murphy

Each time I'm meeting product management professional, I always ask the same question. So it goes to you as well as my final one actually. What do you find the one most important critical skill or trait of an effective, successful product owner? If you were to name just one, what would it be?

‍

[00:24:25.270] - Pawel Felinski

That is a good question. I think it's kind of what I said earlier. I think the ability to listen and absorb information from all parts of the business, whether it is marketing, whether it's the business priorities, sales, design, engineering, the ability to soak up and understand at a reasonable level across all those different industries and kind of disciplines I think is the one thing that will give you that success. And it's hard to cultivate that. And you have to really sometimes put yourself out of your comfort zone. You have to learn things you never thought you'd learn before. You have to put yourself in the rooms where you feel like the stupidest person in the room sometimes. But that's the only way you're going to learn about all the different parts of the business that you need to learn about. So that's the key to success really for me is having that ability to speak everyone's language, I think I call it.

‍

[00:25:22.310] - Michael Murphy

But I'm not sure if that's the same situational awareness to being aware of everything that's going on inside your company but on the market as well because we need to listen to the trends as well. Pretty hard. Pretty hard. But also I think rewarding, satisfying. Jeff all right, thank you. Thank you very much. I think we're ready for Q and A. If you have any questions to Michael or to me, the Q and A mode is only may write it down in the chat and we will try to answer the questions. We're going to give you a minute to write it down. While you are writing your questions, if any. I'd like to tell you what will happen next month. We have, of course, a date and time. Also speakers for the next webinar set. It's October the fourth. Peter Shiplin myself will be talking about, well, we don't know what about, we have no clue. Because this time we would like to ask you, everybody, the community and the internet, what would you like to listen to? If you take a look at the top bar right now, you can click the vote button.

‍

[00:26:37.570] - Michael Murphy

It would move you to LinkedIn to the profile of the next webinar. Even tiny survey four topics, the one that scores the most will be the topic that we will be talking about in October. I'm taking a look into the chat window versus a question. Somebody's typing it. The moment I see it, we will talk about it. So can I give you half minute more? All right, here's the question. Let me show it to all of us. Give me a second. Pop is asking how do you deal with a situation where you realise in hindsight that you made the wrong decision? How do you communicate that?

‍

[00:27:28.460] - Pawel Felinski

Well, I think, first of all, you have to be completely honest about it. I think if you try and hide it, you'll probably get found out very quickly and that will only undermine you for more. So I think it's very important that you own that wrong decision. As I said, we live in an imperfect world with imperfect data and sometimes you will make a decision that in hindsight you look back and think, if I knew what I knew now, then I wouldn't have done that. So I think that's one important part to say. Sometimes we get things wrong and it was because we didn't know everything we knew at the time. And the important thing, I think, is to articulate, well, what are we going to do better next time? So the important part of the communication has to be, yes, we did something wrong. Yes, it led to maybe a customer is unhappy or something else. How are we going to do better next time? Are we going to make sure that we have a better process in place? Are we going to make sure more people are going to be reviewing what we've done?

‍

[00:28:15.770] - Pawel Felinski

Are we going to have more consensus before we do it? But, yeah, very important that you don't again try and hide it or certainly that you blame it on someone else or anything like that. The book stops with you ultimately. As the product owner.That's interesting because my answer to your question would be so different. I do agree you should not hide it. Absolutely. No, you have to deal with that. That's your responsibility and you have to be very bold about it. But my perspective is slightly different. I believe, maybe it's naive, but I believe that when we make a decision at time of making the decision, we truly believe it's a good decision. It's only that after some time shorter, longer time, we realise that the decision was wrong. So I try to speak from slightly different perspective. Okay, it was wrong, but this is what I learned. I'm asking myself, my team, what have we learned based on that? Because apparently assessment of the situation, our situational awareness at the date time when we make the decision was simply wrong or not sufficient. What have we learned? Maybe because I grew up in few companies with sort of blaming culture, we're looking for a person to blame, not thinking in a very constructive way. What have we learned and how we can deal with that similar situations in the future. All right, cool. I can't see any more questions, but if you are typing it, I will say it. So just one more minute for you to take a look and write it down. And while you are writing down your questions, I'm moving to the last slide that I promised. So Agile Encounters part eight next month, October 4 at six in the UK or seven in Central Europe. You can use the QR code over here to open the same page as the one that you will open clicking the vote button. On top of that, we have four interesting topics, pretty independent one really. Once Pichib is an Enterprise Agile coach and together with me we'll be trying to cover one of this, the one that will win. It's still nearly full week till the voting is ended. So take your time and vote wisely can't see any more questions. So I think we are good. Michael, thank you very much for being with us today and I wish you all have a very good evening. Thank you. Goodbye.

‍