Hacker News new | ask | show | jobs
by ewjordan 2757 days ago
PM is a super heavily overloaded term that you'll run across in pretty much any company larger than small, definitely not specific to Google (disclaimer: I work at Google and don't speak for the company, but I'm brand new so my conception of the categories comes from what I've seen elsewhere). Engineers tend to raise an eyebrow at the entire job category because they're thinking of bad experiences with one particular flavor of PM (and often a particularly poor specimen at that), but that can be unfair, a lot of what they do is absolutely critical to business.

The acronym simply means either product manager, project manager, or program manager, but the responsibilities can be any/all of the following, and probably more, depending on the company:

- Full product owner, "the buck stops here" person. Many different possible titles here other than PM (usually "project manager" if that's the title), like general manager (GM), different flavors of producer, product owner (PO), VP of X, etc.

- Feature designer/owner/manager (product manager): writing specs (junior), pitching specs (mid-level), setting and selling product vision (senior), driving strategy (staff/exec, though at that level all roles start to get blurry). Decent business school grad representation here, you have to be good at strategy, negotiation, communication, and Powerpoint; having good product ideas helps a lot, too, but not if you can't sell them. A persuasive PM of this type is a force to be reckoned with and will get a lot of executive attention, which can be very good or very bad depending on whether the strategy they're into pans out or not. This is probably the type of PM the parent was talking about "armies of".

- Development director (project manager or program manager): a whip-cracker at worst or an impenetrable shitshield at best, they manage the practicalities of running a project, like project scoping, meeting and managing hard/soft deadlines, handling support, cross-team communications, processes, compliance, etc., often stepping in as an all-purpose guard against randomization so that others can focus on producing the product. Many PMs of this type ended up being the go-to folks for GDPR compliance over the past couple years, so it's not just internal process stuff that they deal with.

- Task checker: can blend into to the development director mentioned above, but at some companies this sort of PM will mainly focus on tracking tasks that are in-progress, getting estimates, watching velocity, and sending reports up the chain. Some devs find this role pointless and annoying, but it really depends on how good they are - if they're solid, they'll find a lot of ways to improve things instead of just tracking them.

- Scrum Master (project manager): Big-S Scrum is falling out of favor so it's not as fashionable to have this title anymore, but within some processes a similar role still exists as a type of project manager. In a nutshell, Scrum is a simple yet effective "People Over Process" process that consists of a bi-weekly no-laptops-allowed retrospective meeting where you get the team together to have a free-ranging discussion where everyone feels heard, so that you can all decide together whether the team should estimate engineering tasks in terms of hours or hats. You need a trained and certified Master because otherwise people new to Scrum might not know to pick hats. A more seasoned Scrum Master will also schedule a quarterly retrospective-retrospective where the team discusses a strategy for what guidelines to put in place for the next retrospective so that the team can decide on hats faster and leave more time for the less settled question about whether or not the Fibonacci sequence is the right way to count hats or if a size-based approach will make people feel better supported in their work.

- Monetization designer (product manager): mainly at game companies, PM is often a super different role, probably best described as the profitability-focused counterpart to a game designer. They focus on setting prices, managing game economies, speccing and evaluating A/B tests, inventing loot boxes, etc. Ideally PM and designer would be one and the same, and the game design would be holistic with the monetization, with a designer that has serious Excel/analytics chops and deep inspiration and sensitivity about gameplay, but that's a more rare combination than you'd think, so a lot of companies split them out.

I'm probably missing some other ways this acronym is overloaded, but I think this covers most of it.

1 comments

> You need a trained and certified Master because otherwise people new to Scrum might not know to pick hats

You certainly don't need a certified scrum master. Ideally, the scrum master should be somebody who is already in the team. A scrum master who does just that is really a project manager, and having a project manager is, IMHO, antithetical to doing scrum.

According to scrum, the scrum master is not the product owner and not a member of the dev team, but rather an objective person who does just the scrum master duties, e.g. facilitating when needed, e.g. making sure people are following scrum instead of getting distracted, not stalled by roadblocks, not taking marching orders from more than one product owner, etc. In scrum, the dev team organizes its time after priorities are set. Scrum does not want a scrum master to be a project manager - if you’ve seen that they’re just mixing unnecessary stuff into scrum and scrum is getting a bad rap for that. I don’t see a scrum master as being a full-time job unless they’re working with multiple teams, so it could easily be anyone knowledgeable outside the team who will objectively play the role.
In my experience, and from what I remember from my own training, the scrum master can very well be part of the team. Having somebody external, objective, well trained, and available exactly when the team needs him looks very good... but pretty difficult to do in practice.
This seems like a great topic for a pre-trospective meeting to discuss the process of how to structure the process to figure out the process.