I recently attended BBC, the official conference of the IIBA®, and I’m summarizing what I learned from the sessions I attended. The topic of Product Ownership has been hot for years, and it continues to be a subject of great debate.
In the presentation “The Product Owner’s Right Hand” by Alan Koch of Cprime, five scenarios were explored in which a Business Analyst may assist fulfilling the responsibilities of Product Ownership. As a consultant, I have seen all these situations play out myself, and for the most part, I agree with Alan’s assessment of what happens in each.
Here are the five scenarios that were explored:
- Active Product Owner
- No Product Owner
- Absentee Product Owner
- Several Product Owners
- Product Owner Committee
But, before digging into each scenario, it’s important to understand why these situations might happen. The bottom line is that it’s hard to fill the Product Owner role because one single person must have the knowledge, authority, and availability to perform this job.
Now, let’s check out each scenario:
Active Product Owner
If there is an active Product Owner on your team, you are more fortunate than most. Having a PO that is engaged daily and fully participating sets you up for success. But that doesn’t mean there’s nothing to do for a Business Analyst. In reality, many POs simply don’t have the time or right skills to perform Business Analysis, and this is where a BA can step in and provide a ton of value by facilitating interactions among the team and stakeholders.
No Product Owner
If you’re in the unlucky category, you don’t have a Product Owner at all. In this case, the Business Analyst often becomes a surrogate PO. However, there is one downside in that the BA may not have the authority necessary to be successful in the role. On the flip side, BAs can do most of the activities that Product Owners are typically responsible for. They can interact with customers and users, and help guide the developers on the Scrum Team.
Absentee Product Owner
If you have a Product Owner that is assigned, but they’re absent because they just don’t have the time (or the interest) it’s almost as bad as not having a PO at all. However, if you do have an anointed PO, as a Business Analyst, you must still find a way to get things done within this constraint. In this situation, you act as a Product Owner Delegate. You need to absorb as much information as you can about the product and provide the PO with key information. In essence, you are acting as the Voice of the Product Owner and filling the time gap.
Several Product Owners
Having multiple Product Owners is a recipe for disaster, based on my experience, but sometimes it does happen. When this is the case, the designated POs may disagree about decisions and priorities. To address this situation as a Business Analyst, your role is to facilitate consensus among the group of Product Owners, arriving at one voice. You will also facilitate interactions with stakeholders, users, and developers.
Product Owner Committee
Having a Product Owner committee is similar to having multiple Product Owners, but the expectation is that the committee itself must resolve its own agreements. That said, they still need to have a single voice. As a Business Analyst in this situation, your role will be both facilitator and spokesperson for the committee. You will also continue interacting with other stakeholders and users, and represent the voice of the committee to the developers.
Final Thoughts
This presentation was a great reminder to me that having a single, active Product Owner is ideal; however, in reality, it often doesn’t work this way. As Business Analysts, we are uniquely skilled and positioned to fill the gap. So if you find yourself in one of these positions, I hope this recap of Alan’s presentation is helpful!
If there are any other tips or situations you have seen that are not covered here, please let me know in the comments below!