What is a Product Owner?  Not long before I became one, I was unaware of the term.  I had, however, often heard of Product Managers who develop and maintain a product for a corporation.  I’m currently working at Red Hat, and we have several terrific products, with even more terrific Product Managers shepherding the product through its lifetime.  Product Managers are very heavily involved with customers.  Constantly meeting with them to evaluate how their product is performing and, just as importantly, determining new features that the customers need to have added.

But a Product Owner?  That was a term that I was unaware of until the day that my manager asked me to become Product Owner for the RHEL Container Runtimes suite of products such as Podman, Buildah, and Skopeo.  She explained that the position had just become open, and given my business and software engineering background, she thought I’d be a good fit.  Not knowing exactly what I was in for, I said, “Sure! Sounds like fun.”

The first thing I did was to look up the term “Product Owner” on Google.  One of the better definitions that I found was on TechTarget.  In a nutshell, the article explains that the “Product Owner is a role on a Scrum team who is responsible for the project’s outcome”.  They are the bridge between the scrum team and the product management team.  The Product Owner role is very much a balancing role, weighing the desires for the functionality of the customer, as presented by the Product Manager, and the output capabilities of the scrum team.

In addition to being a balancing act, my role as a Product Owner for the Containers Runtime Team has proven to be also a juggling act, with a fair amount of triage mixed in.  One of my primary responsibilities is monitoring problem reports, especially for any new issues reported.  I review all new reports in the early part of the day and then decide their importance and which engineer on the team would best be able to handle the problem and assign it to them.  Then, as the issues progress, I’m responsible for ensuring they are resolved on time, with shorter time frames for critical problems.  Given that, I need to leverage time during my day to monitor new and current issues.

As crucial as issues are, you can’t get too focused on dealing with issues as a Product Owner.  They are ultra-important to the job, but you must also ensure that new features are rolling in to keep a product fresh and moving forward.  My relationship with our Product Manager comes into play to ensure I don’t lose sight of new features.  At Red Hat, we deliver at least two Red Hat Enterprise Linux (RHEL) versions every six months.  For each six-month delivery cycle, I work closely with the Product Manager and several other people in my organization to determine the features that will be added to our products and delivered with the upcoming versions of RHEL.

Many of these conversations also involve our engineering, quality assurance, packaging, and documentation teams to verify that the planned work for the proposed deliverables is possible for each team without overloading any team in the process.  If one of the teams can’t deliver their requirements for a particular feature, further rounds of discussions will ensue to prioritize all of the planned content.  Sometimes, we may need to push some planned content to the next six-month cycle or, in rare cases, drop it from consideration entirely.

Features and Issues are the position’s primary responsibility, but many other things arise on a typical day.  They are varied and must be added to my daily “To Do” list.  I do a lot of work with our community, for instance.  I tend to the Twitter/X, Bluesky, YouTube, and Mastodon accounts.  I manage the variety of email lists that we have for our projects and keep an eye on and maintain the Podman.io  and Buildah.io websites.  I also plan and run the Podman Community and Cabal meetings and write up the meeting notes.  I’m always searching for topics for both and looking for content for our YouTube channel. 

When I get a spare moment, I will write a blog like this one or one that is technically focused.  As I started my career as an engineer, and I still officially hold that title, I do like to actually fix an issue and get my hands “dirty” by doing some code.  More frequently, one of the engineers on the team will find and fix a bug, and I’ll help with backporting to the variety of versions the fix needs to get into.

On top of all that, unplanned fires sporadically sprout out of nowhere.  These fires could consist of a new CVE that comes in, a highly critical issue from a major customer, changes to the team status, a CNCF submission, or changes in the RHEL deliverables that need to be accounted for.  Last but not certainly least, meetings.  With the number of people working on our projects and then others depending on them, both inside and outside of Red Hat, I spend several hours daily in meetings, coordinating and communicating with everyone.

What I think I’m trying to say here with all of this is there is never a typical day as a Product Owner.  I’m constantly planning to do “X, Y,  and Z” on a particular day, and then maybe do “X” and then deal with “A, B, and C”.  Things are constantly popping up that need to be considered, triaged, and then placed into the work plans for the team as appropriate.  

My days are always different and rarely as anticipated.  It’s a fast-paced job, and it’s very reactionary.  It’s a position that I love and find challenging day to day.  It’s one that I need to use all the organizational and engineering skills I have garnered over the years, and it is not like any other job I have held in my career.  I’m not sure if this is the typical Product Owner’s life, but it’s the life that I’m now very much enjoying and leading.