 Alright, 30 more seconds, we haven't quite got all the tasks listed out yet, we need more time. Alright, so, did you find out some new things that you weren't expecting as I tear this pen apart? Uh oh, equipment malfunction. So, what are some of the ideas that you came up with? What are some things that product owners do? Go ahead and shout them out and while we're getting the pen replaced. Yes, define the product roadmap. What need? Okay, indicate what needs to be done for the product. Sorry? Provide clarity on requirements. Prioritize! Okay, we have roadmap, we got prioritize, we have backlog, grooming, refinement. Lead user. Okay. Responsibility. What is the right product? Build the right product. Did I hear business vision back there? Okay. Sorry? Define what? Define what and why. Feedback from user. Okay. One more. Sorry? Translate! Value. Okay. The definition of one more must be different here than it is back in Iowa in the States. Okay, thank you very much. Great list. So, I did a little bit of anticipation about what my people might come up with. And this list is fairly consistent with what I usually hear. I like to condense it down into three general things. Because I'm a simple guy and I can't remember too much. So, the first one is that they're really focused on making sure, focused on that the entire team is looking at outcome over output. How many of you were here on Tuesday? How many of you came to my session? Well, thank you for coming back. We talked about this on Tuesday as well as far as looking at effectiveness versus efficiency. And a lot of times what you have when you have a focus on efficiency is you're worried about how much of this we can pump out. Right? Measuring things based on story points, looking at velocity, things of that nature. Output are the products we produce, the code we write, the deliverables we create. Good. But what we really want to be making sure we're focusing on is what change are we trying to create in our world? What problem are we trying to solve? And it really comes to that product owner to be constantly reminding the team of what that outcome is. So that as the team is making decisions, they keep that in mind. They're not always focused on what's the next thing we got to pump out the door. But we're really worried about what is their ultimate problem we're trying to solve. And it goes into even figuring out how are we going to measure success, not measure it based on this, story points, velocity, things of that nature. But how are we doing towards our objectives? So outcome versus outputs, the first thing. The next thing, building and maintaining a shared understanding. And what the shared understanding is of is what outcome are we trying to produce. And this is where I really like to think about, so I've spent a lot of time in the business analysis world and there's a lot of talk there of requirements. And I really try to bring that discussion up a level to say, this is what we're really trying to accomplish. We want to make sure that everyone has an agreement as far as what is it we're trying to do. So once we've identified that problem we're trying to solve, let's make sure that everybody that's working on something has that same understanding. And I mentioned, notice I said build and maintain. It's one thing to get the agreement to begin with. It's another thing to make sure six months down the line when a bunch of stuff has happened that we're all still lined up in the same direction. Make sense? All right. The third one is make sure decisions happen. And I worded it this way very specifically. Ideally the person who is doing product ownership is in a position where they can make decisions. In real life that's not always the case. So in those situations what you really at least need to be doing is making sure that we've identified who are the appropriate decision makers. Make sure they have the appropriate information to make informed and timely decisions and then actually do that. And then stick with it. So again as I mentioned I spent a lot of time in the business analysis community and as business analysts are starting to be brought into agile settings. Oftentimes they're being asked to play product owner roles. But they aren't necessarily situated as such in the organization where they can be the ones making the decisions. Right wrong or indifferent they still are in a position where they at least have to make sure that they're getting those decisions made. And oftentimes as we'll talk about here in the models coming up what they're really doing is they're coordinating decision making a bunch of different stakeholders. Especially in IT organizations working on internal products which is where I spend most of my time. So again the three things that product owners are really focused on is outcome over output, building a shared understanding and making sure decisions are made. And generally speaking all of the things that you've listed up there fall into one of those three buckets. Sometimes they fall into more than one. The reason I like to kind of group these things together is it brings it up from just a standpoint of that these are specific tasks that product owners are doing. So these are the things that you always need to keep at top of mind. Any questions so far? Yes. How do you define what? So the question was how do you define the Scrum Master role in decision making? And I would suggest that they're making sure that the product owner is making sure that decisions are getting made. Huh? They're the enablers. They're the enablers. Thank you. Yes they're the enablers to make sure that decision making happens. The other thing where Scrum Masters are really important is to make sure that the product owner and the team are working together such that when a decision does get made it actually gets carried out appropriately. Does that answer your question? Yes. Who is accountable for the delivery? D.D.D. I love crowd sourced answers. Alright. Including the product owner. Including the product owner. So it is, I will be honest with you, this is the bad thing about having a phone as your clicker. When I look at, when I describe a team, I'm including the Scrum Master and the product owner in that. So it is the team that owns those things. Because if you start having, splitting that responsibility up, then that starts causing dysfunctions that don't help anybody out. Any other questions? Yes. How much is the dependency on the product owner and the product manager? So the question was, is how much of a dependency does the product owner have on the product manager for decisions? And I'm going to ask if I can defer that question, because most of the rest of the presentation is going to tackle that. I will say right now, though, my main answer is, it depends. Okay. Well, that's always a good fallback answer. Yes. How do we prioritize backlogs? Value. I heard value up here. Any other thoughts? Outcome risk. All of those things are kind of baked in together to do that. And that is also another, it depends question. Is there more of a follow up on that as far as why you ask that particular question? So the general point is that it goes back a lot to this. Okay. So, and I'm going to speak from my own experience as far as working with the Agile Alliance website and submission system. When I'm looking at what things I want to get done, one of the main things I consider is which of the items on the backlog are going to get us the biggest lift towards that outcome fastest. If we're early on, the deciding factor might be what's going to help us learn the most, the fastest. Sorry, my grammar is not too good this morning. Another thing is, do we have some very high risks that we need to work through? So we might do those things first. So those are all factors that can work into prioritization. And which ones you use really depends on where you're at along the whole line. Does that help? Can you say the risk, the high risk you would have to advertise? So the question was, why on earth did you say risk? And would you do high risk? And so there are some cases where I would actually want to tackle high risk items first. Or if there are assumptions we have out there that are extremely key to our solution working that we're not sure about, I'm going to want to tackle those things first because I'd hate to do a bunch of work and then find out a lot later that one of the assumptions we made was incorrect and then all of this other work was for naught. So that's why that thought process goes into that. Okay, last question I'm going to keep going. Should product owner be part of the development team or the business team? I'm going to defer that question too because the models are going to talk about that as well. Okay? All right, great questions. And I can tell that people are wanting to get into this next one. So where do product owners fit? And by this I'm really meaning where in the organization do they exist? And the truth is there isn't one single answer. There's actually several. I've come up, well, I know of at least four that I'm going to share with you and we're going to walk through each one. So here's a model. And again as I mentioned the slides are available online. They're also in the app as well. This model was originally put forth by Todd Little. He's sitting in the back of the room. He's actually paying attention right now. I was going to call him out when he was otherwise occupied. But Todd put this model together at least mostly in order to have some discussions inside a company that he used to work at because they were having some of the same discussions as the questions that came up here. Should we have the product owner in IT? Should we have the product owner in business? And what he put this together for is to say there's a lot of different ways to do it. And it depends on the situation in which you're working. So I thought it would be helpful to kind of walk through what these models look like so you can get a feel and then also think about, okay, what model are we using right now and is that the right one for our situation? Sound good? All right. Let's look at the first one. So this is where kind of going to the almost but not quite going to the product manager question we had. This is where you've got a product manager and a product owner is the same person. There are some in, especially in the product management community that say this is the ideal and the best way to go. Notice I said that they were in the product management community, right? And there are definitely benefits to that. And so for each of these models, I'm going to talk about some pros and cons and also kind of who does what when things are split up. And so I kind of took the three ideas that I just had and put a little bit more granularity to them. Before I do that though, I just want to point out that this diagram does have customers in it. So this right here is basically the business side of things. I have product managers listed here, which is usually what you see in a product development type situation. So if you're selling products outside, software products, if you are an internal IT situation, such as the financial services, insurance, things of that nature, that product manager, there may be someone that's actually a product manager, but they also might be kind of the leader in the business area that you're doing the work for. So just make that conversion in your head. And then PO is product owner, BAs are business analysts, and then you have a delivery team. So that's kind of a key to what this chart is saying. So let's look at this first model where the product manager is the product owner. And so they're effectively doing all of these things. They're looking outward to the market. They're understanding their customer's needs. They're talking with customers. They're getting feedback. At the same time, they're expected to do the main things that product owners are expected to do, primarily interact heavily with the team. The upside of this model is that there are, there is, hopefully there are no communication issues between the product manager and the product owner. If you have communication between the product, problems between the product manager and the product owner in this setting, something might be wrong. So there, there, there's much less chance of communication issues. The other thing is, is that the team is likely to have a much closer connection with their end users and customers because the person that's interacting with them is also the same one that's interacting with the customers. Now don't take that to mean that the team themselves shouldn't be interacting with users as well, but you may not always see that. And ultimately you have less confusion because you have fewer rungs in the game of telephone. But there are some downsides. And the biggest downside is, how big is your product? How many teams are you working with? Does that product manager have a day job aside from being a product manager? And that's especially the case in internal IT settings. How many people in here work, like in a financial services company, what you consider internal IT or internal product scenario? Raise your hands. Are the rest of you in a product development where you're selling software products? Okay. So this one's especially a big concern. The day job issue is when someone is in a business unit, and that's not the only thing they do is being product manager. The other thing is, is it can be difficult to give the team the attention they deserve and expect, and at the same time do an adequate job of talking out to the market. You end up getting a split personality because do I talk outward? Do I talk inward? Do I do both? When do I do which? So where this setting usually exists is when the product tends to be smaller. You see this model a lot in startups. You see it in nonprofits, and this is the setting I'm in right now where I'm not only am I working directly with the teams that are working on the website and the submission system, I'm also the help desk for both, which is a great way of getting customer feedback, especially when you come to conferences and you run into people that know you do that. Hey, I've got a question about the website, or hey, the website's not doing this, or hey, where's that certification statement or things like that. So this is a generally setting where you see it. As the product gets bigger, or the number of customers you have get larger, this model starts to become a little bit unwieldy. How many of you would say that you're currently in this model right here? Not too much. If you remember the survey from this morning, the question that was is the product owner from the business have product and loss responsibility, and then the overall audience 34% said that they were in that model, that would be this model here, where the person that has profit and loss is also acting as the product owner. Now what that question may not have gotten to is that in those situations there may have been some proxies involved, which we'll talk about that model here in a minute, because we only had a handful of hands come up on that one. Let's look at the next model. This is where you have a product manager separate from a product owner, both existing in the business working with the delivery team. So your question is where do product owners fit? This would be an example where they're sitting over on the business side of the house. So here's where things show up with that. The biggest benefit of this model, generally speaking, is that the product manager is usually freed up to focus more externally. Look at the market, talk to customers, talk to users. They can really focus on those things. The product owner is generally focusing internally on the delivery team. So they're giving the delivery team the love, care, and feeding that they need and deserve. That's the benefit. The downside to that is now we start introducing the chance for communication issues. We start introducing the chance for lack of clarity. We start getting potentially into the idea of stepping each other, stepping on each other's toes. Does that phrase ring true? Yes. Because there needs to be clarity as far as what types of decisions do each one of us make. You also see a split up in responsibilities. So generally speaking, the product manager is sitting there trying to set the roadmap and they're prioritizing globally. And by that what I mean is they're looking more along the lines of the big chunks, whether you call them features, whether you call them epics, whether you call them big chunks. They're more guiding those things. What's the thing we're going to be working on next in a large sense? The product owner is doing much more local prioritization. So more focused on a specific team. The other thing that the product owners generally are doing are creating... So they're filling up the backlog. And granted that doesn't mean that they're the only ones doing this. And they're also providing clarity for those stories. Now I've way over generalized some of these tasks here because I really believe that developing a backlog and getting clarity on it is still a team effort. But the product owner is kind of leading the charge on that. Does that make sense? So this is kind of how this is split up. The thing with another con with is that you now have the product owner effectively has, in a sense, two masters. Not only are they serving the product manager, providing information back to them, but they're also serving the team. So they might still get a little bit of a... I'm not sure who I'm working for today. And at the end of the day though, the product manager generally is still responsible for product ownership overall. Because they usually have some sort of profit and loss for the overall product. But they are still working with a product owner. So example of this is I worked with a product organization where there is an engineering side and then there is a product management organization that has both product managers and product owners. And they pretty much follow this particular approach. The interesting thing then becomes is how do you organize and how do you align product managers to the teams and how do you align product owners to the teams? This becomes an even bigger challenge the more teams you have working on it. So the particular example I'm thinking of has about 50 delivery teams. Spread across four different geographic locations. So it's a pretty small team. About 500 people. Yeah. And so the question then becomes is how many teams are the product owners that are aligned with? That's one thing, but then how do we maintain relationships between product owners and product managers? What this particular organization does right now is the product owner tends to go along with the team. But a team may be doing work that one product manager has in one quarter and then may shift over to a different area of work in a different quarter. So you might have product owners working with different product managers potentially even at the same time depending on how many teams they're working with and who those teams are working with. So as you get larger and scale out to multiple product managers, multiple product owners, you then have to start thinking about what's the best way to have that alignment going on so that we don't have a bunch of chickens running around like their heads are cut off. Okay. How many people would say that they're in this model? So a few more. Okay. This would be corresponding potentially to from the keynote the dedicated pool of product owners. Okay. And 39.4% I believe in the keynote said they were in this situation which it actually was the largest by a hair. I mean it pretty much was a third, third, a third. In internal IT scenarios this is often example I've seen as well but I also see the next one or the fourth one I'm going to talk about. And this is a case where business unit needs to have some work done. That individual doesn't have enough time to spend a lot of time with the team so they identify someone on their staff to work with the team who generally speaking tends to be a subject matter expert. May or may not have a lot of experience working on software efforts so they may or may not have the analysis skills would be really helpful for a product owner to have. And so sometimes you'll see IT areas supplement that with business analysts which we'll talk about here in a few minutes. Okay. It does to some extent yes but then the example I was talking about with this model it introduces all new scaling issues. But it resolves some of the things whereas the product managers may not be as overloaded but it induces communication challenges that you then have to start working through. Which at the end of the day you're going to find out that there is no one right model for every situation and every model kind of comes with its own challenges. Sorry? Toe stepping. Toe stepping? So I think the best way to explain it is imagine two people dancing very close together they're not very good dancers. One person steps on the other person's toe. So that's where the phrase comes from. But what it means is two people trying to do the same thing. Yeah. So then the question was so what happens? Well first people's toes start to hurt. And second what it really ends up being is that there's conflict as far as who really needs who owns those decisions. Okay. So the best way to resolve that is to have clarity when you first get started working together as far as what types of decisions are each of us going to do and have regular touch bases to say is this working or do we need to adjust? Yeah. If I'm ever using any weird Iowa phrases that you need because I don't speak English I speak American. So Midwest American at that. Third model. This is where you have a product manager on the business side. You have a business analyst on the IT side. Effectively what this is is the business analyst is acting as the product owner. Okay. It's very similar to the last model. In fact one of the sets of resources that is on my website that I have listed is an article about blog posts about each of these different models. And then when I was sending out newsletters about them I grouped two and three together because they are very similar. The split of responsibilities about the same. There are a couple unique differences. The business analyst may or may not have subject matter expertise. Generally speaking they are going to have business analysis skills but they may or may not be familiar with the business. I've been in the situation on both cases. So I did a lot of contract work where I was going from one company to the next each time in a new industry, each time in a new company and had the great joy of learning completely new domain really quick. By the time I was done I had pretty good expertise but I sure didn't when I started out. So sometimes the business analyst in this scenario may or may not be able to be providing that subject matter expertise and you still have to work with other folks from the business to get that. The other thing that can run into here is this last issue where I have business slacks and what that means is in some cases you can see if the people on the business side say, oh well IT's got someone that's kind of doing all that nitty gritty prioritization stuff, I don't have to be as engaged. The bad thing is that we're still looking for the business person in this case to be making a lot of decisions at the broader scale so that doesn't quite work so well. So that again otherwise there's a lot of the same pros that the previous model had is fact that the product manager is able to be more outward facing the business analyst or product owner is able to be more inward facing. Chances are that the BA doesn't have as much decision making authority responsibility as say a product over on the business side might so you got to work through those things as well. So the comment here was that most IT organizations tend to work in this fashion and that the BA's oftentimes are folks hired over from the business. Sometimes at least in the States it's because it's a way to get them more money. That wasn't a joke actually. Yes that's true and also a lot of the cases where I was involved this is the situation I was in as well but we still end up having subject matter experts coming from the business. Excuse me? How do you differentiate between the PO and the business analyst? The product owner is a role business analyst often is a title. The other thing is is that product owner or business analyst up until recently has been something you see kind of out there in job markets and things like that although product owner is now starting to be something you see advertised. Product business analysts tend to be fitting into that role on an ongoing basis. Product owners might only be in there given what depending on what we're working on. The big difference I see is so the comment over here was the BA's tend to be more on the technical side. Interestingly enough there's a lot of situations in the states at least where there's BA's on the business side as well. What I was going to say is that product owners generally have more decision making accountability than business analysts do in most organizations. I'm not saying that's across the board but that's the big differentiation I've seen. Say that again? You could but I would also respond with it so that the comment was you could say that a PO could be most of a BA and a BA could be a little bit less of a product owner. And I would say my answer would be, anyone guess it? It depends, thank you. So what I do like to see though is that product owners do have business analysis skill sets. Okay? It's kind of misleading to me because here you are saying that it's a better owner slash PO. Yeah that's a typo. That's what happens when you do slides today before the presentation. Thank you. That should just be product manager. Yes? So the question was if a business analyst has supposed to have more knowledge in the business why do I have business slacks down there? It's because in this model the BA is sitting on the IT part of the organization and often times what happens is business says if there's someone that's representing kind of focusing on that outcome there are some cases where the business where the product manager in this scenario would be sitting there thinking you know this isn't my full-time job so someone over there has it covered so I'm going to go work on other stuff and so they may not be as engaged as they should be because they think someone has it covered. Especially in scenarios where the person on the business side isn't used to working in projects or on products. So the question was how is there a disconnect with the business and it often just happens because they're sitting in different parts of the different organizations. Okay? So for me there might not be disconnection. There will be always disconnection between them. I cannot see the business analyst product owner at all. Okay. So the comment here was he couldn't see a BA being a product owner and keep in mind that this is a model. And what did they say about models? All models are wrong but some can be useful, right? So as a matter of fact, so actually real quick how many people would say that they're actually working in this model? So there's a few. It actually is fairly prevalent in the states and so those organizations a lot of it depends on who's in those positions. It may be different scenario but your point is very well taken. I've got about three minutes left. So if it's okay with everyone we're going to finish this out and then I will be around for the rest of the day. I don't have a flight to catch until 3.30 tomorrow morning. Happy to answer any questions you have. Sound good? All right. So the fourth model I would say is a little bit of a anti-pattern and that's where not only do we have a product manager, not only do we have a product owner, we also have a BA or more. Okay? And so this is where this happens. Generally speaking you see this spring up where the product owner, product manager combination doesn't have the requisite business analysis skills that you'd really like to have. So you feel the need to supplement it on the delivery team side. Okay? This actually, this model I've seen a lot in the internal IT situations that I've run into because we're putting someone in that product owner role that really is a subject matter expert but may or may not have an idea, have a lot of experience even doing this kind of stuff. Or describing effectively the things that we want to do, we want the team to do. Okay? So again, the pros here again are in addition to the idea that you still allow the product manager to be outward facing, the product owner and the business analyst can be inward facing, you're also supplementing the product manager and product owner's analysis skillsets and the team is getting probably a lot more support than they would have otherwise. But that comes with some downsides. It comes with the fact that you have bigger chances for communication issues because you can have even a longer game of telephone where messages are going through three people. Now, the best way to resolve that is to get all the, what I refer to is get all the liars in the same room. So you have everyone talking to each other at the same time. You also face the potential of having a wrong decider. So another stepping on toes situation where the wrong person might be making decisions. You also run a bigger chance of decisions getting overturned. So the B.A. makes a decision in the heat of the moment. Then we find out, oops, that doesn't align with what we were thinking. Makes sense? The other key thing here is this is generally how the kind of the tasks break out. Again, not always the case, but this is what I've seen happen a lot is that the product owner and the B.A.'s work very closely together but the B.A.'s are the ones ending up writing and clarifying the stories. So do we need product owners? What do you think? I've heard yes and it depends. You guys learn quick. That's awesome. I put this question in here because I like to use it to do this point. So depending on your situation, so for example that first model technically doesn't have a specifically identified product owner and in certain circumstances that works great. But regardless of what you're doing, I would suggest that you still need product ownership. And in a lot of cases it's more than just one person. As long as you figure out, okay, who's making this particular decision? That's the key thing. It's also why I suggested that one thing that they do is make sure decisions get made. So you'll often hear me not so much talk about product owners specifically but much more about product ownership and in our given situation who's doing that. So a thing I always like to do to tackle that is let's have that discussion up front who's responsible for these things. So to sum things up, if you remember nothing else from today, aside from the toe stepping, you need to focus on outcome over output. What problem are we trying to solve? You want to find ways to build and maintain that shared understanding between everybody involved with the product. You really want to drive home to making sure decisions are getting made. And it's not so much who's the product owner as much as are we doing product ownership. Real quick, I like to recognize the place where I get the photos from. There's a site called Unsplash. So all of the photos are free rights so you can use those. There's my contact information. Again, all of the slides and additional materials are down there on that web page at the bottom. I also recently wrote a book that has a lot of techniques that product owner analysis techniques that product owners can use. So if you have product owners you're working with, don't have much analysis skills. You can give them this and they'll be experts. They'll have a good book I guess. I want to thank you for all the great interaction. You had great questions. Like I said, I'll be happy to hang around and answer any others you have. Thank you very much. Enjoy the rest of your day.