There's a lot you can legitimately blame PMs for, but promising features that don't yet exist is essentially their job definition. A good PM will allow for uncertainty and flexibility, but at the end of the day, to have some sort of product roadmap, even in the most agile of environments, they have to say things like "at that stage we'll have functionality x, so our product will enable users to y, so that we'll better compete across z"
I think there's also an element here of... when you work a long time on something, you tend to become emotionally attached to it, and you want it to be good and work well. Time to fix technical debt and work on making the product good is often implicitly waved as a carrot ahead of people who care about that sort of thing. "We can prioritize that after we ship $FEATURE."
This then feels like a betrayal on an emotional level when instead of a nice block of time to fix technical debt, instead the priority becomes $NEXT_FEATURE (the "features that don't exist yet.")
Management that can successfully keep the treadmill running ships features faster, so it keeps happening, and can contribute to burnout as (what felt like) implicit promises are repeatedly broken for the good of the business at the expense of the product.
Of course. Obviously a PM who isn't talking to the devs isn't doing their job.
But having said that, a PM is the person who owns the roadmap, and after talking to the devs, they may at times choose a course of action that goes against the devs' preferences (assuming the devs even have a consensus), because the PM has a lot of additional considerations. There are for example situations when the choice is either to crunch, take on massive technical debt, and still arrive at a feature with a somewhat lower quality than we'd like, or to lose a big business opportunity and possibly to have to let people go.
Most PMs that I've worked with are actually not that good at their job, and some were definitely detrimental to the org, but the good ones, who have an extensive understanding of the business domain and the technical situation, and have a clear vision (and strong opinions held loosely), are worth their weight in gold. And seeing how I did a short stint in a product role and don't want to go back to that sort of responsibility, I am grateful for the ones who are willing to take this on, and to take ownership when things don't go according to plan (and they usually don't, even in the best orgs).
PMs are an invention of PHBs that sat in too many introductions to agile from management consulting firms.
Actual agile gets rid of them along with all the other cruft. PM as a title is fundamentally a jobs program for people who couldn’t hack it as programmers, or are nepo hires. You could argue a North Star like a product manager performs useful business alignment. But in 12 years across several companies I haven’t met a single project manager that is more than a professional problem manufacturer with selective hearing that miraculously ignores expert engineering opinion.
>> promising features that don't yet exist is essentially their job definition
Agree. I think he meant (at least my reality) they promise features that does not exist (ok) AND are impossible to implement in the promised time (or at all).