[Pasanpr]

> The product management side of this equation is equally unsettled. If developers are now thinking more about what to build and why, they are doing work that used to belong to product managers

It's not clear to me why this is true. If LLMs are writing code, why are developers simply not orchestrating the completion of more features instead of moving up the stack to do product development work? Is there some implication that the existence of LLMs also enables developers to run user studies, evaluate business metrics and decide on strategy?

Additionally, if PMs can use LLMs to increase velocity in their work why not focus on all the things that used to be deprioritized? Why, with the freed up time, is generating code the best outcome?

These questions likely have different answers depending on organization size but I'm not sure I understand why orgs wouldn't just do more work in this scenario instead of blending responsibilities. It's not like there's infinite mental bandwidth just because an LLM is generating the code

[roncesvalles]

Arguably the PM role only exists because SWEs don't want to do PM work, and the industry acquiesced to this because SWEs are in very short supply - if you could hire a layperson (sorry) to take a few hours of non-technical work off a SWE's plate, it is worth it.

In a (hypothetical; not quite there yet) world where SWEs are in surplus, there is no reason to have PMs.

The really eye-popping efficiency gains from LLM coding won't come from doing the coding faster but from consolidating the PM, SWE, and QA/SDET roles under the same person. Then you'll start seeing startup/indie level productivity-per-person inside large organizations. Imagine Google is like 50,000 Pieter Levels.

[manphone]

The concept of a large organization doesn’t even make sense in this model. How do you make decisions? How do you coordinate? What is Google when you have 50,000 individual silos?

[mbrumlow]

Decisions are less costly. When a swe can take 4 days to do what would have cost 6 months, the math of making sure you are doing the right thing before executing goes away.

[manphone]

That has little to do with building code and a lot to do with customers and releases and operations - giant companies don’t just magically demo software to people.

There’s so many layers today that can’t exist if this is the way forward.

[wreath]

PMs do different things in different organizations.

In my last job, PMs were responsible for identifying problems that were worth solving and align with the overall company vision and plans within the owned domain, and design+engineering decided how to solve those problems and what to build. Of course with collaboration w/ the PMs (and EMs).

The job before that, PMs wrote jira tickets and nagged engineering when tickets will be delivered. The "what problems to solve and what to build" questions came straight from CEO/CTO.

[kingkongjaffa]

I’m not saying you’re wrong but as a senior PM, the engineers I work with see about 10-20% of what I actually do in a week, so in general engineers are not a good judge of the utility of product management.

[drivebyhooting]

Because feature development speed wasn’t the bottleneck a lot of times.