Is that what your workplace is like? 1. Product managers should manage products, not teams. Certainly they should not "own their team". Managing their product

Is that what your workplace is like? 1. Product managers should manage products, not teams. Certainly they should not "own their team". Managing their product means deciding what gets built and why. Generally, there is a balance to strike between needs of the company (e.g. make money, support overall company strategy), needs of users (e.g. want to listen to self-made playlists) and technical considerations (how difficult is it to build, can we implement something similar with less effort). Not sure what you mean by "no communication responsibilities", but striking a good balance typically requires talking to a lot of people inside and outside the team. 2. It sounds to me like you're trying to rid team members of as much responsibility as possible. Of course everyone has their strengths, but I don't see why a "frontend dev" cannot help out with backend code or any of the other work necessary to get the product out the door. Which should be the mission of the team. 3. Even if some people don't have the same level of technical understanding as you do, there are still lots of ways they can contribute. For instance, they can sit in meetings with stakeholders so you don't have to. If something is wrong with a user story, don't assume bad intent. Discuss the pros and cons of an approach and suggest alternatives. "The greatest admission is the implicit acknowledgement that product managers cannot work efficiently with teams organized by discipline. In any other industry that is the bread and butter of management: Coordinate and plan with other departments. Here we just eliminate this." The whole point of a product team is to bring people from different disciplines together to deliver a better product in less time. This is possible because of more direct communication and less organizational friction. "Departments" organized by discipline are generally plagued by bureaucracy and delays in communication. On the other hand, having a product team sit together in one room enables a completely different level and pace of collaboration. If something is wrong with your DB story, you just mention it, people in the room become aware and find a solution potentially within minutes. "And what's the outcome? A coherent product? Far from it. You get a bunch of features glued together by a UI no one really owned." This is exactly what product teams prevent. The whole team owns the product. They talk about what should be done and by whom.