Podcast Ep. 43: The Importance of the Product Owner Role in Scrum with Sam Falco

Share on facebook
Share on twitter
Share on linkedin
Share on email

Episode Description:

In today’s episode of the Agile Coaches’ Corner podcast, host Dan Neumann is joined by AgileThought colleague, Sam Falco, to take a look at the Product Owner role in Scrum. The Product Owner role gets overlooked in a lot of discussions around Scrumyet, they’re one of the most important, complex and crucial roles. They’re the visionary behind the product. Primarily, their responsibility to the Scrum team is to maximize the value of what the development team creates.

Tune in to hear Dan and Sam’s conversation and get more insight into the incredibly important Product Owner rolewhat it is, the challenges of being one, the valuable traits and skills for a Product Owner to have, and some of the anti-patterns around the role.

Listen on Google Play Music


Key Takeaways:

  • What is the Product Owner role in Scrum?
    • It is one of the three roles of Scrum (Product Owner, Scrum Master and the development team)
    • They’re the visionary behind the product
    • They’re a crucial reason to why we have Scrum teams in the first placethey’re feeding the Scrum team the most valuable backlog items to turn into an increment of product every sprint
    • The primary role of the Product Owner is to maximize the value of what the development team creates
    • It’s important that it’s only one person; not a committee
  • Challenges of the Product Owner Role:
    • Managing and representing the opinions and voices of the development team and stakeholders by distilling them into a coherent product backlog that’s optimized for value
  • Valuable traits for a Product Owner:
    • Someone with a distinct understanding of the market and a vision for a product that they want to bring into the world
    • An entrepreneurial mindset
    • Someone with very deep domain knowledge and business knowledge
    • Understands the customers (or potential customers)
    • Decisiveness
    • Open-mindedness
    • Strong leadership skills and the ability to motivate others
  • Important skills for a Product Owner to have:
    • Domain and business knowledge
    • The ability to write a good business proposal as well as a strong canvas that articulates to funders what it is you’re trying to accomplish
    • A willingness to test your hypothesis and do market research
    • Communication skills and articulating things in a way that makes sense to your development team
    • Negotiation skills
    • Having a well-crafted and well-ordered backlog
    • Being able to define the sprint goal
    • Being able to communicate the vision and having the organizational skills to put the backlog in a good order so the development team, customers and stakeholders always know what’s next
    • Technical skills (though it is not a must-have, it is helpful for them to have an understanding of the technology they’re working with)but be careful, a Product Owner with technical chops can sometimes interfere with the development team
  • Anti-patterns within organizations that are not setting up their Product Owner for success:
    • Having someone without the right traits and skills in the Product Owner role
    • Having a proxy Product Owner stand-in for the real Product Owner which jumbles the message and leads to “answer shopping”
    • Having the role split into two people (where one becomes the ‘business’ Product Owner and the other person becomes the ‘technical’ Product Owner) which affects team self-organization and leads to uncertainty
  • Product Owner anti-patterns:
    • Rigidity
    • Disregarding estimates
    • Product Owner is an ‘order-taker’; simply taking notes and doing everything that is said (which causes issues because they cannot articulate a clear vision)
    • When a Product Owner is not valuing everyone’s opinions equally (and instead, giving more value to those who are loudest or had the last say)
    • Presenting a release plan to stakeholders that is wildly at odds with what the development team can accomplish and expecting the development team to live up to that
    • Unbalanced focus and either being too involved with the development team or not enough
    • Spending too much time with the stakeholders
    • Only showing up for Sprint Reviews



Mentioned in this Episode


Sam Falco’s Book Pick:



Intro: [00:02] Welcome to Agile Coaches’ Corner by AgileThought, the podcast for practitioners and leaders seeking advice to refine the way they work and pave the path to better outcomes. Now here’s your host, coach and agile expert, Dan Neumann.

Dan Neumann: [00:16]  Welcome to the Agile Coaches’ Corner. I’m Dan Neumann and thank you for joining today as we’re going to be focusing on the product owner role in Scrum. And my co collaborator on this is Sam Falco, who we’ve done some episodes with in the past on Scrum values. And thanks for joining.

Sam Falco: [00:35] Thanks Dan.

Dan Neumann: [00:36]  We’ll maybe make a histogram of who’s been in and turn it into, we turn it into a competition of sorts, so it’d be interesting. And of course these are my opinion and your opinion and not necessarily those of AgileThought or other folks or other companies.

Sam Falco: [00:54] Correct.

Dan Neumann: [00:54]  All right, so focusing on the product owner role, Sam, let’s start with what, what you see as the product owner role and some facets of it.

Sam Falco: [01:06] Sure. Well, the simplest statement is that the product owner is one of the three roles of Scrum. And I wanted to talk about that today because it often gets shorted. A Scrum master gets a lot of attention, right? That’s Scott Scrum right in the title. So we have to have that. Uh, but the product owner just sort of gets overlooked in a lot of discussions that I wanted to dig in a little on what that, what that means. And the product owner is the visionary behind the product. I mean, you don’t need a development team if you don’t have a product to develop and you don’t need a Scrum Master if you don’t have a development team. So really product owner is kind of crucial to the reason why we have Scrum teams in the first place.

Dan Neumann: [01:48]  Yeah, they’re feeding the Scrum team the most valuable backlog items to turn into an increment of product, every sprint. So it’s pretty crucial. Garbage in, garbage out.

Sam Falco: [02:01] Well, hopefully not, hopefully value in value out. And that’s key is that the product owner primary responsibility, uh, to the Scrum team is to maximize the value of what the development team creates. Not just make me some things, but these are the most valuable things to do right now or so I assume, we’ll know that once we release and test it on the marketplace, but usually based on some data and some research here is here’s what it’s going to be most valuable for us to focus on right now.

Dan Neumann: [02:32]  And I liked that you mentioned it’s an assumption until we turn it into increment and get some feedback and that’s where one of the earlier topics we explored about Scrum or the empiricism of Scrum can come in. So yeah, it’s a guess until we get actual data. Okay. So we’ve got somebody responsible for maximizing the value that the development team’s going to be delivering within the Scrum Framework.

Sam Falco: [02:58] Right. And it’s important. It’s somebody, it’s one person. So we occasionally see committees of they’re the product owners or we don’t even call them that. They’re just the people who are calling the shots and the product owner has to be just one person, not a committee. Uh, not two people. The product owner can represent, uh, committees, desires, uh, or um, some organizations call them demands but you know, the product owner can represent them, but the product owner still has to be the person responsible and accountable and has to have the authority to make decisions and make trade offs.

Dan Neumann: [03:37]  And I think that’s one of the big challenges of the product owner roles. They have all those other voices, all the stake holders with their own particular interests and the product owner has to take those and distill them into a coherent product backlog that’s optimized for value.

Sam Falco: [03:58] Right. Ordered in a certain way. Uh, instead of just whoever screamed loudest or most recently gets their stuff or whoever has the higher title gets their stuff. If you start getting into that situation where you’ve got the wrong person in the product owner role, it may need to be somebody else. One organization I was at had that problem where the product owner was continually overruled by an executive and essentially that executive was the product owner cause that executive was making all the calls.

Dan Neumann: [04:31]  And in a scenario like that, I guess maybe to put on the coaching hat a little bit, yes. That the wrong person is wearing the title of product owner and how do we get that executive either to fill the role or to let go of some of the the reins that maybe they haven’t yet. So it does that. The person who’s filling the product owner role have the knowledge, authority and time to do it and trying to figure out how do we fill that role effectively.

Sam Falco: [05:00] Yeah. And that that’s where a strong Scrum Master comes in. Who can coach both the person who is nominally the product owner and the person who is overruling or the people who are overruling. Do you want to see this Scrum team succeed or not? Somebody has to be doing this role in this way and right now we have a problem. How are we going to overcome that? What do you wanna do? Do you want to let go of some of your power or do you want to take over the rest of it and do the job, do the role, do all the things that it involves and possibly set some of your other responsibilities aside. What do you want? How do you want to do this? And I like to focus on specifically what outcome are you looking for. And of course we’re looking for is good working product increments that comes from some coherence. So we need a strong product owner. What’s it going to be?

Dan Neumann: [05:55]  Having touched on some of the responsibilities of the product owner, when an organization is looking for a person to fill that product owner role, why don’t you share some of the traits that you see being super valuable for a product owner?

Sam Falco: [06:10] Sure. As I said originally, this is a visionary. This is someone who has a distinct understanding of the market and a vision for a product that they want to be, uh, to bring into the world. So there is a bit of entrepreneurship there and often we have an entrepreneur in this role, someone who has gathered a small team and they’re going to build something. But even in an organization where the product owner is just one part of a, of a larger, uh, operation. So for lack of a better word, you want that entrepreneurial mindset that, you know, I, I have some money to spend and I have some money to spend on bringing something into the world and this is what it’s going to be. So whether we’re talking actual entrepreneur or part of a larger organization, we want someone with a very deep domain knowledge, uh, and business knowledge as well. This is someone who understands the marketplace in which the product is going to be used, understands the customers or potential customers, and there’s a wealth of information out there on developing the a, those abilities, those skills, I’m, dumping into skills here. I do want to get back to traits though. We’ll talk about skills in a little bit. So the difference between traits and skills. The reason I make that distinction, traits are more or less not something you easily learn they’re outlook, they are mindsets that is, not exactly ingrained, but certainly a deep part of somebody. So we’ve talked about deep domain knowledge. That’s a skill. It’s also a trait, we want someone who is decisive. The absolute worst thing that a development team can have is a product owner who is wishy washy and makes a decision today and then reverses it tomorrow. We want someone who says, no, this is the direction we’re going and we’re going to build this thing for one sprint and then we’re going to get our feedback from the marketplace or from stakeholders or what have you. So that we have a constant direction, a steady direction, sort of like, you know, if you’re on a ship, you don’t want a captain who says we’re going to go to Majorca. Nah, maybe we’re not go to Majorca. Where are we steering captain?

Dan Neumann: [08:32]  Yeah. And that, that vision and the ability to hold it fairly constant and evolve maybe the solution based on the empiricism is really important. But we have a vision. This is where we’re going. We’re not going to get distracted by little shiny objects laying around and we’re going to be able to make clear decisions. This is where the value is. This is the investment we’re able to make in trying to achieve that value. And how do we get there?

Sam Falco: [08:59] Yeah. And that’s shiny objects tendency can really kill a team’s momentum. If a product owner is constantly going beyond what is the marketplace’s state? But what’s the thing I want to do? That’s really, you know, everybody’s doing this really cool thing so we’re going to do this really cool thing and trying to anticipate the market without really having the deep knowledge. You want somebody who can avoid that, that tendency. That said, you also want someone who’s open minded and is willing to look for new things or change their opinion based on new data. So it’s not just rigid minded, decisive, not what I mean. Rigid minded is not what I mean by decisive but certainly resilient and, and able to change their mind based on data.

Dan Neumann: [09:46]  Yeah. And you know, changed their mind. And be open to different hows as they are working with the Scrum team, the development team, the Scrum Master to come up with a ways to deliver this value. You know, I want those developers coming up with ideas, hey, what about this? Here’s a faster way to do it. Here are some pitfalls of the the faster way. Here’s the, the more robust way to do it. Maybe the pitfall there is time invested and really being able to take in all that input as they’re collaborating with the development team on how to do it. So that’s where I see that open-mindedness coming in.

Sam Falco: [10:23] That’s, yeah, that’s a very good point because some product owners will start trying to tell the development team how they want this thing developed rather than saying, here’s the outcome I’m looking for. I want my users to be able to accomplish this objective, make, make that possible. Help me make that possible. Uh, and exploring options and some product owners will dive into starting to tell them exactly how that’s going to happen and that’s not necessarily healthy.

Dan Neumann: [10:49]  The other piece. Then maybe the last one related to traits. And I liked the attention. Traits are so much harder to change I think than skills. We can build skills, but if you aren’t used to moving with some degree of uncertainty, if you aren’t used to iterating, if you aren’t used to collaborating, it can feel really painful and hard to do that. So I like the distinction between those traits of finding somebody where you’ve got an easier path forward. Um, and one of those traits, then a leadership and motivation are a couple of additional traits.

Sam Falco: [11:23] Yeah. You want someone, not just who’s a visionary because you can have a visionary who nobody wants to follow or is unable to articulate that vision in such a way that people want to follow. So you want someone who’s a leader and you want someone who can get people excited about this goal.

Dan Neumann: [11:42]  Yeah. And I think then that’s where the vision comes in too. So yeah, you’re right. We have a vision and if you can’t articulate that in a way that other people can understand or when you articulate it, they understand it or they aren’t excited about it, that’s not doing anybody any good. So how do we, how do we take the leadership skills? How do we find somebody who can motivate and help grow them into a product owner?

Sam Falco: [12:05] Yeah, and I mean those, those traits, we can see them. I mean, I don’t know that we could come up with a checklist right here and now on what those look like. But yeah, I think we can come up with some examples though from what we’ve seen in the business world right now for, for good or ill, uh, Steve Jobs was a visionary and a leader and a motivator. Now he apparently had some, some nasty side to him sometimes as well. But here’s someone who didn’t just have a vision for the way Apple should change and, and present itself to the market, was able to get people to go along with that. So there’s plenty of examples out there for that. Uh, Elon Musk is often cited as well because he has, some people would say grandiose visions of not just his company but where the human race should go. But he has a lot of people who will follow him.

Dan Neumann: [13:07]  It’s interesting to see some of those extreme examples of people who have been successful in that, in as leaders and as innovators. Um, yeah. Sometimes they come with a lot of baggage, right?

Sam Falco: [13:19] That’s unfortunately some of those traits we reward and we overlook some negative side effects. So, um, I know there’s been other podcasts about psychological safety and that sort of thing, so we won’t get into that here, but do be aware that leadership is not synonymous with jerk.

Dan Neumann: [13:39]  Agreed. And so if we have a product owner with the traits, then as an organization it’s important to make sure that we’re setting that product owner up for success. And I know there’s some, some anti-patterns, there are some dysfunctions that are fairly common it seems like within companies. And it’s interesting to see how many times we encounter those.

Sam Falco: [14:00] Boy, howdy do we see those. And, um, some of those dysfunctions come from not having the right person with the right traits and skills in there. Um, so the product owner has just ordered taker comes to mind where the product owner is just goes to meetings and takes notes on what a host of stakeholders have to say and writes them all down. And here’s, here’s our backlog. We’re going to do everything those people said. This is, this is not really a product owner. This is, this is a scribe. And uh, that, that causes problems because then this person can’t articulate a coherent vision. It’s just whatever jumble of requests have come in. They can’t articulate a convincing why that will get people excited about doing this. I’ve, I’ve been in a situation where we had a product owner who that was the approach and the team just really didn’t care. Sure, they were going to come in and do their time basically as if it were a prison sentence. Um, but they were really excited about the product.

Dan Neumann: [15:09]  Yeah. And, and with the product owners order taker, the don’t say no and no is super powerful word. Yeah. Lots of situations, especially for the product owner or not yet. It doesn’t even have to be, no, it just has to be not yet. Like, Yup. I’ve heard you and there’s a bunch of other good ideas that are competing for spots in the product backlog and this is where the most value is for now. So I’ve heard you and maybe you’re not saying no, but you are saying not yet or not now.

Sam Falco: [15:39] Yeah, it’s really important. The next step up from that as sort of the, the proxy product owner who, um, has sort of some domain knowledge but not quite as much and they are standing in for another real product owner. And we see this in sometimes in a situation where we have the hierarchy of product owners, we have a chief product owner and product owners. That’s not to say that that structure is an anti-pattern. It can work very well. Um, for example, Scrum at scale. That’s the model that, uh, that uses. That’s that scaling framework uses. But in those cases, the chief product owner is usually responsible for an overall vision of a large product. And each product owner working in that hierarchy then has a vision for a portion of that. And they still have that ability to have an entrepreneurial mindset. And, and that strong vision, what I’m talking about is just the proxy product owner, meaning I, the product owner doesn’t have time to talk to the team. So I’m gonna stand in.

Dan Neumann: [16:53]  Yeah. And I see those people playing. Mother may I a lot or be an example between, between the, you know, right in between the, the, the real decider, the real product or the person who should be the product owner and the team. And so they just spend their day running back and forth or routing emails or routing questions back and forth.

Sam Falco: [17:12] Right. And that was, that ends up confusing. The development team, they don’t know who’s calling the shots. They can’t get a straight answer. It’s always, I’ll let you know later and you get a game of telephone going back and forth or it can lead to answer shopping.

Dan Neumann: [17:27]  Oh, say more about answer shopping. I have a mental picture of what that might be.

Sam Falco: [17:32] So you ask somebody a question and they don’t give you the answer you want. So you go to somebody else and ask them and until you get the answer you want, then you do that. Whatever that answer was. And when someone says, what on Earth were you thinking? Well, so and so told me to do that, um, you can get into that situation very easily with that weak product owner.

Dan Neumann: [17:52]  I am familiar with that pattern and now I have a better name before it.

Sam Falco: [17:57] Oh, that’s what my mom used to call it when my sister and I would ask her if we could do something and she would say no, we’d go ask dad and hope for a better answer.

Dan Neumann: [18:07]  Man uh, corporal punishment kept that from happening in my house.

Sam Falco: [18:09] Yeah the other name for that was cruising for a bruising but oh yeah.

Dan Neumann: [18:16]  And somebody called those the good old days apparently.

Sam Falco: [18:22] Anyway, another anti pattern that sometimes comes up when we don’t have a clear understanding of what the product owner is, is where we’ll split that role into two people, whether that’s two product owners who are working together, which I actually saw work fairly well in one organization where they had also the team was huge and they had two product owners. But those two were like a hive mind of some kind. I’ve never seen it work since, but what I’m thinking more of is uh, you have someone who is the, for lack of a better term, the business product owner and the technical product owner. And I see that play out as well. This person is going to decide what the business rules are, but this person is going to be the product owner for how the architecture works.

Dan Neumann: [19:05]  Yeah. And sometimes I wonder if that isn’t just a way to kind of continue with the old hierarchy, you know, a technical product owner, maybe it was called an architect before and it really can affect team self organization. So now we’ve got somebody. Yep.

Sam Falco: [19:23] What I see, and I saw this happen not too long ago where someone identify themselves as oh I’m the technical product owner because so-and-so just doesn’t know what’s possible or not. So this person then became a veto point. Nope, we’re not doing that because it’s not possible. And they didn’t get the team involved in those discussions and maybe it was possible and this technical product owner didn’t know or maybe some discussion would have come up with another alternative instead of just, nope, it’s not technically possible, we’re not doing it. And then that undermined the business product owner because that person was not actually able to articulate a vision for the product or what I wanted to do. It was, it became a I kind of want to, can we do this? Well guess what? You’re not, you’re not making the decisions anymore. If you’re asking can we do this from a perspective of am I allowed to?

Dan Neumann: [20:15]  Yeah. And if there is some uncertainty, I see a lot of value in deciding how we’re going to decide which can be powerful in lots of different realms. So is this going to be a situation where they need to come to consensus where the two of them agree? Is there something where one is informing the other and it’s really advise and decide? Um, you know, if it’s two people you can’t do majority rules, it’s either one’s in charge or we do everything by consensus and so it really gets muddy pretty quick.

Sam Falco: [20:48] Yeah. And I’m not saying that always a bad thing to do. I’m sure there are situations in which it could work, but most of the time when I’ve seen it, actually I can’t think of a time when I didn’t see that pattern be a problem.

Dan Neumann: [21:06]  Okay. So let’s imagine we do have, we found somebody with the traits, the organization set them up well, meaning they’re not an order taker, they’re not a proxy, they don’t have one hand tied behind their back because somebody else is the other facet of the product ownership role. Talk about some skills that that person can either have natively or need to acquire to fulfill the role effectively.

Sam Falco: [21:30] Right. So we’ve already talked about domain and business knowledge. But let’s touch on that again because someone can have a kind of an intuitive understanding of a particular business domain or market. Maybe, uh, maybe you’re developing a product that will help guitarists and you are yourself a guitarist. And so you have this deep immersion in the problems that come along with, you know, lugging your stuff around from, from Gig to Gig or, or whatever it is. But you still need to then develop some business skills that, that you might need to, you might not have an intimate knowledge of automatically. So there’s business knowledge, there’s the ability to write a good business proposal or can’t make a, a canvas that can articulate to funders what it is you’re trying to accomplish. So please give me some money so I can go build this product.

Dan Neumann: [22:35]  Yeah. And so we’ve got these people who, who maybe do have the domain knowledge of business knowledge. Um, a facet of that though that can be hamstring is we are our own favorite reference. I think I’ve seen the sticker. You are not, you not equal the user, right? So yeah, we can mistake ourselves as the user because we have a familiarity with that. So it’s kind of, uh, a willingness to test the hypothesis that you have or even view your opinion as maybe this is a hypothesis that others may or may not hold.

Sam Falco: [23:07] Right. There’s a piece of software that I use the windows version 3.0 is due soon. I can’t wait for it. Scrivener started out as a Mac product and it is for writers. The person who first envisioned this was a writer who could not find a tool that would do what he wanted it to, that would organize his thoughts the way he wanted to. So He created his own product and then began selling it. But he didn’t just build it for him. He built it for writers in general. So he talked to a lot of other writers about how do you work, how do you, uh, envision putting a structure together? And so this product is useful, not only for fiction writers, it’s also useful for nonfiction writers of many different stripes. I know bloggers who use it, I know some science writers who use it. I know a variety of domains, knowledge domains who can use this, even though the way they write is different. Uh, the way they structure things is different from the way another writer in another field may do it. It’s modular, it’s flexible. And this comes from not making the assumption that I am the only person who matters to making these decisions.

Dan Neumann: [24:24]  Yes, definitely need to go into the validation of that hypothesis and do market research and then communicating about what, what you have learned. Having communication as a native skill.

Sam Falco: [24:37] Yeah, you can know what you want, all, all that you want, but if you can’t articulate that in a way that makes sense to your development team, you’re not going to get it built or you’re gonna get something built, but it’s going to be really difficult to get what you’re looking for. So a product owner really needs to have very, very good communication skills, be able to talk to people in the business world. Again, we’re probably going to be looking for funding or we need to talk to a marketing department. Here’s, here’s the strategy for getting this out to the market, but we also need to talk to the people who are going to build it and that requires general communication skills and then it requires some very particular types of communication skills. I need to be able to, for example, if you’re using user stories, I need to know how to write a user story so that it makes sense to developers, not that we’re not going to have a conversation with them or many conversations with them, but give them that head start,

Dan Neumann: [25:38]  Yeah. So communicating about it and then organizing it in such a way that it is coherent in the product backlog that we’re delivering a set of capabilities that make sense together. We’re not just kind of randomly nibbling away at this product backlog based on what’s interesting or, or maybe who’s available or other criteria that aren’t helpful.

Sam Falco: [26:02] Yeah. It’s something we haven’t talked about very much yet today is just the fact that one of the product owners, big responsibilities and accountabilities is having a well crafted and well ordered backlog. Um, in the book the professional product owner by Don McGreal and uh, Ralph Jocham, they make the bold claim that everything you need for reporting on a product project is contained in a well organized and well articulated backlog. It’s all there. And so not only does the product owner need to be able to communicate what the vision is and what we need to build and they need to have the organizational skills to make the tradeoffs, put the backlog in a good order so that the development team always knows what’s coming next and that other people, stakeholders or customers or what have you also can take a look at what’s coming next, when are we likely to get a release, what’s likely to be in it, that sort of thing. So organization is a runner up to communication in importance.

Dan Neumann: [27:15]  And one of the things that I’ve seen now or recently be really helpful in organizing, not just the product backlog but the work that the Scrum team is focusing on each sprint is having that sprint goal defined because it’s really helped teams focus on this is what’s really the most important thing for this sprint. And then as there are other product backlog items that maybe we want to do, but if push comes to shove, the sprint goal is going to stay sacred and the team kind of knows it and it’s a really short articulation of what that is. So the organized backlog and the ability to communicate and deliver that around a sprint goal is super helpful too.

Sam Falco: [27:57] Right. Cause the sprint goal should not just be, here’s a laundry list of stuff I want do all of it. You know, the spring goal should be coherent around a particular thing. The Scrum guide says that a sprint can be considered as a project with a one month time horizon. So think of that when you’re, when you’re creating a project, you have a goal in mind. Sprint is no different, you should have a goal. And so product r needs to be able to look at the backlog and say, here is the goal for the next two years. You know, they’re spending money, it’s gonna cost $25,000 to run this team for the sprint. Just grabbing a number of random, what do I want to get from my $25,000? I want to buy this, I want to buy this capability. Can you do that for me? And have the conversation with the development team about what’s possible, how much of that is possible. So there’s some negotiation involved too, right? I mean, it’s not just communicate, I want this, you know, brush your hands off of walk off. It’s, I want this, is this possible? What can we do? And for the team to say, well, that’s a little bit much to chew off. Here’s the portion we can give you right now, or we need more information, et cetera. And it’s not just negotiation with the development team, of course, especially in a situation where you’re not the sole entrepreneur. If you are the product owner in an organization, you have to negotiate with your stakeholders. You have to negotiate with the Organization for funding. Perhaps you have to be able to show that value of what you’re doing and it involves some negotiation. I’ve heard of a product referred to as the stakeholder wrangler before because they have to get all their stakeholders together and help the stakeholders achieve alignment. So this, again, with negotiation, it goes with the communication organization and leadership, right? Because stakeholders all have their own desires. You have to help, may have to help them come together so that you’re not ticking someone off by putting somebody else’s thing first, but getting them to say, you know what? Larry, your thing is more important right now. Let’s go ahead and do that. Mine can wait until next quarter. If you can get a stakeholder to say that, you don’t have to worry about getting them. You know, they scream up to their boss who then comes screams to yours or you.

Dan Neumann: [30:16]  Well or or worse, they undermine each other as an organizational dysfunction where they are, they are not supportive of the decision and through various means are communicating that pretty clearly to the team.

Sam Falco: [30:30] Yeah. They undermine each other. They undermine you. They are shoulder tapping and causing all sorts of havoc. Yeah. You gotta be able to add that off. Yeah.

Dan Neumann: [30:39]  Yeah. So if your product owner does not have the skill of negotiation to build that consensus, like we might not like it, but at least we can support it. We, the stakeholders can at least support that decision cause it makes sense. And analysis is one of the other skills. So we’ve seen the analysis, we understand why you made that decision in yeah, I’m not super excited about it, but at least I know why and I can support that if I’m a stakeholder.

Sam Falco: [31:05] Absolutely. And then I sometimes like to see a product owner with a little bit of technical chops. It can cause problems. It’s certainly not high in the list of, it’s not in the must haves and it’s not that high in the list. But I think sometimes to have a product owner with enough understanding of the technology that they’re working with because then they’re, they’re gonna make requests of the team that aren’t feasible. No, not something like, Hey, can you make my briefcase lighter? This, you know, I want a device that, uh, makes my briefcase lighter and that’s an old Dilbert cartoon. But, um, it can be a hindrance because I’ve also seen technical knowledge get in the way of product thinking and product owner trying to get too deep into the weeds of here’s how you should build this thing.

Dan Neumann: [31:55]  Yeah. I’ve seen, I think I’ve seen both edges of the sword and where I’ve seen it really work is on either really technical projects or products, uh, where it really helps to have a technical product owner who understands the technology that underlies it or where they’ve made a similar product in the past at a different organization can bring in some of that expertise about here are some of the pitfalls we’ve encountered in the past around the technology.

Sam Falco: [32:23] Yeah. Look out for this little bite. You know. Um, I worked with a product owner who had been a developer, got promoted up into project management and then Scrum was adopted. Here you’re the product owner. And for a while that was actually hindrance because he knew the code. He had written some of it. Over time, not only did he grow into the product owner roll, but he got farther and farther from that, that stuff to the point where he wasn’t coding anymore at all, even for his own stuff. And so he really didn’t know the details anymore. He knew enough, he knew the underlying architecture. He had an idea of what our request might do to the existing product, but it wasn’t a, here go change this module, it’ll like link it with this. So it’s a, as you said, it’s a double edged sword. You gotta be really careful with that. So another problem then is a product owner with some technical chops can start interfering with the development team, not just in the expressing the, the backlog items with too many technical details, but starting to tell the Dev team what to do and directing them. And this is a dysfunction that is not limited to technical oriented product owners. A lot of product owners will make this or can make this mistake. And this is again, where a good Scrum Master can talk to the product about what are the helpful ways to communicate with your team and what are the not helpful ways. And by the way, we just did that wasn’t helpful because we want the Dev team to be self organizing so that they’ll come up with their own solutions that may be better than what you, uh, what you thought of on your own or, or thought you wanted. So that is a, we were talking earlier about some of the organizational dysfunctions in product ownership and these are some behavioral dysfunctions that come up frequently and one of them is that just interfering with the Dev team. And another example of that is, uh, Dev teams rolling on a sprint and the product owner says, you know, this item that you pulled into the sprint that’s really important to me and you haven’t started it yet. So I need you to get started on that. Well that may be not the best way to handle that, uh, that may need to wait. That thing you think is so important cause we’re finishing up the stuff that’s gonna make that easier for us and you end up distracting the Dev team or disrupting their work. Maybe the sprint just sort of blows up as a result, so you want to avoid that tendency to get into project manager mode and start telling people when they need to have things done or the order they need to do it in.

Dan Neumann: [34:56]  Yeah and you know, there’s that fallacy in that specific example of in order to get more done we need to start more when in reality, it’s like the opposite of you need to set something down, finish the thing you’re on and then move forward. Because the reality that when you’re setting this, when your context switching and setting something down, it’s not moving right. It’s actually slowing the whole system down. You’re not getting any more done. So yeah, that a ineffective project manager mode, not necessarily that the project managers has a bum rap on this. But yeah, kind of that task master, that task management mode.

Sam Falco: [35:29] Yeah and then the flip side of that is setting deadlines. Disregarding the team’s estimates, so not directly interfering by saying this is what you should be doing now, but this is how much effort this should take. I, again had a product owner who would do that with the team would be estimating and refinement and this product owner would be well that shouldn’t be a three, that should be a two. That’s, that’s easy. A, well you don’t know. Uh, so disregarding estimates or not saying that to the team, but then going to stakeholders and presenting a release plan that is wildly at odds with what the Dev team has told you it can accomplish and then expecting the Dev team to live up to that.

Sam Falco: [36:15] And related to that, there’s an organizational dysfunction where teams are handed scope and deadlines and kind of told that that is what they are to go deliver. Absolutely. This is on the roadmap so you will do it. And a product owner that goes back to you is the product owner or an order taker or is the product owner, the leader, the visionary, the entrepreneur who needs to go back to the organization and say, listen, you don’t get to make that call. You can tell me what you want and we’ll work on it together. We’ll collaborate, we’ll negotiate, but you don’t just order people around or else you’re not actually respecting the role of the product owner. You’re not respecting me.

Dan Neumann: [36:53]  And it defies common sense to, you know, if we talk about empiricism and having the people who are going to do the work estimate the work, it just defies common sense to hand them scope and timeline and then use all kinds of perverse means for trying to get them to hit that artificial deadline.

Sam Falco: [37:14] Yeah. I mean if I take my vehicle to the mechanic and it’s making a weird noise and I don’t know what’s going on and I say I want this back by one o’clock well if I have a good mechanic, they’re going to tell me, well we’ll call you in an hour or so and let you know what it is. Um, or they’re just going to say take your car someplace else. But if you had like, you know, a mechanic says all right, we’ll get it back to you by one o’clock. Well you may get it back by one o’clock but some pieces are missing.

Dan Neumann: [37:42] I like my mechanic, I go to, you know, the car is old enough. I don’t go to the dealership anymore. I go to a dude with some other dudes that work with them and it’s like, well do you need it back today is one of the questions I typically get asked when it turns into some kind of work. Cause then if they’ve diagnosed it, they know the problem before they rip it apart. They can say, hey, do you need it back today? You know, maybe I pick it up and drive it with whatever problem it has for another day or two until our schedules are more flexible. So I don’t know, maybe he’s an agile guy deep down inside. So unbalanced focus as a dysfunction.

Sam Falco: [38:18] Yeah. So the product owner has to work with the team. The product owner is part of the Scrum team, right? So they need to be involved with the Dev team. They need to be doing refinement, answering questions. They also have to spend time with stakeholders, especially if you’re in a larger organization, but even if you’re not, let’s say you’re the entrepreneurial product owner, you still need to be out there doing market research. Uh, you may be needing to do sales calls or maybe you need to do a whole bunch of things. And so what I have seen happen is a product owner shifts too far in one direction or the other. The product owner is spending way too much time with the team. They’re there for every event. They come to the daily Scrum. Maybe they don’t say anything, but they’re there. Whether they’re needed or not. They schedule a lot of refinements, but they’re not talking to the larger organization or talking to the customers or doing all of those other things. And what can happen there is that the product owner then begins to lose sight of where the product needs to go to serve a broader purpose. On the other hand, I have seen product owners just pull back from the team, spend zero time with the team to the point where they don’t even come to maybe retrospectives or planning. They just show up for the sprint review, which at that point is usually called a demo. We’ve talked about that in previous episodes, that’s just one of my pet peeves. Uh, but they’re spending so much time with stakeholders that they’re not helping the team to understand what is needed and why. So then the team slows down because they’re, they’re not getting their questions answered or the team starts making assumptions that causes problems because, well, that’s not what I want. Then you get things like the product owner only shows up for sprint review and it becomes the sprint review is when the product owner accepts or rejects the product. No one is happy.

Dan Neumann: [40:06]  Well then you’ve got all the risks that you’re trying to avoid by doing agile methods. Then you get right into the sprint review. So yeah, avoid risk.

Sam Falco: [40:14] So that’s, that’s kind of, it’s a fine line to walk something the product owner probably should do is both should definitely attend the sprint retrospective, but sometimes ask the team as part of that, are you getting the right attention from me? Do you need more, do you need less? Or at least explain, hey, here are some problems I have. And also remember the product owner is accountable for ordering the backlog is, is accountable for making sure that the development team is working on the most valuable stuff. But that doesn’t mean the product owner has to do that stuff. So the product owner can delegate to the team, to the Scrum Master if they’re willing. Some of those responsibilities and I’ve seen product owners be very unwilling to do that because they get this idea, I’m accountable, I have to do it all. And so there’s that there they’re too much in control. And there’s that rigidity that we talked about earlier is a bad thing as an anti-pattern. But I’ve also seen other than just pull way too far back, they don’t write stories anymore at all. They just sort of drive by and lob some, some requests over the wall and they let the team do what it wants and, and that can make for in the short term, a really happy team. They’re building cool stuff. They’re building exactly what they want, but that might not actually serve the needs that it needs to.

Dan Neumann: [41:40]  Right. And I do like the fact that anybody can contribute to the product backlog. It’s the product owner though, who’s responsible for that being well-ordered to optimize value being delivered.

Sam Falco: [41:55] Right. I had a product owner who had a query set up that he would run every so often, uh, that would show him all the new stuff in the product backlog. And it would exclude anything he’d written. Okay. So you’d right away see, look, here’s 10 things that came in since, since last week who wrote these? Go talk to that particular person, whether it was a stakeholder or developer and quite often in this situation it would be a developer who’d thought of a cool thing, stick it in the backlog so that we can talk about it later and decide does it stay, does it move up? Where does it go?

Dan Neumann: [42:27]  Yup. Super valuable for them to have a way of keeping organized, keeping on top of that product backlog. So the product owner role, suffice it to say is complex and difficult to do. Yep. You’re at the mercy of the organization if the setup isn’t good and even if the setup is good, there are lots of little pitfalls that one can encounter. Doing that.

Sam Falco: [42:51] Absolutely. I took a product owner certification course years ago and I think the biggest takeaway I got from that class was I don’t want to do that job. I really liked being a Scrum Master, but product owner was just seemed like way too much for me.

Dan Neumann: [43:07]  Kind of a downer. Can we leave on a better note?

Sam Falco: [43:10] Well, my opinion has changed since then. I have been product owner on a couple of different initiatives, small scale stuff, but I did enjoy that.

Dan Neumann: [43:20]  Congratulations product owner, your job is really hard. I don’t want it.

Sam Falco: [43:27] But it is, it is really when you think of it, all of the, all of being on a Scrum team has its own difficulties. I mean, Scrum Master is a really, really hard job and I’ve had product owners tell me I would never want to have to do your job. And likewise, and I’ve been on a development team that can be really, really difficult and challenging. So I don’t mean that to be a downer. I just mean, I mean that to be fully respectful, a product owner is a really, really important role. It’s very difficult to do and deserves someone who really has a deep love for developing new products and bringing positive change into the world.

Dan Neumann: [44:05]  Yeah. And for deciders who are helping figure out who is going to fill the product owner role. Realizing that it is not just to show up for the daily Scrum, do a little planning thing, a little demo thing and then uh, you know, check the box and run away. It’s, it’s much more complex.

Sam Falco: [44:21] Yeah. Because I’ve seen organizations where the product owner is just, it’s just some more responsibilities we’ve put on top of somebody who has essentially another job to do. We don’t want that. We want, we want someone who can really be dedicated to doing this and doing it right and doing it well and delivering high value to the organization, to the marketplace. And again, as I said a couple times now bringing positive change into the world.

Dan Neumann: [44:48]  Fantastic. And if folks have questions about the product owner role or some scenarios or other facets they’d want elaborated, they can email us podcast@agilethought.com or tweet it with the #AgileThoughtPodcast. And with that, why don’t we wrap up with what are you reading these days, Sam?

Sam Falco: [45:07] So conveniently enough, I’m reading “Business Model Generation,” because I’ve basically got a product owner something so I like getting into that role to understand how to uh, how to use that tool.

Dan Neumann: [45:22]  That’s super cool. Look forward to hearing maybe more about that. And for me, I’m actually reading um, this time and it’s called “Thinking in Bets,” by Annie Duke and it I think is also a valuable product owner tool because let’s not pretend we know everything and treat it more like there is actual uncertainty and so let’s make an inappropriate bet to move forward. So yes, Annie Duke, professional poker player, now consultant to executives.

Sam Falco: [45:49] Yup. I used to play poker and one of the things that I learned from doing that was to consider the ratio of the pot that you’re creating by making this bet compared to the odds of the next card you need is going to kind of complete what you’re, what you’re looking for. So that’s a, that’s a good way of looking at product development as well.

Dan Neumann: [46:07]  It’s fantastic. I look forward to maybe talking more about that. I’m trying to apply some of the things I’m learning there. Well, thanks for joining today, Sam. Appreciate it.

Sam Falco: [46:16] Thanks for having me.

Outro: [46:19] This has been the Agile Coaches’ Corner Podcast brought to you by AgileThought and get the show notes and other helpful tips from this episode and other episodes at agilethought.com/podcast.

Stay Up-To-Date