If I had to mention two things that can change the fate of the project, it would have been domain-driven design (DDD) and agile methodology. One of the most popular agile methodology is Scrum which provides product owner role. Unfortunately, I noticed that in many projects, the weakest link of the team was a 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, She/He can be just a proxy to clients. This is a very uncomfortable situation. A 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 process is lost, DDD approach can’t by mixed with scrum methodology when product owner doesn’t known the core domain.
OK, but what about technical projects? As technical I mean building metrics lib, preparing Casandra as a service platform, creating framework to management frontend in microservice-base architecture, etc. It’s clear that such kind of projects are made for others developers. It’s also clear that no one better understands the developer than the other developer. In a tech project case 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 gonna be not a Scrum but still it can be right process). Likely, after some time informal one will emerge. This is a model example of self-organized team.