Do we need a PO?

We must first know what a PO is

Surely you have heard of different profiles within a software project. Of course, we have the developers, the QAs, the technical leaders, and sometimes we have the dbas.
But in another aspect of the project, other profiles appear, such as project managers, business analysts, and product owners.

We know that a project manager is in charge of keeping the project running on the defined rails, managing tasks and people to arrive on time and on schedule, and with the desired quality. We also know that a business analyst is in charge of analyzing the requirements and lowering them in detail so that the rest of the team understands them and the PM himself can manage them. But do we know what a PO does?

Ideally, a Product Owner is part of your team and not ours. But in the process of being your technology partner, we must go beyond a simple task executor. We must integrate with your team and work with you from the center of everything.
The product owner can help define the product roadmap, can determine priorities, and understand what is best for the project, both from a technical side and from the business itself.
In addition, the PO is in charge of managing the tasks in such a way as to obtain the maximum value in the least possible effort.
But for all this to be possible, it is necessary that we try to comply with some points:

Measure results, not lines of code

It is often believed that the best measure of a good team is the amount of code written or even the number of hours executed. But the important thing is the result really.
You should measure the developments that went into production, and even more, you should measure the value of each one. It is also often believed that the more functionalities developed, the better. But the truth is the other way around, if one can save lines of code and new functionalities to solve a problem, all the better.
What a PO does is precisely guide you and the development team on the best path, on the path that returns value with the least possible effort.

The value and investment of the product

Sometimes development requests are received one after another without actually thinking about a few things first.
What the product owner must do, having knowledge about the product, the market, and the roadmap is to catalyze these orders to lead them to a successful conclusion.
A development that does not add value should not be included. Each development includes a high investment that weighs on the wallet and on the entire product roadmap. Therefore, each development that wants to be included must really think if it is needed, if it should be implemented in the defined terms, if it is better to modify it, etc.

Welcome changes

Although there is a roadmap and there are definitions of functionalities to be developed, the natural thing is that things change. Sometimes priorities must change because the market wanted it that way, a date, a situation, etc.
The product owner is always in communication with the client and with the development team. He is the one who represents both parties, the business and the development of the product. With this in mind, he must communicate each change to the team so that they are implemented as required at all times. Of course, he must also evaluate whether a change should really be implemented or if it was requested because a pressing situation made us decide.

Ideally, the product owner belongs to the client, but this is not usually the case. Usually, there are inconveniences that make it difficult for it to happen.
It is difficult for a member of the client to dedicate the necessary time and have good communication with the development team.
By offering a product owner in our own team, we improve that situation, acting as a proxy between the development team and a client-side manager.

When can a proxy PO help?

When time is short. The job of the product owner in addition to simplifying processes is precisely to save time. In the mediation and in the refinement of tasks, the time consumed by the developers and the client himself is minimized.
When the client's PO or part of the team is not used to agile work. While a scrum master would be very helpful in this case, a Proxy PO on the development team can be enough. A profile like this one can keep the work focused on the objectives and help the client's PO to focus on what is important, on what offers the greatest value. This ultimately saves time, money, and headaches.
When the development team is external. In this case, it is essential to have a PO Proxy that can deal with the internal problems of the team, know-how development is progressing, what the business is about, and how to talk between one world and another, greatly simplifying the client's work.