[awillen]

I spent about a decade as a PM at startups, so I can definitely attest they do.

Obviously I'm biased here, but the PM role isn't just some spillover, it's work that needs to be done. Someone has to talk to stakeholders, gather and document requirements, work with customer-facing teams on launches/preparation/etc. and so forth. If the product manager isn't doing it, then engineers are doing it, which means they aren't doing engineering, which is of course not great.

The definition of a product manager (and project manager/program manager) changes from company to company, but the work of defining the thing to be built is always being done, otherwise you're not building anything. It may be done by committee, by engineers, by engineering managers, by the CEO or via some other method entirely, but it's always happening.

[tikhonj]

It seems like many companies do a poor job of separating product management from project management—I believe this is actively counter-productive and explains the issues engineers complain about.

On the one hand, we have "product" work. In an idea world, this consists of talking to users, understanding their individual problems, synthesizing this into higher-level problems for users to solve, helping design the solution and managing iterative feedback on all of these. This is real work and it's important work, at least if you care about consistently building products that actually help people!

On the other hand, we have "project" work: schedules, deadlines, tracking who does what, when... etc. This can be important depending on context, but it's as separate from "product" work as it is from engineering. It's also the most common vector for micromanagement, whether from actual managers, "stakeholders" or other roles.

"Product" considerations are certainly important for timelines and product managers are responsible for prioritizing which customer needs to address first, but exactly the same thing can be said of "engineering" considerations except engineers should prioritize which technical systems to build instead.

All of the complaints I've seen in this thread—and most complaints I've heard from engineers about "PMs"—sound like they're about project management, not product management. I imagine this is a symptom of some broader problem (unreasonable/arbitrary deadlines, micromanagement... etc), but conflating that with product management ends up making the product side of the work much harder and contributes to unnecessarily poor relationships between product management and engineering.

[dnndev]

From my experience PMs serve one true purpose well. That’s reporting to the higher ups (execs building a moat) and being a single point of contact for the devs. Everything else is red tape. Gathering requirements is hard and a PM digesting it first is never optimal.

[kodah]

I'll second that. Any time I've seen PMs involved in dev work (like requirements gathering) it's a shit show. PMs can usually have shallow conversations about software, but not deep enough to do requirements gathering.

[awillen]

I hope you have better experiences with product orgs in the future, because based on what you're saying, you have worked with some really bad ones.

Requirements gathering is the main job of the PM, and it's most definitely not technical (or at least not remotely to the level of technical knowledge required to actually write code).

For example, a PM at Twitter defined that Tweets should be 140 characters (at least in the olden days). That's a fundamental requirement of the platform, but it's related to the company's objectives, user engagement and other things that have nothing to do with writing the code. There's zero reason that engineers should have anything to do with that. Once it's been decided that Tweets are 140 characters max, then that requirement gets handed off to the engineers to actually do the development.

Obviously all oversimplified, but the point is that if you think requirements are technical, then you're probably dealing with bad PMs who aren't drawing them up particularly well. The irony is that when this comes up, it's usually because the PMs used to be engineers and don't have the experience to separate the two roles.

[dnndev]

Wow. You probably have high dev turn over rate or extremely complacent ones. Mistake many pms and execs make is assume dev is only worth they’re coding skills. We are humans who also have a non technical creative side. But the assumption is someone has already done all the high level thinking so we don’t have to.

[awillen]

It's not about assuming that devs are only worth their coding skills, it's about recognizing that their coding skills are what they're hired for (and also what they're extremely highly paid for).

It's fine that you have a non-technical creative side, but it's frankly not what you're paid for. That's true of everyone in the organization - I'm really enjoy writing and am very good at it, but I don't believe I'm being mistreated or underutilized because I'm not asked to do copywriting. That's the purview of marketing, not product.

This is even true within engineering - if you have experience working on both iOS and Android apps, but you interview for and are hired for a role on the company's iOS app team, nobody is undervaluing you because they don't also ask you to work on their Android app.

Businesses benefit from specialization and focus of their employees. Product exists to gather requirements and define specs not because dev can't, but because that's not what developers are hired to do.

[dnndev]

Alright, keep cooking up the ideas in an ivory tower and us lowely well paid devs will just code it up. Because that is how outsourcing works. Really, may as well outsource your in-house devs.

[kodah]

This view is a really poor understanding of what engineering is about. If what you are saying is true then we wouldn't be sitting here trying to encourage engineers to learn every layer of the stack. Each of those layers is significantly different and quickly falls out of the domain of a Software Engineer.