undefined | Better HN

0 pointssatvikpendem1mo ago0 comments

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.

0 comments

6 comments · 2 top-level

necovek1mo ago· 3 in thread

> ...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.

graemep1mo ago

> 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.

necovek1mo ago

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).

1 more reply

satvikpendemOP1mo ago

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.

BugsJustFindMe1mo ago· 1 in thread

> 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."

satvikpendemOP1mo ago

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.

j / k navigate · click thread line to collapse

0 comments

6 comments · 2 top-level

necovek1mo ago· 3 in thread

> ...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.

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.

graemep1mo ago

> 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

necovek1mo ago

Depends on your "business moment" (how mature you are, how complex your product is, etc) if you want to have more specialization or less.

Note that I am referring to product managers, and not project managers (since you bring up projects).

1 more reply

satvikpendemOP1mo ago

BugsJustFindMe1mo ago· 1 in thread

> yet I assume you can distinguish good development practices from bad

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."

satvikpendemOP1mo ago

j / k navigate · click thread line to collapse