[yalogin]

I got stuck on the first one "Product Manager". Do the newer companies have this role? I mean, for the companies that are consumer facing and not enterprise oriented. IMO, this is a spillover role from the enterprise heavy 90s/2000s into today. Am I wrong?

[nonameiguess]

The bulk of software that is actually making money and not just trying to convince investors to get in early enough to get rich off of other investors before enough people figure out they're never going to monetize are still selling to enterprise customers. For every 30 people figuring out how to profit off a user-facing web app, there are 3000 chugging away at basic J2EE or maybe Spring Boot now for some proprietary backend business system for a Fortune 500 or the government that no member of the public will ever see. This sort of work seems to have become invisible to web-based developer communities like Hacker News, but they're still there. The need and the demand has only grown.

Granted, I don't know that it means there needs to be dedicated Product Manager roles. Granted, I as an engineer don't particularly want to deal with expectation management, scheduling, and capacity planning, and am perfectly happy to let someone else do it, but most of my work has been for the military and intelligence community and I think we have a much bigger problem there that org structure at the actual product development level can't solve. Our "customer" is an acquisition office, not the actual users of our products, and we're not legally allowed by the structure of contract law to have any direct contact with the actual users. So we cargo cult the hell out of basic agile principles that promise a more responsive and user-oriented process, but we can't legally implement that process the way it is actually supposed to be implemented. Instead of being directly accountable to our users, we're instead accountable to career bureaucrats who are more concerned about adding bullet points to their resumes while taking minimal risk than the actual needs and use cases of analysts and warfighters.

[codingdave]

All software companies have someone fulfilling this role, it just isn't always a full-time job with that title. Somebody is deciding what the product will do. In tiny companies, it may be the founders. As it grows, that may filter down to other teams. Or, if nobody takes on the role, the engineers will take it by default because they are literally the ones who choose what the product does as they write it.

As your company grows, it easily becomes a full-time job, if not a full team. It has nothing to do with 'Project Managers' from the 90s. It actually is not about project management at all in many cases... the engineering teams run their own processes. But it is about making sure they are solving the right problems, at the right time, in the right way. (Meaning, correct consumer experience... Product Managers should not be telling the engineers what to do on the technical side.)

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

[warkdarrior]

Any company that has more than one product or more than one flavor of a product have product managers.

[gowld]

Run a web search for "product manager jobs" or "$STARTUP product manager jobs" and try to find one that doesn't match.

[arcturus17]

How did you come to such a conclusion?