It depends on a lot of factors: the culture and history of the company, the personalities on the team, the seniority of Product Managers vs. Engineers, etc. So there’s a lot of variation across companies and even between teams at the same company.

But regardless of job titles, the person on the team with the most influence on the team’s priorities should have a good understanding of:

• customer requirements (what do users need?)

AND

• product insight (what’s a solution to those needs that users will actually use?)

AND

• business sense (will our solution make us more money?)

AND

• engineering feasibility (can it be done at reasonable cost?).

On many teams the person with this constellation of skills has the job title “Product Manager” but on other teams this may be a development lead, or sometimes a Designer, or even (in small companies) the CEO. What the job title is matters less than having a person who can weigh the various factors against each other to come up with the best possible features for the team to build.

Some other thoughts on this topic:

• Most of the time, the senior leads of the team should agree on what developers should be working on. If the team is constantly squabbling about priorities, then productivity will be low, turnover will be high, and it will be a sucky place to work.
• In the (hopefully rare) cases where team members don’t agree on priorities, one person should be empowered to make the decision so the team can move forward. You *really* want to have a final decisionmaker on the team, because otherwise your senior management will be wasting valuable time on problems that a team should be deciding on their own.
• There should be a balance between time spent on feature development and time spent on non-feature tasks (refactoring problematic code, improving performance, writing internal tools, researching new engineering tech, etc.). Hint: if the % of time on non-feature work is larger than 30% or smaller than 10% then your product may not be long for this world…