Who is a Product Owner?

Some time ago there were only programmers who sat and wrote programs. Many programmers still believe that this is possible. But there is a problem: if you do this, then there will be no program. After all, programmers themselves do not make a complex software product. Because they program, not follow the release of the product.

More info here - https://romtos.com/

At the input, programmers receive a technical task, and at the output they issue a program code that will perform what is written in the TOR. All this looks good and great, but, firstly, the terms of reference must be drawn up by someone. Secondly, if in the sixties you could give a TOR and wait for results for two or a year, without visible changes, then in the modern business world this is impossible. If nothing has changed for you in a month, this already indicates stagnation and problems in business. Therefore, now the terms of reference are constantly changing.

It turns out that the programmers received a technical task, which is amended by the customer every few days. Some parts become more important, some are simply thrown out, some are added. This means that either programmers should work with this, that is, independently understand, set and change priorities, or someone else should do it.

So there were two roles - Project Manager and Product Owner. Project Manager receives incoming requests from the customer, which, as a rule, are not formalized.

The Project Manager must ask questions to the customer, refining the requirements in order to transfer the formalized TOR to the team. The Project Manager must explain the priorities, play with the scope, that is, with the amount of work, and most importantly, bring the project to the final. If in the same sixties the team received a technical specification, it was implemented, tested and released, now it will not work like that. Edits come in continuously, and if you wait for all the requirements to be met, the project will never be released. The Project Manager regulates the amount of work, makes sure that the team does not overestimate its strength and complete it on time, manages risks, and much more.

Project Owner is the custodian of product information. First of all, his role is to be a decision-maker. And all the bumps will fall on him if the team does not do what the business needs.

In dialogues with the team, he represents the business. This role is a source of information for the Project Manager because he tells the team what to do now and what to do next.

In many companies, the Product Owner and Project Manager are the same person. But it's not right. These are competing roles as prosecutor and lawyer. Project Manager plays on the side of the development team. He tries to do less work, to shrink the scope as much as possible. Whereas the Product Owner acts on the part of the customer, on the part of the business. It requires expanding the scope, adding tasks. He tells you exactly what you need, what you can’t start without, and what you can do without.

It often happens that the Product Owner is a representative of the customer. But in this case, he has tension with the Product Manager. The Product Owner can escalate problems to the management, and then the tension begins already between the companies. Therefore, the development teams quickly realized that it was easier to keep the Product Owner in the state. Then the customer sees a kind and affectionate Product Owner, and all conflicts about the scope remain inside.

Very often, a Product Owner is also called a business analyst. They seem to be completely different positions. The business analyst analyzes the business and determines what to extract from it. But in reality, the business analyst is just another face of the Product Owner. The Product Owner is the responsible person for the Project Manager, this is the person who is responsible for the business side and says what we do and what we don't. And for the customer it is a business analyst.

Who is this job for? First of all, people who are well versed in the business domain, that is, they know the subject area well. For example, if it is medicine, a doctor or just a person with a medical background will do. He will explain to the developers why this particular data should be here, and how the ultrasound results affect it. Neither the programmers nor the Project Manager will understand this themselves, because they do not understand this. If this is construction work, it is not bad that it be a person with experience as a foreman engineer who knows where a solution can fit, because he knows how it will be used.