How the project outputs will be produced (the supplier in PM lingo) is only one aspect of the project. Projects typically have an associated business interest,

How the project outputs will be produced (the supplier in PM lingo) is only one aspect of the project. Projects typically have an associated business interest, and users who will use the products produced by the product. Certain resource roles (e.g. business analysts, UX specialists) can provide advice on the impact of decisions on the business case and the users, while others provide technical input, but project decisions typically cut across more than one of supplier / business / user interests, and it is in the interests of the business to ensure that someone can integrate the requirements of all three. Having a project manager (or equivalent role such as an agile 'Scrum Master') is not incompatible with employees taking ownership of the project - decisions that only affect the supplier, or fall within ranges that the business / user is happy with can be taken by the suppliers. Often, the PM's role is to facilitate agreement between the different stakeholders. It is possible for the PM role to be shared amongst the suppliers, but it is not usually a good idea for a big project, because being a PM is a specialist area in its own right hat developers have to learn separately from their specialist technical skills, and spreading the role across too many people can mean that context switch inefficiencies mean the PM role doesn't get carried out.