Looking for the best product owner
If I had to mention two things that can change the fate of a project, it would have to be domain-driven design (DDD) and agile methodology. One of the most popular agile methodologies is Scrum, which provides the product owner role. Unfortunately, I’ve noticed that in many projects, the weakest link of the team was the product owner. This is not because they are generally bad product owners; it’s possible that in other projects they could do a great job. Although it seems obvious, not everyone realizes that the product owner should be the domain expert. Otherwise, they can just be a proxy to clients. This is a very uncomfortable situation. Team meetings, for example, often end up with the statement “I have to ask the client, can we finish tomorrow?”. This leads to a delay in the project and a decline in morale. To prevent that, developers skip the product owner and speak directly with the client. It degrades the product owner role to a secretary who adds meetings to a calendar, reserves the room, and so on. However, the essence of the process is lost; the DDD approach can’t be mixed with the Scrum methodology when the product owner doesn’t know the core domain.
Okay, but what about technical projects? By technical projects, I mean building metrics libraries, preparing Cassandra as a service platform, creating frameworks to manage frontend in a microservice-based architecture, etc. It’s clear that such projects are made for other developers. It’s also clear that no one understands the developer better than another developer. In the case of a tech project, a good product owner should be a technical person. However, there is nothing wrong if the mature team decides to work without a product owner (it’s not going to be Scrum, but it can still be the right process). Likely, after some time, an informal one will emerge. This is a model example of a self-organized team.