The Scrum Product Owner In The Wild
As we dive into this series, if you’re in the software engineering field, you’ll already know that a large percentage of software engineering projects end in “failure”. Either they’re scrapped before being completed, or they don’t live up to their goals, or they run out of funding. All of these possibilities and more. Therefore, I thought it was a fitting place to begin this journey with the Product Owner. This role is central to a project’s success or failure. That certainly doesn’t mean they are to blame when a project fails, but an effective one can go a long way to prevent that from happening, or at least see it coming. So let’s get started.
Scrum.org describes the Product Owner’s responsibilities as follows.
As a member of the Scrum Team, the Product Owner provides clarity to the team about a product’s vision and goal. All work is derived and prioritized based on the Product Goal in order to deliver value to all stakeholders including those within their organization and all users both inside and out. Product Owners identify, measure and maximize value throughout the entire product's lifecycle.
When it really comes down to it, the product owner’s role is to act as the liaison between product Stakeholders (users, business owners, operations staff, etc) and the Scrum Team (The group working on the solution). Below is a typical diagram of the relationship. Seems simple, right?
Every last one of the diagrammed people on left and right are very opinionated when it comes to identifying problems and creating solutions. A Product Owner has to have thick skin, and be able to control situations.
The interesting thing about Scrum documentation as it relates to the Product Owner is that it essentially says the Product Owner should be ready for anything, and needs to potentially wear many different hats, or specific hats at different times, depending on the team and the stakeholders they are representing.
In reality or In The Wild, the hats they have to wear, and the difficulty of the role ultimately comes down to the level of skill of a set of key players on both sides of the spectrum . . . or possibly whether the mentioned player even exists.
I’ve been asked the question in the past, “What kind of person makes the best product owner?” And the answer is that it really depends on the team and the stakeholders being represented, but when it comes down to it, here are some key qualities that make for a good product owner “In The Wild”. It stresses me out just writing this list. A product owner needs to be a special kind of person.
Assertive but patient
Willing to take ownership over a problem
Flexible and confident personality
Collaborative
A product owner may need to collaborate with the following personalities all in the span of a couple of days:
Highly experienced business executives
Users who don’t know what they need
Inexperienced software engineers
Highly experienced software architects
Project managers trying to stick to a schedule
Demanding customers
Product Owner Partnerships
When it comes down to it, ultimately it’s a group of key partnerships that define how a Product Owner’s role will end up playing out In The Wild. The way these partnerships come together to form the role ends up looking like a spectrum. This makes the Product Owner role either tight and well defined, or very broad and all encompassing. As Scrum.org suggests with those puzzle pieces, a Product Owner can wear one hat thereby making it a manageable job, but in some cases, they end up wearing all the hats. In those cases, the role of Product Owner can be very difficult.
Product Owner ←→ Product Owner
You read that correctly. It’s not a typo. The most important guidepost for what a Product Owner’s role will look like In The Wild is the personality of the Product Owner themselves.
Are they the kind of person who likes to control a situation, control a product or a project? Do they give off executive vibes?
Or are they more passive, less likely to take the bull by the horns? Waiting for guidance from another role? As you’ll understand while we continue with the other partnerships, this can be the primary factor in determining what this role looks like, and ultimately how successful their product can be.
There is a lot of pushing and pulling that goes on in software engineering projects, so if a Product Owner doesn’t have the right personality to handle it, and they aren’t able to maintain control, a project can get out of control rather quickly. Much of the role may be maintaining that control in a turbulent environment.
Product Owner ←→ Product(s)
The Product Owner’s primary responsibility is always, you guessed it, the product. Whether it’s one product or several, a large part of the role is dependent upon the state of the product itself.
Brand new, “Greenfield”
In some cases, a Product Owner might be hired to launch a new product, or to bring to life a software desire that a business owner has. These cases require special vision, and more importantly, great partnerships with the roles below, which we’ll continue to get to.
Creating something from nothing is always much more difficult and taxing than maintaining or adding enhancements to an existing system. In these cases, not only does the vision need to be clear to the team, but personas need to be thought through, along with an entire hierarchy of features, user stories, screen designs, roadmaps and timelines. All of these things aren’t singularly executed by the Product Owner, but are dependent upon key partnerships, and it is up to the Product Owner to see that they come to fruition. While they are working on all of this tedious detail, they must also be in contact with stakeholders, assuring them of progress, and making sure the engineering team has what they need.
In The Wild, this is the most difficult type of product to be involved in. It is also the most rewarding, if successful.
Launched but young and buggy
A new application often takes some time to stabilize after initial launch, and for early bugs to be addressed. Not only that, but keeping users informed of fixes, what’s coming next, training initiatives, and stakeholder communication often keeps a Product Owner busy in scenarios like these.
The primary areas of focus here will be bug tracking and planning with the team, along with roadmapping the future plan for the application. These two areas are critical for keeping stakeholders informed and engaged.
Launched and mature
In the case of a fully launched product, the Product Owner role is typically going to be one of documentation, new feature additions, bug fixes, training, and subject matter expertise.
It still requires a strong team, and all of the same important roles discussed below, but it is typically the more laid back scenario, as compared to handling a new or less mature product.
Internally or externally facing
In terms of quality requirements, whether a software application is directly used by customers is the primary driver. Many applications are internal to a business, like a Point of Sale, or an inventory management system, or an ERP. While quality is, of course, important in these internal situations, it jumps to a whole different level when customers are directly interacting with it on a regular basis.
Things like web storefronts, social media experiences, mobile apps require much more rigor since their use is a direct source of customer involvement. Therefore the Product Owner must put extra emphasis on the collaboration with their Quality Assurance partnership.
Product Owner ←→ Business Owner
Active participant, or giving PO full process ownership
The best case scenario for a Product Owner is when the business owner/executive sponsor of the product provides clear value, and clear goals for what they would like to see out of the product, but at the same time, gives full ownership to the Product Owner for execution.
Typically business owners in this context are not familiar with product definition, roadmapping, Scrum processes or project planning principles. So when they are heavily involved, it’s often typical for their egos to get in the way of it getting done properly.
This isn’t always the case. Sometimes the business owner might also happen to be well informed in these principles, but that is rare. In most cases, we would prefer that the in the trenches execution, prioritization, etc be handled by the Product Owner and the team.
Knows what value the Product should bring?
This is a key factor for identifying whether a Product Owner will be able to be successful. When it comes right down to it, when a product exists, it typically provides some kind of value. i.e. There is a reason for its existence, and a reason to continuously improve it. The best source to define this value in the business context is the business owner, who is tasking his business to use it, whether internally or externally.
Knowing a product’s value is a key piece of operating with a successful software team, so when this isn’t the case, the Product Owner is left to decide that value on their own. This may conflict with the goals of the business itself, and cause problems in the future of the product. So, it’s always preferable that the business owner has a good vision, and knows the value of the product in question.
Supportive and understands the PO role
The right kind of support from a business owner is often a critical aspect of a project’s success. When the business owner understands the role, and trusts the Product Owner, great things can happen. On the other hand, when they miss some of the key facets of product ownership, they may directly undermine the Product Owner’s ability to execute, whether they know they’re doing it or not.
For example, an executive may attempt to have direct 1 on 1 contact with an engineer on the team, and attempt to set their priorities. A Product Owner will need to step in and find a way to make sure that doesn’t happen. At least without their prior knowledge and buy-in.
Product Owner ←→ Users
Do the users know the product already, or is it new
The age of a product and the experience of the user base is important, due to the potential need for training, documentation, extra user support, and other types of basic involvement with the user community.
When the product is new, a lot of this may fall to the Product Owner to coordinate, and implement. In all cases, the Product Owner will want to interface with users as much as possible to learn from them, and make sure their needs are being met, in addition to making sure they are trained and using it properly.
Are they external or internal
Another key difference in a Product Owner’s role depends on who the users are of this product. Are they external (customers), or is the use of the product restricted to internal use only.
This difference drives the Product Owner’s posture, and also dictates what kind of person is necessary for the role. Do they need to be able to interact with customers, assist in a sales-like capacity? Or is their communication limited to internal stakeholders?
Product Owner ←→ Scrum Master
Does this role exist?
On a product team, a Scrum Master or a team facilitator is a critical role. They handle scheduling key meetings, helping clear blockers, coordinating team members, keeping track of sprints and related ceremonies, team motivation and escalation of key problems, and much more related to organization of the project.
When this role or person doesn’t exist, it typically falls to the Product Owner to handle all of this coordination, along with his or her other hats.
Experience level
Piggybacking off of whether or not the role/person exists in the organization, we’ll talk briefly about the experience level of this person. Do they have a handle on the Scrum process, or whatever process is to be facilitated? Are they experienced with the size of the product in play?
In cases where the facilitator (Scrum Master) isn’t qualified with sufficient experience, the Product Owner ends up acting as somewhat of a supervisor of this person, which is not an ideal piece of the Product Owner’s role, if it can be avoided.
Facilitating one team or many
In most organizations, there is either just one or a small handful of Scrum Masters who are qualified to facilitate major projects. At the same time, some of these organizations have many projects, and many different products. A small number of facilitators end up getting striped across many projects in these cases.
In these cases when they are loaded up with many projects, they are able to execute the bare minimum responsibilities, and there is typically fallout, which the Product Owner has to pick up.
The ideal scenario is where your Scrum Master is facilitating a team or a couple of teams related to a single product, so the Product Owner and Scrum Master can rely upon each other.
Product Owner ←→ Software Architect/Designer
Does this role exist?
This relationship is critically important on greenfield level projects. This encompasses both UX design and software architecture. When this role doesn’t exist and design/architecture falls to less experienced software engineers, it makes the Product Owner’s role tremendously more involved. They will often end up needing to not only write features, user stories, etc, but they are also creating screen layouts, talking to engineers about database structures, and more technical detail that Product Owners shouldn’t need to be involved in.
On the flip side, when this role does exist, the relationship is important as a lot of this initial planning and design is collaborative. It can become a problematic relationship if the Product Owner is used to designing screens or dictating too much technical implementation.
Experience level
We’ll talk more about personality when we get into the Engineering Team section, but suffice it to say for now that folks in the Software Engineering tree of roles tend to be confident, and in some cases, overconfident. Therefore, the experience level of the Architect role is of vital importance.
Just as we said about the Scrum Master partnership, it is crucial that the Product Owner and Architect can openly collaborate. That they have agreed on what rests solidly in each other’s role, and what parts of it can be shared.
Product Owner ←→ Engineering Team
Experience level
This is one of the areas that will exist in every software product team. However, there is rather extreme variability in the industry as it relates to the experience level of the team. Some software teams have high levels of experience, team-wide, and some teams have just one person with any amount of significant experience, while still others are very young and inexperienced. The importance of that experience to the Product Owner relates to how much trust they can have in the team building their product. Based on that, the amount of oversight that is necessary by the product owner can be higher or lower.
The experience also can be highly dependent upon the product stage as well. Does the team have a lot of experience with supporting systems, and creating small enhancements, but less experience building a new enterprise system, like the one in question? This can have a major impact on the success of the product, and the trust the Product Owner has in the team.
Personality
Just like the experience factor, software engineering teams tend to have varying types of personalities. Same can be said for the IT industry as a whole. Commonly, IT folks are introverted, and lack leadership traits that can be important to have on a team. When those are missing, the Product Owner needs to lean in more in order to ensure the team is succeeding and has what they need.
It is also not unusual for some personalities to be overly strong and opinionated on a software team. Sometimes, this can cause strife on a team. In these cases, a strong Product Owner/Scrum Master relationship is necessary to keep the team’s morale high, and the strong personalities in check.
Product Owner ←→ Quality Assurance
Does this role exist and is it robust?
This is the last key relationship we’ll discuss, but certainly not the least in terms of significance. Testing, documentation, communication, and other Quality Assurance related things are quite a critical piece of the puzzle for a Product Owner, especially toward the end of a project’s lifecycle. It’s ultimately the role of the Product Owner to ensure a complete and quality product, so this role is critical.
In many situations In The Wild, the Product Owner will find themselves doing a lot of their own testing. Sometimes this is because there isn’t a sufficient Quality Assurance group or QA role at all. This kind of situation makes the Product Owner’s job more difficult and stressful. Preferably, they have a QA team they can rely on to go through this process.
Wrapping Up
In The Wild, a Product Owner’s role complexity is very much dependent upon the variables they need to balance. From the business owner asking for the product, to the team working on the product, to the users who use it, to the product itself. All of these things will influence what kind of person is required for the Product Owner seat.
It greatly helps us understand what Scrum.org is hinting at with the puzzle piece graphic at the top of this article.
