Many articles have been written about the core competencies of Product Owners. These include owning and communicating a road map for their product(s), backlog management, stakeholder alignment as well as translating business requirements to technical features. Besides this, there are many more responsibilities and tasks that a Product Owner might or need to do. Which tasks actually depends on the organization you’re working in and the perceived expectations from anyone being in that role. Software teams that aim to successfully run applications in production understand that they need to keep an eye on small details. In parallel, for organizations that demand a proper Business IT alignment, it’s a must-have to explore advanced topics for Product Owners.
Context
Product Owners are responsible for the products they own. Often, Business Owners who are higher in the organizational hierarchy own the business they deliver through their products. In relatively small organizations, Product Owners fulfill more tasks than usual such as backlog management, envisioning the product roadmap, stakeholder management, and writing user stories. This is also true in large organizations where things are not organized optimally. Or where they trust Product Owners with a lot of responsibilities. In both circumstances, Product Owners might do more tasks that also correspond with more responsibilities. In this article, we’ll explore some of those tasks. Besides the “extra tasks”, there are also advanced topics that might be in scope for the role of Product Owners in certain organizations.
Budget controls and boundaries
Product Owners who execute IT-related projects for their products are not always involved in business and budget-related activities. Often, they do not have to negotiate about license costs, control and keep an eye on the total costs of the human resources which are in some way or the other involved in their products.
Despite this situation, sometimes they need to keep track of one or more of the following responsibilities and activities:
- Make sure the license costs align with the actual needs of the products they are responsible for. In case a vendor changes its license model, the Product Owner might need to re-evaluate how the license is being used or report the impacted change to someone else in the organization.
- Align product backlog epics (as called in Jira) with business goals. This might not directly affect budgets or other financial aspects, but there is a close relationship. Once an epic is attached to a higher-level issue type, financial departments can generate reports more easily. This might affect what the Product Owner has selected to be the “next compelling feature” or a major refactoring for a critical application.
- Companies have different policies on whether or not to employ internal people or to hire external experts. This also affects how much is spent on human resources. Sometimes Product Owners have to keep the right balance between internal and external personnel. Thus making him/her responsible for the budgetary aspects of this topic.
For sure, there are many more topics that include a financial aspect. I leave it up to the Product Owners in charge to list all of them that suit their situation.
License management
Every Product Owner who is responsible for software that requires a license is involved in this topic. In many cases, the Delivery Manager or Service Owner holds the responsibility of license management. However, sometimes the governance-related aspects are not (fully) in place. This might mean the Product Owner is also responsible for everything about license management.
Think of the following topics to add to your list of activities and thus responsibilities:
- Keep track of expiring licenses and be sure to renew licenses when they are about to be renewed. Sometimes this takes a long route in organizations that include other departments such as contract management, vendor management, or procurement. This all needs to be taken into account when prioritizing backlog items.
- Linked to the previous topic: licenses cost money. Renewing a license for a tool that might be phased out quickly after the renewal is a waste of costs. Sometimes, due to time constraints or other business priorities, this can’t always be avoided.
- Understand the conditions under which the license is valid. Tool vendors tend to restrict their licenses based on rules that work best for them. It can be very complicated to oversee these for the Product Owner who needs to know the inside outs. For example: license costs can be based on several compute cores (even for ephemeral resources like VMS in the cloud), lines of code, types of infrastructure resources, or number of users. In case a Product Owner hasn’t got a thorough understanding of the tools and landscape he manages, he might pay too much or fail to have sufficient licenses when it’s needed.
As seen in the above-mentioned list, license management adds up a significant amount of extra tasks to a Product Owner.
Certificate management
Security departments should take care of certificate management of the applications that are in the application portfolio landscape. Often they notify product teams when their certificates expire or in case of other problems.
However, if there is no well aligned security department or if they do not have a clear certificate management process in place, they might miss this task. This is also the case when they do not have a clear view of the applications or individual workloads they oversee. Especially in the cloud era, where microservices live and where all of them need to be secured using a dedicated certificate, this can be the case.
Such situations tend to lead to Product Owners being responsible for the certificates that are in use for their applications. Perhaps this is a “common task” for DevOps teams which are responsible from A – Z. Many organizations are not yet that far.
Business IT Alignment
Business departments demand IT projects to be traceable: Business Owners need to be “in control” – always. This means they need to have a firm grip on the outcome of IT-related activities. For Product Owners, it means they need to make sure that their roadmap is linked to more tactical or even strategic business goals.
In the old world, this means having a spreadsheet that gets updated now and then – say every quarter. In more modern environments, this could be a graph on a wiki page that gets updated automatically based on the set start- and end dates of their epics. However, this still requires manual intervention from financial departments to pull the numbers. This also gives no information about how many hours are spent on the actual features being delivered. Once you link your epics in some way to the hours spent on tickets, this is also traceable.
In essence, you’re now linking the features of your IT department to your Business Initiatives – thus aligning them with each other. This brings your organization a bit closer to strategic initiatives which lead to business architecture resulting in technical architecture, which then results in infrastructure that enables business workloads to run.
The CMDB
Every company should have a Configuration Management DataBase. This is a centralized “register” in which all the (business) applications are registered along with their dependent components, third-party dependencies, teams, owners, etc. Often, the Delivery Manager or Service Manager keeps track of the entries in the register that are related to the application in scope.
In smaller companies, there might not be someone with the above-mentioned role. Then the Product Owner might step in here. This adds another task to his/her list. It might take time to explore how the CMDB actually works and to fill it in correctly. Only when all information is properly filled in, this CMDB has any value to the organization. Be sure to check out the excellent articles of Fred Jonkhart on Medium to further explore this sophisticated topic.
IT Architecture
Often, Product Owners have a fair say in which tools to use for the capabilities they are responsible for. This also demands them to think about business requirements which should be translated to technical requirements in terms of architecture schemes and IT infrastructure architecture. Product Owners who are solely focused on the business side of things miss a key competency here.
In organizations where “working under architecture” is not so common or where architects are not properly aligned with the product team or where the Product Owner has a strong technical background, he/she might also be involved in deeply technical architectural decisions. This can be seen as an advanced topic that needs to be mastered. For many organizations, however, this is a very good practice so Business and IT come together in a single person focusing on a concrete IT product.
Wrap up
Product Owners typically manage their backlog, conduct stakeholder management, align business initiatives with technical features, etc. But there is more. Product Owners might also be involved in more strategic Business IT initiatives, budgetary controls, keeping the CMDB updated as well as handling tasks which are related to certificate management and license management. In summary, these are the more advanced topics that might be the responsibility of Product Owners in certain organizations.
