alt Hacker NewsWhat 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.
Replies
> 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."
Someone: "Bartender, another drink please."
> ...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.