An effective Product Owner can make a world of difference – one which separates a ragged and so-so implementation of agile methodologies from the proverbial tightly run ship. But organizations can make the Product Owner role more challenging than it needs to be.
While individuals are supposed to be mastering (among other things) backlog management they are instead trying to navigate choppy waters associated with the areas described below. If you see evidence of any of what I am about to describe they are strong candidates for areas to improve on and will be rewarded if you are able to make changes.
Let’s start off right. The approach to assign the role often takes the form of “business, you need to provide us a Product Owner”. Instead prime the conversation with the shared understanding of what is needed. If there are differences in perspective, air them out first. A straightforward synopsis of the role should result. Something along the following lines perhaps:
1) Domain expert who …
2) will create and refine the User Stories
2) prioritizes the work for the teams
3) represents the business’ interests
4) can accept or reject stories
5) will make decisions for the team when the need arises
To THAT we would like to attach the description of Product Owner. Now who would we recommend?
This may seem like a subtle difference but it can significantly change how the role is positioned, what the expectations are … and even what hurdles can be anticipated. “Oh, so Mike doesn’t seem comfortable making decisions … is that something we can coach?”
This modified approach will help to avoid:
a) An ironclad assumption that a Product Owner must come from the business part of the organization (at least allow for the conversation)
b) Inadvertently overlooking a great candidate who has earned the right to be considered
Few would believe that it makes sense to throw a would-be ScrumMaster into that role with zero training – and expect great things to happen. And yet it is too often considered an adequate approach to have the Product Owner pick the role up on the fly. To expect them to perform at their best without training or mentoring will produce disappointing results and a frustrated P.O. There is a high likelihood that they will embrace a reworked definition of the role – one which is aligned with their prior experience. And so now there is the potential for unnecessary tension between the PO and ScrumMaster, and possibly the team too. We do expect Product Owners to be superwomen/men and have proficiencies in a diverse set of skills. Among them is leadership. The Product Owner is leading the team to a successful outcome. Yes, they should be getting some advocacy from key players. But it is hard to do this well without being given certain foundation skills first.
If you don’t give your POs adequate training there will result a (completely understandable) tendency to cherry pick only certain aspects of the role. So, for instance you may find that your PO attends requirements workshop but takes no responsibility for crafting User Stories. Moreover they may come to infuse lessons from prior approaches which will not work well in the context of agile. An example would be a lack of comfort with uncertainty and refining requirements just in time.
Finally, all of the above is true even for a simple one-team-being-agile scenario. If you are trying to scale a-la-SAFe then the situation is exacerbated even more.
Ambiguity of role definition
A senior director in an organization once shared with me that they were the Product Owner for the ABC product. It was evident though that they were not in any way associated with managing the backlog for a team and not attending key ceremonies of any team. There were of course many other things which they were responsible for (example: steering committee meetings) but engaging at the team level was not within their remit. Clearly in this case the term Product Owner had different connotations for this person. And that’s a problem. In other cases the problem is not as much a competing interpretation to contend with – the issue is that there is none. What prevails is a fuzzy notion of what might be suggested by the role. When this assumption is challenged by reality it can be a cold shower for some. As a practical consequence, the outcome is often that responsibilities end up becoming sliced-and-diced and then divvied up between a subset of the team. What makes sense will depend very much on that team’s context and so how the role is actually executed can vary significantly between teams within the same organization.
IT and Business Misalignment
Are IT and Business aligned to a common vision of what agile should look like your organization? We owe it to our business partners to make that compelling argument to them. We are after all about to spend their money. Of course, the compelling case for change is bigger than just what surrounds the Product Owner role, but you can often see the evidence of misalignment in how Product Owner functions are executed. When that larger conversation (at senior levels) between the IT and Business is missing you have a recipe for misalignment of priorities. In particular the priority given to the Product Owner position. And so we should not be surprised if we observe inconsistency in how the role is filled.
Let me set the scene: It is decided by someone with seniority that agile is the chosen approach. The IT part of the company (the ones doing the building) glances across the boardroom table to the business (the ones doing the paying) and requests that business provides a PO for the team. By the way, they must be dedicated to the team or this won’t work. Oh and there’s more. There are a ton of meetings which they must now attend and some which they should lead/chair. Now, this is new work for the Business and probably not planned or budgeted for by them. So they must now find some capacity somewhere from an already shrinking team and DEDICATE that person to the agile team. Viewed through the business’ eyes this is an impossible request. A person may be found who is a candidate (we have many) but they all have jobs. They HAVE jobs already. So there is no chance they can be released from their current roles. So one of two outcomes is likely. The first is that a less-than-qualified candidate is found to plug the gap. Meet new-hire-Mike who is going to rock your agile team. Bad idea – not only is this a gamble but new hire reqs are in short supply. The second option is that a spell is cast to generate more capacity. The name of this spell is “multi tasking”. The proposal is that Katherine will be assigned to the P.O. role. She is superb at what she does but we’ll just have to make do with 25% of her time. So Katherine can come to some team meetings but not all of them. Katherine can’t really provide answers at short notice – often she is unavailable. So it is inevitable that the role now needs to be reworked. Others are also going to need to step up a little bit. But a lot of meetings will occur which are ineffective without Katherine there. While all of this happens – Katherine is at risk of burnout. There is overhead associated with multi-tasking and that conservatively means that 10-20% of her bandwidth is wasted
Is this really a recipe for making all feel invested in a successful outcome? When we ask for a commitment from the team – how fair is that to ask? If you see this playing out and you have influence don’t allow this to happen. Stop. Restate/reassert that the goal is to build a high performing team. Agree on what that looks like. Build on that.
Empower your Product Owners. Empower them with decision making authority. That does not mean that they will make the right decision 100% of the time. Nobody does that (Babe Ruth did not bat 1000, Pele did not win every game). What it does mean is that based on the data they have available to them they will make decisions which will guide the team. Yes they will need some support and advocacy from the team. Teams need a chief-decision-maker and the Product Owner is it. Whoever is given that role, she/he needs to feel that they have the authority to decide and is comfortable exercising that authority.
Support for Product Owners
Product Owners need to be supported by their teams. We make this hard when the scenarios above are playing out. But the support needs to be there. The Team, the ScrumMaster and the Product Owner are mutually dependent on each other for success. There are several ways in which this should manifest itself. As team members we are free to have a good-faith difference of opinion with the Product Owner. But once they make a decision we need to respect it and implement it. If you want to be a decider … apply for the next Product Owner job. Get training then show the rest of us how it ought to be done. Providing advice/advocacy to the P.O. when you see opportunities to do so is also important. Systems are now too complicated for a single person to know everything. Finally as an extension of/proxy to the business the Product Owner needs to be able to count on the team to deliver on the plan (and therefore the value) that they commit to. Plans are systematically agreed upon and then executed. It is through the predictable realization of value that the Product Owners build a trusted relationship with the rest of the organization on behalf of the team.
Over to you….. what are your thoughts on how we have applied the Product Owner role in large enterprises?