It is not rare to hear discussions about the responsibilities and relationship between POs (product owners) and developers in software companies or agencies. In some companies, the PO sits at the top of the engineers and developers, in others it's vice versa, and sometimes they are at the same level. Who is right and what should be the relationship between them? In order to answer that question, we need to clarify their roles first.

Roles of developers and POs in a software company

Imagine a software company with a couple of developers who need to build a custom accounting software for a client.

Usually software developers are people with highly technical knowledge, knowing software engineering inside out, and are capable of building any custom software solutions. In order to build software, they have to understand the product they build first, in our case accounting. Since their expertise lies in software engineering, and not necessarily in accounting, that might be a bit of a problem.

Building software without knowing and understanding its goals, purpose and a business domain, can lead to a huge failure as a result. A solution in such cases is developers learning as much as possible about the business domain (accounting) and frequently interacting with the client in order to get more information about the business.

Why might this approach be problematic? There are a couple of reasons for that.

Usually there will be an initial meeting with a client in order to gather necessary requirements about the solution that needs to be built. Since developers' expertise is not in accounting, most likely they won't understand even basic accounting terms, which increases odds of a total misunderstanding of what the software is supposed to do. That will most likely lead to a failure.

Second, since developers don't know much about accounting in general, they usually have to talk to the client way too often. Even for very small fundamental things that are known and common in accounting, they have to contact the client and ask for the clarifications. Usually client's answers might come with some delay of a day, two or even more which might significantly slow down the development process which becomes very suboptimal.

Also, the client might get the wrong impression about the software agency and their expertise, since all the client sees is a bunch of elementary and basic questions every single day.

The interaction between a software agency (in this case developers) and client can be depicted like this:

What would be the solution to that?

Our software agency has to have a person with extensive knowledge about accounting, who is able to discuss it and to understand all terms and phrases regarding the topic. That person will be dedicated to talk to the client and be a middleman between the client and developers. Why is having such a middleman so important?

In an initial meeting with the client, who explains what needs to be built, someone has to receive and understand all requirements. Since our middleman has sufficient knowledge about the field, this is the ideal person for that task. Odds for misunderstanding drastically decrease since both of them speak the same language (accounting). Most of the requirements will be correctly noted without much guessing.

Moreover, further communication between the client and the middleman will be only regarding the specific features that need to be built, and not because of the explanations what accounting is and how it works. That makes the interaction much simpler and less error-prone.

Developers will benefit as well, since they will have someone in-house who is a domain expert in the field. The middleman is supposed to be here to teach developers everything about the domain (accounting) and explain to them what needs to be built.

Developers will probably throw a bunch of questions related about both, specific software and accounting in general. Our middleman is here to explain everything they need to know. Also, responses will be very quick since all of them are working in the same company, no reason for delay.

The middleman should actually act as an internal client. He is the one who explains what needs to be built, the one who creates requirements, the one who checks if the software does what it's supposed to do. He is the one who should think and act as a real client.

Our middleman is actually a product owner.

Now, the interaction between a software agency and a client can be depicted like this:

There will be cases when a client asks for a custom software solution totally unrelated to any known fields like accounting, e-commerce, banking etc. In such cases it would be impossible to find a PO who has an expertise in that. But even then, our PO needs to be trained to fully understand a client's business. POs should spend some time with a client learning the business and trying to understand its pain points where custom solutions help. That is a crucial and extremely important step.

If we hire a PO only based on how well he/she understands Jira, how well he/she can "manage" developers or based on the number of meetings he/she is capable of holding during a week, based on the number of stickers hanging on a wall, how well he/she understands terms like scrum, kanban, backlog etc, we are hiring a PO for wrong reasons. The real value of a PO comes in the domain knowledge and the expertise of a client's business.

POs are responsible for understanding a client's business, providing specification and requirements, making sure software does what it is supposed to do and to provide a real value for the client in terms of solving a business problem.

Developers are responsible for building software according to the specifications and requirements provided by POs. They should guarantee that the software is bug-free, reliable, secure, easily changeable & customizable and well tested.

Do we always need a PO?

A short answer is No. But in such cases, developers, or most likely a team lead developer, are responsible for understanding a client's business and being a domain expert in that field.

If a software solution is totally a custom one, then having either a PO or a developer doesn't make much difference. They both need to learn about the business from scratch. Having a PO wouldn't be necessary since developers would do the job as well as PO would.

But in a case when a client's business is part of some well-known sectors like banking, accounting etc. it would be necessary to have a PO with a deep knowledge of a given sector. Not having a PO and letting developers alone to learn about, for instance banking, wouldn't be a very smart move.

Who is the boss then?

A software company has to have in-house expertise in both, software engineering and in domain knowledge. Very often it's hard to find one person with both expertise, that's why we usually end up with two different people: a PO and a developer.

POs don't give orders to developers, don't manage developers, don't tell them how to do something. But they teach and help developers to better understand a business domain so that they can build a solution which will be useful for the client. So, a PO is not a developer's boss.

In some companies POs are under the tech branch, usually under the CTO, and get orders from technical people. This approach is also wrong, and might lead to neglecting business requirements in a favor of technical decisions. So, a developer is not a PO's boss either.

Based on all said above, it's easy to see that there is no boss! PO and developers cooperate together on solving a business problem providing a valuable software to the client.

Alle Artikel anzeigen