"This tool 10x the productivity of software engineers"
"GREAT! That means we can fire the people who do the actual work, and replace them with MBA robots, who neither understand nor care about making a good product"
Pardon my pessimism, but in my whole career, I have never met a PM who actual did the work of driving the product vision. Most were just middlemen shuttling information between management, marketing, design, and engineering. Thinking that hiring more PMs would increase the output in the age of AI is such a childish fantasy.
I have worked with a few PMs that have been significant helps to my job but LLMs have completely destroyed my ability to work with them. "Oh I asked an AI to put together a demo for this idea and I presented it to leadership. When can you have it finished?" This is now a constant refrain, with LLMs seemingly convincing every PM I know that it is trivial to put together a reliable and maintainable system. "Oh let's just launch this and we'll fast follow with the maintainable infrastructure" and I want to blow my brains out.
The PM discipline has unfortunately maldeveloped as a place for souless MBAs, engineering degree holders who dont want to be engineers or both. Actual Product people are a small minority
Its a tragedy as its undervalued - I firmly believe apples products are significantly worse if their engineers led it. Jobs made those products
Product Management = Big picture product vision. Features and Priorities. Market trends/strategy, Voice of customer
Project Management = Day to day to execution, logistics, resources, schedules. Scheduling meetings, sending out meeting minutes etc
Program Management = Team management towards delivering business goals/product launches on schedule
Where its tricky is the differentiation between project and program management. IMO we dont really need both terms or both roles, causes uneccessary/unnatural separation of responsibilities
What actually happens in most (small) businesses is one person gets lumped with all these jobs and the business is regularly surprised they're constantly over-worked and under-delivering
I often see product and project management combined. Usually it results in mediocre execution on all fronts. The last PM I worked with didn't even understand the product.
Yes, before MBAs took over, project management was more related to actually what happens in the project, GANT charts, stuff like Microsoft Project, resourcing team, setting the overall plan what goes where, who's available, when are vacations allowed,...
Product management was interfacing with the client, understanding what is actually supposed to be built as vision, understanding UI/UX before that became a field of its own, coordinating usability sessions, and so forth.
Naturally they have common touch points like what is possible from the vision, given the actual budget and available resources, expectation management and what not.
There's even more. In games, we also use the term 'Producer' which manages the production, ie they're mostly a project manager. The design team is the product design role. Even here, the producers can and will dabble in design discussions in so far as is needed to meet timelines.
The nice thing is no one gets inflated with a manager title they think makes them the boss of every department. You get engineering lead, production lead etc.
I suspect what you are really lamenting is the effects of poor leadership that does not grant a "product manager" (which is really a misnomer) the authority and autonomy to be a "product manager".
As you imply, that role is really more a director role, not a manager role. A manager managers, a director directs, including the vision and product market fit. Most Product Managers I see do not have that authority at all, and at best are constantly having to convince "leadership" like some door-to-door salesman, rather than simply updating leadership in an advise and consent format.
As a Product Manager (not Program or Project), this has been my lived experience of the devolution of the profession.
We want PMs to understand the market, the tech, the customer, and the economic value of building a product.
We then ask them to tell us when it will be built, down to the discrete feature and function, be a technical expert for the field and engineering in the product space, ask them to convey the roadmap and timeline to customers and prospects, build reports about everything from utilization to capacity, save deals by changing timelines for “just this one feature”, participate in product marketing, and understand how their product space co-exists in the complex product offerings from a company.
“You are the Chief Product Officer for your product!” is the promise and rallying cry. That’s not an accurate description of what most PMs do and even fewer are capable of doing.
Yeah, when I read it (probably a decade ago now) it was remarkable how much of the advice was still applicable. If you (yes, you reader) haven't read it before you should do so. It's only 200 pages or so, mostly short articles so it's not a difficult read.
> Most were just middlemen shuttling information between management, marketing, design, and engineering.
well, in my experience as a developer integration between different systems with different views about how things should work is often the most challenging part of the job, so what you describe sounds like it would be difficult.
In my experience PMs often work at a very high level. How things shold work are defined in a incosistent way when we take into account all the user flows, subtelness and restrictions of other systems. So programmers end up doing a significant chunk of the work by refining the specs so that the thing actually makes sense.
I am sorry you've had only negative experiences. Most of mine with PMs were negative as well, but a good one is a dragon slayer and bottleneck unclogger. They feel not like your manager, but like your servant, listening to exactly what you need, relaying messages accurately from other teams of what they need from you, and with the big picture perspective required for you not just to fulfill the task, but do it in a long-term strategically productive way.
> never met a PM who actual did the work of driving the product vision
I have a couple times, but they didn't have an MBA. Unfortunately though if you have an incompetent C suite or board, it's hard to get anything meaningful done no matter how good the team under them is.
"I have never met an engineer who actually did the work of driving the engineering vision. Most were just middlemen shuttling data between servers, disks, clients, and CPUs."
You seem to have a deep misunderstanding of the value PM's provide. What you describe as "just" is a challenging job.
Generally, the vision is set by the founder, and it can be written down in a sentence or two. There's a ton of work trying to translate that vision into something that is coherent across engineers, customers, sales, and marketing.
Deeply flawed analogy. Engineers operate in the same organizational structure as PMs.
Also, in product feature teams it is up to the debate whether PMs provide any value, if you put engineers closer to customers. For the PM role to work, they need to convey customer requirements to product requirements. I have never seen a PM do a better job at this in comparison to just sending a TL to a video call with a client.
All the projects I have been part of where this idea took place, either were a complete failure, or eventually one engineer sacrificed themselves into a PM role to help steer the cat herd into something sensible.
Unless it is a team of senior folks with top skills, the team manages itself never works.
> Engineers operate in the same organizational structure as PMs.
I don't know what this means. Engineers are not generally spending half their time talking to management, marketing, sales, customers, and other stakeholders.
> Also, in product feature teams it is up to the debate whether PMs provide any value, if you put engineers closer to customers. For the PM role to work, they need to convey customer requirements to product requirements. I have never seen a PM do a better job at this in comparison to just sending a TL to a video call with a client.
Great, but ten different clients want ten different product requirements, that in fact contradict each other. And it takes ten hours of calls to talk to those ten customers.
Plenty of engineers could certainly do the PM job. Many PM's come from engineering. But the point is that it's far more efficient and effective to have one person doing that, and let engineers do the engineering. That's the value. As an engineer, do you want to spend 20 hours every week talking to customers and writing feature specifications and managing a backlog? Or do you want to do, you know, engineering?
Just because you could do the PM job doesn't mean that's an efficient use of your time, or what you enjoy doing.
Exactly that. Generally, engineers want to build and not go to meetings all day. The problem happens with the PMs who are supposed to be doing this work don't do it, or do it poorly. You wind up with miscommunications: missing requirements, misunderstood edge cases, etc. This pisses people off big time.
Any efficiency gains which come from cleaner organization structure are gone because of the lossy translation mechanism between a PM and Eng team. You can argue that good PMs translate requirements perfectly, but this is a rare skill and I’m just saying I’ve never seen it from someone in this role. Perceived enjoyment of one’s role is a separate topic, but not completely orthogonal. If someone just wants to code and they force them to be a PM then their personal productivity might drop. This is why I asserted in the beginning I’m talking about feature teams, where a role fit I described is more likely.
As engineering becomes less expensive with generative models I can imagine efficiency tilts even further in favor of engineers doing more PM-like work.
For the right set of requirements I can fix bugs in my system with significantly less effort, than rewriting a system which was built with wrong assumptions to begin with.
Again, wrong analogy. I don’t demand perfect analogies though. Treat this as rather charitable gesture.
I have had a bad time with PMs and UX designers not actually understanding how the product works _right now_. How can you ask for changes if you don't understand how it works currently?
Like I am saying how the current behavior of the app downright needs a big flowchart to explain and I get asked: "Add X, but keep it working for all existing users" when that means the whole freaking flowcharts needs to be redrawn from scratch. When I suggest to remove some things to make things simpler (because the users don't understand it either) I get denied because it would be too much hassle to communicate the changes.
"GREAT! That means we can fire the people who do the actual work, and replace them with MBA robots, who neither understand nor care about making a good product"
Pardon my pessimism, but in my whole career, I have never met a PM who actual did the work of driving the product vision. Most were just middlemen shuttling information between management, marketing, design, and engineering. Thinking that hiring more PMs would increase the output in the age of AI is such a childish fantasy.