|
I'm not yet an expert on this, but I'm coming to the same intuition that the writer has so let me attempt to explain. Let's say we have 4 domains, and 4 domain experts. P is product, B is backend, F is frontend, and D is database(this is heavily simplifying, I know there are many sub-domains within each depending on the scope of the project). Each new feature starts with the P expert working with the team translating the user requirements into what he thinks is needed. B and F communicate with each other. B and D communicate with each other. But since none of them have a shared understanding, the communication is of poor quality. You get mistakes. You'll find that if you had an PF expert the implementation would be 10x simpler. You get things where if you had an PBFD expert would be 1 million times simpler. Without the cross-domain knowledge you will never know when those simplifying measure are possible. The problem with starting with a P is that the expert is basically starving the rest of the team of the knowledge that they have accumulated. They handle that work, it's up the the product expert to come up with the new features. And by putting that title on their head, and never letting the developers in, it tends to lock in place. You are only as creative as your feedback loops, and your feedback loops depend on the bandwidth of communication. Within waterfall that might be months. Within agile that is a sprint. But with a PBFD expert your feedback loops can be measured in seconds. You don't need PBFD experts, but it is very helpful to at least have translators. So there might be a PD expert, there might be a BF expert. That way you can get a reasonable translation of the requirement out. By taking on the team a Product Manager who is explicitly non-technical person, you lock that P in place. I think that's why we're seeing push-back to PM's where it's a general domain issue. P is a fine role, if you also have a PD, if you also have a PB, if you also have a PF. The Fullstack developer is already a BFD, why not also train them in the product? The example I like to give is that Linus Torvalds created git in 10 days because he was a master user of Source Control and knew exactly what he needed while also able to create everything, while Microsoft's Source Control team had worked with hundreds of developers over years and couldn't compete. When you have hundreds working on a project the ability to communicate in a depth-first-search style drops to 0, and you are left to only breadth-first-search solutions. Metcalfe's Law destroys productivity. |
But in my experience the PM is technical enough to understand what's going on. (Can write some SQL to answer questions, possibly ex-engineer themselves, etc.) They're in the same meetings, same email threads, looking at the same set of OKRs, etc. It's part of the engineers' jobs (B/F/D whatever) to communicate their constraints and their ideas (both product and pure-tech) to the PM, and it's part of the PM's job to take those into account when advocating for what should be done.
Similarly, the more the engineers know each others' specialties, the better they can coordinate. It's probably more important for everyone to have "a little bit of product" in them, but that doesn't mean we don't need a product-specialist.
When it's time for quarterly planning, the PM's voice is definitely loud, but they're still just one voice in the room. They're the one accountable for the product, which gives them some leverage, but the other voices are there (TLs, managers, etc.)
Now I can see this going terribly wrong if the scale is off (only one PM for too many engineers), or if communication breaks down (PM scribbles a "design" on a napkin and faxes it over), or if only the PM is consulted for planning. But the problem there is that communication broke down, not that it's bad to have a PM.