Maybe you both just have bad PMs, because just like good devs they should also be reviewing their work. My point was that it is more likely for PMs to review and edit a generated ticket than to have to write it all themselves which they often won't do.
I feel compelled to point out to you that this is a completely unsustainable, unsupportable, unsubstantiable claim. You have met ~0% of PMs, and of the ones you've met maybe you've experienced a non-zero percentage of their work, but statistically that's also very unlikely.
If you think you can say what most PMs do or what PMs are likely to do, then, I'm sorry, but you are not even thinking like an engineer. You're thinking, actually, a lot more like a PM to many of us.
> just like good devs
I'm so sorry, my sides just can't handle the starry-eyed nature of these takes. This is just too much for me.
To many of us this reads like you've never met people before. But who knows, maybe you live in Lake Wobegon, where all the women are strong, all the men are good-looking, and all the children are above average! If so then we're jealous, but you still should be more careful about how unrigorous your mental model is because it will make you a worse engineer.
Experience with different PMs and developers aside, the older you get in the profession the more you will hopefully realize that none of your quality effort fantasy matters. Sales happen and money rolls in independently of whether you think the PMs or the people who call themselves engineers do a "good job". Businesses thrive on sales and marketing, not engineering.
What a strange response. By your logic you've met ~0% of developers too yet I assume you can distinguish good development practices from bad. I also mentioned good PMs which by definition review and write good tickets with a clear explanation of the problem and what they want the solution to be. If personally meeting millions of people is the epistemic standard you have to know something then I'm not sure how you know anything at all.
As to your latter point, not sure why you think I think business doesn't continue on even with bad employees, of course it does and I didn't say otherwise. But that does not mean they're doing a good job, those two are orthogonal concepts.
And I'm not sure how we even got to this, the original point was that I personally as a dev can physically see PM productivity increasing with AI, even as other devs in this thread seem not to. For a competent PM, a tool that automates a detailed first draft fundamentally changes the psychology of ticket creation. If your argument is just "bad PMs will still be bad," then sure, I agree, but that doesn't really engage with how the tooling changes the workflow for everyone else.
> ...good PMs which by definition review and write good tickets with a clear explanation of the problem and what they want the solution to be
This is where the problem is — such PMs are not "good PMs...by definition". They are usually terrible PMs who start with a solution they envision and work backwards to a customer problem or two.
PMs should be able to clearly form a customers' world model, fit that into their business, and clearly articulate needs to the "builders": UX designers and software engineers.
Builders need to form a sufficiently good mental model of the needs to be able to quickly envision a few solutions with different balance between effort/cost and customer/business value, and then dive deeper on the one they agree on with a PM.
IOW, solutions are provided by the builders who understand the effort part better than the PMs.
Yes, there are PMs who can do that just as well (frequently designers/engineers who switched careers, but not only!) — yet they are far and few between!
This desire to own the solution is usually why engineers and PMs cross horns, and why many a smart person will appear a terrible PM too.
> PMs should be able to clearly form a customers' world model, fit that into their business, and clearly articulate needs to the "builders": UX designers and software engineers
What your describing fits a job I did many years ago and my role was distinct from that of the PM and my job title was Business Designer. That was in the context of software that required complex and precise specifications so may not be typical, but I do think running a project and understanding customer needs are different skills.
Depends on your "business moment" (how mature you are, how complex your product is, etc) if you want to have more specialization or less.
Most software teams benefit from getting daily access to someone who deeply empathises with customers and understands how can their challenges translate into business wins, especially when the problem space is still being explored.
Note that I am referring to product managers, and not project managers (since you bring up projects).
I was too terse, what I meant by writing good tickets is what you just said, gathering requirements, running it through UX designers and engineers then writing their collective findings into a ticket that can be picked up by an engineer with minimal questions, as they've already been answered in the ticket.
> yet I assume you can distinguish good development practices from bad
Uh. We're not talking about knowing what good is, which is completely irrelevant to anything in this thread. You made a claim without qualification about what it is more likely for PMs to do. I can't tell if you've lost the chain or are engaging in some kind of motte and bailey fallacy. Either way it's a bad sign for this conversation.
I'm going to summarize the threads so far. I hope it highlights why what you've said sounds so silly:
Someone: "I see X failing to do Y."
You: "X definitely do Y. Why would you think that X aren't doing Y? Doing Y is the obvious thing for X to do."
Someone: "I literally am seeing it happen right now."
You: "Well then those X are bad."
Someone: "Yeah, no shit. They just said as much."
You: "But most X would do Y."
Someone: "In my experience that is false."
Someone else: "Mine too."
Someone else: "Mine as well."
Someone else: "Same."
You: "The bad ones shouldn't have their jobs."
Someone: "They do though."
You: "But we can tell which ones are the bad ones."
It is X with a given attribute of "good," not all X; thinking it is all members of X is what you are missing here. Most good PMs would review tickets, by definition. That bad ones do not is irrelevant to the argument, so it doesn't matter how many someone elses notice their PMs are bad, like yeah, no shit.
Anyway this is delving into pedantry deriving from the fact that you seem to have missed what I had said above, rather than engaging with what is going on with regards to PM productivity itself. Have a good day.