There is often an open debate regarding the role of the Product Owner in IT sector teams. This debate sometimes comes up when the Product Owner does not comply with what is expected of them.

In terms of Scrum, the role of Product Owner has clearly identified functions and their correct performance is vital to the success of the Product.

However, when the Product Owner’r role comes from the customer, sometimes we find it very difficult to get them to meet expectations.

What do we do in these cases? Would it be more suitable if the Product Owner was someone from our company?

To answer this question, we must first know the responsibilities of a Product Owner according to Scrum. In addition, we should know what qualities make a Product Owner a Great Product Owner.

According to the Scrum Guide, these are the three responsibilities of a Product Owner:

They are responsible for maximizing the value delivered

For this, it is necessary that the Product Owner:

• Knows the Business.
• Has a Vision of the Product you want to build.
• Is able to define the elements that create Value.
• Is able to prioritize these elements according to this simple rule: first (as far as dependencies allow) the elements of maximum Value at least Cost. Most of the Products that I know are developed to make money, as much as posible and the sooner the better.

The Product Owner must ensure that a Product Backlog exists

Does this mean that the Product Owner is the person who must write them physically? The answer is “no".

If they don’t do it, they can delegate it to other people: stakeholders or other members of the Dev Team (analysts, UX, etc.) if the team has been assembled. But the person responsible and who responds to third parties is the Product Owner.

Therefore, if they do not write them down or doesn’t detail them to the required level, they must participate in its definition and description, guide the people who write them, participate in the Refinements and ensure that the maximum value is always prioritized at a minimum Cost.

The Product Owner must lead the Sprint Planning and Sprint Review, and participate in the Sprint Retrospective

• During the Sprint Planning, the Product Owner must define the Sprint Goal and the Product Backlog elements that will allow reaching that goal. The Product Owner should help the Dev Team understand those elements of the Product Backlog, explain them in sufficient detail and answer the questions asked by the Dev Team. The Product Owner must also be willing to negotiate the extent of the Sprint if it exceeds the team's capacity for that Sprint.
• During the Sprint Review, the Product Owner must also lead the meeting, and this is critical. You have to invite key stakeholders to explain which elements of the Product Backlog have been completed and which haven’t. You should also comment on the status of the Product Backlog, collect the feedback obtained during the Increment review, cross-check this information with the current state of the market, and update the Product Backlog for this feedback to be of value for the next Sprint Planning.
• Finally, in the Retrospective, the Product Owner must actively participate as a member of the Scrum Team to inspect people and their relationships, processes and tools in order to draw up a plan, actions, that improve the work of the team.

So let's start with something basic and obvious: if a Product Owner does not meet these responsibilities, either because of lack of time, capacity or commitment, then they can not be the Product Owner. In other words, the fulfillment of these responsibilities is a necessary condition to be a Product Owner.

Otherwise, there will be a dysfunction that, in the end, will end up hurting the development of the Product and frustrate the whole team.

These are the three basic responsibilities for any Product Owner. But if we want to be a highly valued Product Owner, in addition to the above, the profile should also have the following skills:

• Knowledge of Business.
• Decision-making capacity.
• Availability.
• Value Oriented.
• Know how software development works.
• Committed to the team.
• Good communicator.
• Achiever.
• Ability to resolve conflicts.
• Desire to improve their understanding and application of Scrum.
• Manage expectations.
• Trust the team and the framework.

Once we know the main responsibilities of a Product Owner and what qualities make them a Great Product Owner, we are able to answer the question we asked at the beginning, internal or client’s role?

In my opinion, whenever the Customer is able to offer a Product Owner and they are committed to the responsibilities of the role (which, in addition, implies knowledge of the Business and dedication) it will be a better choice than an Internal Product Owner.

However, if the Product Owner proposed by the Client does not commit, or does not comply with what is expected during the development of the Product, then it would be necessary to find another person to play the role, either someone else on the side of the Client or someone internal from your organization.

A Customer Product Owner, in most cases, will have more knowledge of the Business, "your" Business, and this is fundamental to maximize Value and know how to prioritize.

In addition, they are usually more influential in the different areas or departments of "your" organization, which is a huge help in resolving dependencies and streamlining integrations.

I dare say that in Paradigma we know how to solve any technical problem and this is never a blockage of a development, but what about cross dependencies and integrations with other products of the organization?

Here we need as much possible help to influence and mobilize the right people and a Customer Product Owner can unlock the doors we need to open.

Another aspect to consider is the ultimate responsibility for the Product developed. If the Product Owner is the Customer and the Product does not offer the Expected Value, it is the responsibility of the Product Owner, as it is they who decide and prioritize the elements of the Product Backlog.

This is not exactly a minor issue when choosing between an Internal Product Owner or the Client’s as, without a deep knowledge of the Business, there is a greater risk at play.

Among the advantages of an internal Product Owner would be their dedication, commitment to the team and knowledge of Scrum. Undoubtedly, an internal Product Owner will fulfill all the responsibilities of the role and will facilitate the balance of the whole team.

However, it is more complicated to know the Business, the organization, the stakeholders, the contacts and even those with decision-making capacity, which is fundamental.

It is difficult for your opinion to be respected and adhered to within the organization if it is not part of it, at least until a strong relationship of trust is established.

Another point to consider is the nature of the relationship established between the Client and the company. If we want to facilitate this relationship, ie more integrated, a mixed team formed by the Client and the company will facilitate transparency and increase the cohesion between both.

Transparency is a basic pillar of Scrum, opening the work that makes the team generate confidence and this is basic to avoid future frictions.

Conclusion

Although each case requires a particular approach, whenever the Customer has a Product Owner who is committed to the responsibilities of the role (and is even willing to pass evaluations by the team), can dedicate the necessary time and know the Business, they will be the option with greater probability of success.

In addition, it is the Customer who assumes responsibility for the Value generated, which makes sense since, after all, the Customer is the promoter of the Product.

However, there are cases where this is not possible for various reasons. Then we can count on internal Product Owners that will undoubtedly bring many other benefits, such as the commitment, dedication and deep knowledge of Scrum.

In any case, it will be necessary to study each situation to make the best decision in a specific context since, the development of Products is not, and never will be, an exact science.