Exactly as I suggested, you've tossed non-coding activities into the coding category. Planning is not writing code.

Imagine an architect who never writes a line of code. Under your accounting, they're doing coding, because it's the planning for code.

You seem to be having a different conversation.

The root comment was about coding vs "design, quality assurance and debugging, art assets, localizations", etc.

Not coding vs planning coding. It's the same way the art department both plans the art and draws it.

The root conversation began with:

> Coding as such is seldom a bottleneck to begin with. How many times have you been in a conversation along the lines of "we have every detail of the product figured out, but we need another month for the coders to finish writing the code"?

And you quoted "how many times" contradicting it.

Yes, the art department plans the art and draws it, but an AI tool for generating art could only help with the actual drawing. The possible productivity improvement directly relates to the portion spend actually making art.

Your department or job-role style view of things doesn't make sense for this conversation.

I'd hate to work at a place where the backlog comes from the PM and the requirements come from a mix of PM and UX. Do you really think your PMs know that much more than your Engineers, Data Scientists, Ops/Business, etc.? This just sounds like something the type of PMs most of us hate, the type who insist on being the main character, would say.

I'm genuinely confused by your comment.

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.