On Product Ownership

Recently I’ve been dealing with disengaged product owners. You know the type: they don’t show up for the stand-ups, when they come to the standup meeting they don’t bring any stories and instead simply review whatever the team has brought to them – and then leave early because they have more important things to do. When they show up for the demo, they obviously don’t recognize the stories and simply give tacit approval to the work that the team has done. And the scrum master marks the work as accepted. The only time they express any opinion about the project is if it is late. Otherwise they are off in other meetings for projects that seem more attractive to them.

Call me a jerk, but these are the product owners that I least like to deal with. I almost prefer an actively hostile product owner – at least then I know that they care! Instead these ghost product managers do nothing to engage the passions and the commitment of the team. Soon I find that the team is coming to me and saying, “We don’t see much value in the work we are doing…” This is a very bad sign for a team. When you hear this from a team you can rest assured that you have a product owner who at best is distracted or at worst just doesn’t care.

Of course part of the problem is that I just haven’t worked with that many really good product owners. I think they are a rare breed. However, I saw something the other day that gave me pause. I was watching a coordination meeting for a big program that was getting started. The meeting was being run by a talented facilitator and there was a very charismatic product manager who was conveying a very obvious air of “being in charge”. You could tell that he had an ego the size of Texas. He was comfortable with public speaking, he used terms that were dramatic and conveyed a sense of purpose and commitment. He also conveyed the sense that he was confident an knew what he was talking about. People would defer to his knowledge of the business domain. He was brash, arrogant, had a full head of hair, and I almost instantly despised him. I know that type of guy all too well. He was just like me – with hair. What a jerk!

I saw him again a couple of months later and he was still selling the hell out of his program. I remembered thinking to myself, “Does this guy ever quit?” There he was in front of the team. He was basically reaffirming the value of the product that they were all trying to deliver. He was still selling the heck out of it! At the time I’m afraid I must confess I did not recognize the value of what he was trying to do. It all seemed a bit too “high school cheerleader” to me. So instead I settled for quietly loathing his presence.

So lo and behold, there I am a month or so later working on my own program. And I don’t happen to have a product owner who is charismatic, energetic, or at least has a face. No, instead I’m working with some guy I’ve only met once who lives on the east coast and who has not shown up for a planning meeting in recent living memory. The project is stumbling along, like many of them sometimes manage to do. Schedules are slipping, impediments are being worked around rather than being resolved, and we all pray for the day when we get to work on another project. And then it hits me.

I need to sell this baby. Well, somebody does anyway. It’s probably more suited to the product owner’s role, but in their absence somebody’s got to do it. Otherwise this project will just quietly fade into obscurity. Perhaps it should be put out of it’s misery. If you can’t get the product owner to care, then maybe the best thing to do is to let it die. But there is another school of thought here. Leadership on projects is not always clear. By that I mean that sometimes the product manager is a strong leader, sometimes the project manager is a strong leader, and yes, sometimes that giant dork, the development manager is a strong leader too. Sometimes, but not always. In fact the chemistry has been a little different on nearly every team that I have ever worked on. The fact is that the leadership may be hard to find, it may lie in different, even unexpected places – but it must be there somewhere.

One thing to keep in mind is that your leadership needs are going to vary based on the size of the group you working with. If the project you are working on is a nice little single team project with just a couple of iterations to it, then you probably don’t require much in the way of overt and active leadership. In that case it’s probably enough for the team to be well functioning and trusting each other. The commitment is small enough that it doesn’t require any particular skill of vision or any additional requests for re-commitment. The value of these small projects is often small enough that everybody usually feels that they are easily achievable and they don’t require much additional motivation to achieve.

Then there is the more complicated project, really more of a small program. These projects might have two or three different phases, milestones or releases to them. They generally take longer than your typical individual project and they require more commitment on the part of the organization and the team. The added risk and uncertainty, simply due to that introduced by the increased scope and the concomitant unknowns make these projects more worrisome to all involved. We’re not talking major fear, uncertainty and doubt here, but we are talking about the kind of program where, with just a few things going wrong, the mood can swiftly change from, “We think we can do this” to “We’re all going to die!” These are the types of projects that require someone, an engaged product owner – someone who will consistently paint a clear picture of the overall goal and help the team understand and appreciate the value that they are delivering to the customer and the organization. It may not take all that much, and you may even find that you can get away without it, but like I said, it’s much more likely in these situations that you will find that life goes a lot smoother with someone who is willing to actively rally the troops.

Finally, there is the genuinely large program – to me this is any program that has 3 or more teams, each of whom has multiple overlapping milestones that they need to hit in order to deliver the program successfully. Often times these teams are also distributed/dispersed teams as well. These are the programs where you need one hell of a good salesman. You need someone who is good at bringing people together and helping them feel like they share a common goal. Someone who is good at working with large groups of people – this can’t be the kind of person who will shy away from a room filled with 50 people. They need to be fairly energetic and be able to tell a compelling story. And they need to know the business really, really freakin’ well. They have to have some sort of very real respect within the group. For the really big programs, you probably need more than one person like this. Or maybe not. When I have worked with the multiple leader scenario I have also see a lot of infighting, which can be death for any project, large or small.

These are just some observations and speculations. They aren’t based on any kind of empirical data. To a certain degree they are based on observations of things that I have seen missing in myself as I work with teams. They are also what I often need from a product owner. Teams really need leadership as much as anything else from the product owner. However, leadership is one of those intangible skills that is very difficult to impart in some sort of training class. Certainly it is not the kind of thing that you will find in any sort of product owner certification course. The point is, I think teams need it from the product owner, some more than others, but they all need it.

Of course I suck at things unless I find some sort of way to formalize it into a set of things that I find easy to remember. So how would I formalize what I am asking for here? First I would bring back a much stronger emphasis on the project kick off meeting. This is the first opportunity to sell the project/program to the team and it is very important that you do it well. Second, I would put together regular status updates with the group, perhaps along the lines of key milestones that would serve to bring the group together and reinforce that original commitment to the project. Finally, I will treat impediments very aggressively and review them with the product owner and make sure that not only are they aware of them, but that they are taking an active role in resolving them as well. The team needs to see that the product owner is just as committed to removing project impediments as anyone else – perhaps more so.