[solatic]

In a recession, where companies give up on the efficacy of their marketing and sales operations, a lot of those positions get cut. When a company merges or gets acquired (often, to improve financial metrics), that enables the company to cut a lot of marketing and sales positions.

Product is seen as a position that is seen as a bit more stable. The company still sells the product, current and potential users can still be interviewed, feature work still needs to be prioritized for developers, and various executives are loath to take over a position whose workload often feels like a lot of drudgery. So PMs are less likely to get laid off.

With that said, good PMs are worth their weight in gold, and most others are an anchor. When lots of people take some courses and switch to PM positions, well, Product suffers. Smart executives understand this and resist it. Unfortunately, most executives are not so smart... do the math.

[whatever1]

PMs are such a hit or miss. I have not seen an average PM in my career. They either are incredibly talented and they can move mountains out of the way of making a great product, or they are a complete black hole of resources focusing on gantt charts and project updates.

[MattPalmer1086]

Are you talking about product managers or project managers?

[hn_throwaway_99]

That's kind of the issue at heart. Most product management includes at least some aspects of project management.

The core problem I've seen is when the product manager sees the project management aspects of their role as their primary or only job. This is unfortunately incredibly common.

[thunkshift1]

And what is the difference in job function between those two?

[MattPalmer1086]

Well, the clue is in their names. Project managers manage projects, which could be anything. They juggle resources and timelines.

Product managers are responsible for the direction of a product. They have to figure out what customers want or need and ensure that the product being built satisfies some of those needs and is competitive in the market place.

There may be some project management in product management, but there is no product management in project management.

[pg_1234]

Project Managers oversee the building of new stuff.

... then Product Managers move in and squat.

[ian0]

|| When lots of people take some courses and switch to PM positions, well, Product suffers

This mirrors what happened with the rise of coding bootcamps. Another similarity between the two is the whole framework marketing machine.

I think its more related to tech becoming mainstream. A long time ago a lot of the people you met had a genuine interest in computing and then sort of fell into it as a career. Nowadays its fairly well plotted out like other fields, with all the baggage that comes along with that.

[ssag2]

As someone interested in moving into PM, what are some of the things PMs do that make them worth their weight in gold?

[solatic]

Mostly covered elsewhere in this page, but in my opinion, gold PMs understand, on a deep level, the intersection between user needs, the marketplace, company strategy, and the engineering resources available; don't take shit from any of them, and can balance each of them.

1. User needs: this means not just talking to users, but seeing how users use your product and competing products. You understand what users are actually trying to do. Not taking shit from users means, just because a user tells you they wish something existed, therefore it gets written down as a feature request. Maybe something else would be better, maybe the user is a sourpuss who is giving you crap because they're having a bad day. Gold PMs read the room. Allowing every user direct write access to the feature request lists is design-by-committee and guaranteed to result in crap. Gold PMs know how to filter out everything but the most essential.

2. Marketplace: Gold PMs understand what other products are in the market. They understand that the market chooses between different products in the market, and therefore, what's important is how to differentiate the product within the market. Good PMs understand the difference between a feature that other products have that needs to be built in their product (i.e. table-stakes/non-negotiable, like SSO in Enterprise products), and not taking shit by adding features just because other products have them already (the building of which won't help differentiate their product in the market).

3. Company strategy: Gold PMs listen to executives who say which market segments the company is trying to reach so that they can reach out to the relevant users and choose relevant features, and not run after irrelevant segments that don't fit into the strategy. Not taking shit means knowing when to push back when executives pick a market segment that isn't going to be interested in the product (happens more often than you'd think), and making sure that the team has the budget and resources to go after (i.e. talk to users in) that market segment.

4. Engineering resources: Gold PMs understand, roughly, the skills of the engineers and developers who are available to them to build the features. They know what feature requests are feasible, approximately how much time it takes to build them, and when they need to back off and let engineers pay down technical debt. Not taking shit from engineering includes concerns like: not allowing Engineering to build feature work that they feel is really important but hasn't been through the Product process (market research, UX, etc.), pushing back when Engineering says something will take much longer than you think (i.e. is it a misunderstanding over scope?), pushing back when Engineering releases half-assed work (i.e. almost like QA in terms of exploring edge cases in the Product, and making sure those are addressed).

Gold PMs are valuable to Engineering when they distill user needs + marketplace + company strategy into a very simple list of the top 3 things that need to built in the next two weeks, and can clearly explain (including showing their work) why those 3 things are at the top. They are anchors when those top 3 things are clearly bullshit, when they don't even bring you a list of prioritized features to build, when their presence is required to get anything (even non-feature work) done, when they push paper for the sake of pushing paper, when they get in-between you and necessary externally-sourced information (design files, customer feedback, bug reports, etc.).

[tarsinge]

How is it possible to be efficient in these points without a strong engineering background, especially if you are innovating? Discussions in points 1, 2 and 3 will only be note taking if you cannot concretely envision what the implementation could be and need to ask engineering everything that is not a generic or superficial feature. The non-technical PM I have worked with always turned up to be project managers drowning the engineering and design teams in meetings and processes.

[xboxnolifes]

Why do points 1 and 2 require strong engineering background? Knowing a feature is important or what features users actually want is not related to how hard it is to implement or how long it will take. If you have a good relationship with your engineers, you should be able to talk to them and trust their input.

Point 4 is the one that really sounds like needing engineering background.