The bottlenecks are almost always elsewhere. Design, quality assurance and debugging, art assets, localizations, hiring, performance management, you name it. And to be fair, AI can streamline some of that.
The bottlenecks are almost always elsewhere. Design, quality assurance and debugging, art assets, localizations, hiring, performance management, you name it. And to be fair, AI can streamline some of that.
Literally all the time? Every single month?
I am struggling to understand your perspective. In my existence, the bottleneck is always the coding.
The development team has a backlog that could keep them busy for years. Meanwhile, everyone else -- QA, localization, whatever -- operates at whatever pace the code gets delivered.
Never in my entire life have I been in the situation where the engineering manager said, "well folks, localization is backed up so we've got no more code we need to write. Go home and check in next week to see if we have any work?"
The only exception I can think of might be videogames where the bottleneck is the art and then maybe the testing loop. But gaming isn't representative of software development generally at all.
The developers would have to help with the requirements and planning all the code changes. That implies a huge amount of non-coding work was done by the developers.
The backlog comes from the PM, as user needs are established.
The requirements come from a mix of PM and UX.
Obviously developers plan how to write the code. That's part of coding. Not part of product requirements.
Yes, PM's are absolutely supposed to know that much more about what the customers need. That's their job. They're constantly talking to customers; engineers are generally doing that only occasionally, if ever. They're not trying to be the "main character", but their entire job is to be the point person for integrating all the stakeholders' needs and making prioritization decisions. It's organizational needs, not ego-driven.
Sometimes products are simple and straightforward enough where you don't really need a dedicated PM, but then the lead engineer often just winds up informally taking on the same responsibility, and at some point there's enough success and complexity that it needs to become a full-time dedicated position.
I'm really curious how you've arrived at the perspective that engineers and data scientists know as much about customer needs as a PM, that they learned via channels outside of the PM? I've certainly never worked anywhere where that was the case.