We live in the DevOps world now. Businesses implement CI/CD processes throughout their entire organization. Traditional teams have evolved to multi-disciplinary teams, delivering new features and release to production more quickly and with higher quality applications, removing organizational silos and long waiting times and queues between departments. Scrum masters make sure the cadence of the scrum events helps the team to achieve their goals. But what does the traditional Product Owner do? Did the role of the Product Owner change in the world of DevOps? For sure, there are changes. In this article we are exploring a number of them.
The “traditional” Product Owner
Before we jump into the role of a Product Owner within a DevOps world, let’s first summarize some of the key characteristics of a Product Owner in a (well established) Agile environment. A Product Owner typically has the following responsibilities:
- The Product Owner is like the project’s key stakeholder: they represent all other stakeholders that benefit or influence the final IT product. It’s in the name of the Product Owner: they “own” the product in terms of communication, goals and upcoming work.
- A Product Owner should have a clear vision on where the product is going. They need to follow market trends, listen to other stakeholders and acquire customer feedback to improve the next iteration of the product.
- The Product Owner collects all of the features and issues and prioritizes them through the use of a so called “backlog” (list of work).
- The Product Owner owns both the functional and the non-functional attributes of their product. This includes any technical debt accrued over time, and includes the responsibility to prioritize and fix it.
- In the end the Product Owner represents the IT product being delivered by the team, so they should have a clear understanding of the system and all of it’s dependencies.
No news so far, what has changed when DevOps entered the stage?
What changed?
In the past, Product Owners delivered functionality once per week to once per couple of months. The Product Owner needs to move faster in the DevOps era. Competition, especially for tech and online companies, is based on speed of delivery. It’s a primary success factor for businesses. The successful Product Owner should keep the product roadmap dynamic and make sure they can deliver expected value within time.
The DevOps way of working incorporates these principles of speed, feedback, continuous improvement and automation. Some teams are able to release multiple times a day whereas, in the past, new versions were released a couple of times per year only. Releasing continuously is an ever-growing trend. This situation is a significant shift that a modern Product Owner should be aware of to be successful in their work.
In the pre-DevOps era the Product Owner could take decisions based upon market research and other trends. These days, continuous feedback by (automated) systems and customers who are heavily involved are much more important. This impacts the product roadmap. It now changes every day or at least every week. As feedback comes from the applications which are build by the DevOps team, the feedback is faster and more context specific. No need to wait for (the same) feedback from the actual customers. However, don’t forget to listen to your customers about their wishes! Close collaboration with support teams is needed. And don’t forget the security issues which needs to be fixed and/or patched in time to stay secure.
Typical challenges
As said, a Product Owner is in the middle of everything. They need to pay special attention to a lot of stakeholders and involve them on the right levels using the appropriate communication channels. Other typical challenges for Product Owners include the following:
- In a DevOps world, stakeholder management becomes even more challenging. Stakeholders are aware of the ever changing world. Product Owners from other teams can be stakeholders too. Both teams interact and have the same challenges – thus the levels of complexity becomes bigger than ever.
- A Product Owner needs to take the right decisions at the right time with the right set of information. As information about systems change very fast, this can be an extra challenge. Product Owners should take into account the demands from other stakeholders as well to make an informed decision.
- Ship the intended product within time and within budget. Extra challenge: keep track of the details of all aspects of the product dependencies. Basic question: where do you store these items?
- A Product Owner needs to coordinate al of these tasks between the internal teams and the stakeholders and customers. Besides this, they need to balance they thoughts about the (future of the) product when triggering and facilitating the collaboration.
Creating a highly transparent work environment for all of these parties is essential. Some organizations choose to enable a single Application Lifecycle Management (ALM) system for all of the developer teams. Other organizations choose a set of tools which are connected together to fulfill this difficult requirement. In order to make informed decisions, the information should be in the right format and correct at all times. This greatly influences the quality of the product to be shipped. In the end it’s the quality that matters.
Thinking in terms of “systems”
Referring back to the first paragraph of this article, the traditional Product Owner focuses heavily on the delivery of features. Their role is more “project-centric” than “product-centric”. In the DevOps era, the product is the most important aspect to consider. Everyone contributing and collaborating to the product should have the vision and (business) goals for the product in mind.
A modern Product Owner should focus on the product lifecycle instead of just features to be shipped. New features need to fit into the context of the bigger system, they should support the product lifecycle from birth to retire. Some articles on the internet already refer to the “Product Lifecycle Owner” instead of just the “Product Owner”. It’s the system as a whole that counts here.
Thinking in terms of systems require a greater level of overview while keeping the details of the individual product in sight. From this perspective, it is important that a successful Product Owner is capable of segregating these overviews and not drown into all of the details. Once failed on this the overall vision blurs and the organization might steer into the wrong direction (e.g. putting the wrong requirements in place or deliver features which contribute less to the mission of the organization).
The importance of non-functional requirements
New features demand a clear set of requirements. Functional requirements tend to be practical and concrete. Those are the ones which are relatively easy to create. Examples are: “add an extra help page to the portal website in which visitors can find an FAQ.”
How different are the non-functional requirements. These are not so tangible and in most cases a little more difficult to write down. Non-functionals are attributes that describe the quality of a product or system.
At first sign, non-functional requirements do not have any relevant business value. However, these become much more important in DevOps than before. Why is that?
In DevOps the product should be shipped as fast and as often as possible. Preferable without configuration errors, bugs and other issues like performance bottlenecks or security flaws. The right scanning and monitoring solutions should be in place to detect any issues here. But that’s too late in the application lifecycle. Your new version is already deployed. Non-functional requirements make sure to capture any potential problems before you actually deploy your new features. But they also include whatever is needed to deploy your application.
Operational requirements
Non-functional should help to keep the system up and running and to facilitate fast and reliable delivery of new features. It’s impossible to think in terms of the product lifecycle and the entire system when there is no reliable deployment environment in place. Therefore, it’s important to pay more attention to the non-functional requirements. If needed, teams needs to be trained in it, since those requirements should come both from the business department as well as the technical departments.
The term “non-functional requirements” tend to sound a bit negative – like they do not contribute to the business value at all. Some coined the term “operational requirements” for this matter.
Examples of operational requirements are:
- Proper unit tests for code snippets which build up the infrastructure layer (e.g. Terraform unit tests).
- A patching strategy and implementation to fix issues without causing any downtime.
- Integration tests for components which build up the infrastructure solution (e.g. a Kubernetes cluster).
- Performance tests of the various components (ranging from the deployed application to the infrastructure components like storage and memory).
- Pay special attention to latency related issues before they could hamper your application and provide a bad experience to your end-users.
Deeper technical knowledge
Derived from the previous point, it’s obvious that the Product Owner should have a deeper technical knowledge than before. A Product Owner in the DevOps world should understand more on the following topics. It’s just a list to get your thoughts in the right direction.
- Cloud infrastructure and the role of Infrastructure as Code.
- The interplay of Infrastructure as Code and the application lifecycle.
- How to implement proper product lifecycle management in various cloud environments. For example: the promotion of an application through different environments changes. It’s not about the (re)deployment on a static Virtual Machine anymore.
- Deal with the concepts of (horizontal) auto-scaling and what that means to an application and the data being processed.
- Understand the cloud native security risks and their impact within a containerized and highly flexible environment.
- How to handle the large amounts of monitoring (alerts) and logging from the perspective of cloud native applications.
All of these items require advanced technical skills which Product Owners need to acquire to make informed decisions.
In case the Product Owner “knows their stuff well” it really helps to set the vision and goal for the product. The team can anticipate on it to make sure the right features are being developed with this vision in mind. Both should be in sync. In the end, the alignment the business and IT departments is improved.
Conclusion
The traditional Product Owner as we know it right now, slowly evolves into a “Product Lifecycle Owner”. Thinking in terms of “the entire system” and the product lifecycle becomes the new guideline to ship new features, faster and more reliable. Operational requirements should get more attention to make this happen. I hope this article inspired you to re-think the role of a Product Owner in the DevOps world and to adopt these best-practices in your organization.
