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.
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.
... then Product Managers move in and squat.
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.
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.
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.).
Point 4 is the one that really sounds like needing engineering background.
Don't get me wrong, I think product management is actually the hardest job in tech because it can straddle so many different areas: design, marketing, data analysis, customer relationships, project management, etc. etc. I still think great project managers are worth their weight in gold.
That said, I think great product managers are extremely rare, and many (most?) product managers are neutral or negative value adds. Reasons being:
1. Product managers need to be incredibly detail oriented. They should know every in-and-out, every edge condition of their product. I've found this level of detail-oriented-ness to be very rare. It can be one of the biggest causes of friction between engineering and product.
2. The best product managers have a good, basically innate sense of products and features that will work for users. This skill is incredibly rare.
3. I think most importantly, many product managers see themselves more as project managers: keep Jira boards up to date, coordinate with stakeholders, schedule meetings, etc. These types of product managers can do lots of work to look busy, but I'm usually like "yeah, I can schedule my own meetings."
So my point is I'm extremely skeptical of people that can do a 1-3 month boot camp and be good product managers (though, that said, I think the same thing of code bootcamps). I do think there are some "pipelines" to becoming product managers that should be strengthened, as I've seen some very good product managers come from being very detail-oriented and motivated QA or customer service folks.
But in general, I think the time of hoards of useless product managers is coming to an end.
I've seen lots of product managers who basically just "facilitate" between stakeholders (e.g. between engineering, business execs, and customers) but don't actually add much value to the primary job of product management, which should be defining, in detail, how the product should actually work.
Essentially, non technical people who want to insert themselves into technical projects account for many of the new PMs we see, at least in consulting, nowadays.
I think that it can be a mixed bag, especially depending on the size of your team and what you're trying to accomplish....and just as important - what role your PM actually fills on a day-to-day basis. PM has evolved to be a very vague description of many different needs a business actually has (some tech, some not) that nobody is specifically doing already.
My own experience as a PM - I worked at an education software startup. I was on a very small team with 3 engineers, a CTO, an operations person, and a CEO who was more of a market development / bizdev type of person. I was made PM almost by default. There was nobody regularly engaging with our users on a regular basis, nobody from our team actually using our product, nobody making sure we were building what we (and our customers) wanted to build, and nobody that understood the competition or the market we were serving. That's the PM role I filled - part tech, part biz, part UX, part design. My main value-add was that I knew the industry (and niche within the industry) well, and had personal experience at both sides of the product from a usecase prespective well before we even built it.
At other companies, this could be a much more limited role, or much greater role depending on the needs of the company.
I'm not super technical but have done coding bootcamps, know the right tech questions to ask, understand what engineers are capable of and how long things take; and most importantly - how to tell non-technical people to stop bothering the technical people. I do think PMs should be able to code, or at least know enough to ask questions, call out BS, know what's possible and what isn't, and how to get non-technical management to stop micro-managing the software development lifecycle. People skills are important too.
As I said earlier, PM has evolved into a catch-all that nobody can quite describe because it fills a slightly different niche at every different organization. The problem just gets worse when you hire fresh grads or people with 1-2 years of consulting experience who don't have any background whatsoever.
> The problem just gets worse when you hire fresh grads or people with 1-2 years of consulting experience who don't have any background whatsoever.
Yeah these are the culprits of the trend and the source of most rubbish PMs. The undefined is where these waste-chameleons lurk.
I highly suggest reading the aforementioned book (or even listening to the audio book).
That works fine until it stops working, and then it works horribly, because engineers have asserted themselves as antagonistic product owners: I know what customers want! And they just plain don't. Things can go completely insane. It boggles my mind how badly some otherwise competent folks can botch this.
I didn't even realize how important this role was until I was working with people who clearly had no business asserting themselves into it, and I'd rather have someone less technical doing it than an engineer who is awful at it.
This hit home with me, I’ve seen some of the smartest engineers fall into this trap. They seem to believe their great engineering skills translate directly to product management.
It can be one of the worst possible outcomes for a product and company
Rather, the point is that it's an extraordinarily critical function and not something to assume everyone is just good at because they say so or because they're "smart" in some sense.
The result is that Product Manager is mostly an imposter role. It's created by charismatic "business" people to insert themselves into an area of value creation. They are attracted to the light and heat that tech has been giving off. Once they are in, they promulgate the idea that the role is absolutely necessary for success and create more demand for hiring similar imposter roles. The necessity of these roles is now part of the conventional wisdom.
As an imposter role, anyone well liked, with enough confidence can pivot into it. Areas with clear metrics for success like demand generation have seen cuts. But the success of a product manager is more difficult to quantify, and so it's a good place to jump to.
Can hardly see an argument of everyone pivoting based on loudness and charisma. People would usually fail here on analytics, design or even technical questions of data flows.
Contrast that to metrics around demand generation. If you have a sales team, they can work "how did you hear about us" into the conversation. Maybe you are tracking where redirects to the website come from. It's much easier for a marketer to prove that 100 prospects got in touch as a result of something they did, than for a product manager to prove the product is better because of them.
Exactly this! My biggest tool as a PM was the ability to confidently communicate with our users and tell them "thanks for that suggestion, it's a good idea, but no we won't build that, and here's why" in a collaborative and positive manner so that our users will continue to use our product but understand why we are building what we are building, and why we have a very specific goal in mind.
PMs should almost work backwards - they need to have a product's goal and desired outcome communicated effectively to everyone from the get-to, and then understand what needs to be done from there. They should know enough about the business needs and market needs to be able to voice their opinion early on about what needs to get built, how it needs to get built, and why it needs to get built...and then leave the rest up to the technical people, with somewhat consistent feedback from users, stakeholders, and the market.
The best product managers are engineers who care about what customers think, and have enough soft skills to talk to them. Even selecting from that pool, it's likely they will add less value as a PM vs as an engineer. In the case of hiring internally, at least they can fallback to being an engineer. Compare that to an imposter from the open market with poor domain knowledge, and no technical skills.
With tech seeing layoffs and a drive for efficiency, right now we're definitely seeing the number of PM spots decrease. Also, in times of cost cutting, you can drive the ratio of engineers to PMs up - I just listened to Zuckerberg on Lex Friedman, and he said they had a ratio of ~3 reports to one manager before they started layoffs, and he wanted that to more than double. He was talking more about engineering management there, but I have to imagine the PM ratio would be similar.
Paying for someone who can increase the efficiency of a bunch of other highly paid people is a sound investment. Not that this happens often in reality! A shit show is a shit show even with a paid cat-herder. But it can work very well given the right circumstances.
Also, PM requires real skills too, as you can see from a lot of the comments here. Unfortunately most PMs don’t have those skills, so I don’t blame people who don’t know that.
But, it's a result of where the money lies. And has been done in industries and periods past. Tech realized that every company needs to be honing their product strategy, it's not cool that your tech is awesome, but you need sell it. I think this group structure is more useful than the legacy agile/ with a scrum master model. PMs can steer the ship and handle all the roles of a business analyst, scrum master, and to some degree maybe even merge with an engineering manager (might be going towards that), but perhaps it was a good idea to separate engineering and product/business decisions.
The best product managers I know seem to have a natural talent for it. And plenty of them found their way into it by accident. Maybe they were working in another part of the business, but realized that they had a knack for understanding how the product could be better. Maybe someone told them that they would be good at it.
My take on it is that yes, lots of people want to be involved in tech, but don’t know how to code. Product management is a Way to do that that’s accessible to non-engineers. Some people will try it out and find that they have strong abilities at it, and many will fail at it. But I think it is seen as a desirable job.
That said, I think it’s an incredibly hard job as well. You have to deal with people above you constantly pushing on deadlines, you have to stay super on top of things, and you won’t succeed, unless you earn the respect of the engineers you work with. It can be very demanding. Most people don’t seem to have the skill set for it. And if you are in a company with a bad culture, it can be a very thankless job.
On the other hand I've seen atrocious data-oriented PMs which get so hyper-focused on metrics that completely lose the sense of taste, their vision is completely clouded by whatever KPIs they want to reach, lacking the ability to re-assess those metrics if they get in the way of making a good product. Some products don't see a change in metrics easily, it might accrue over time and only a strong, enduring vision can get business people over that hump.
My background is very technical, but it's in the traditional IT industry and I doubt anyone would trust me to start writing code even though that's what I've been doing for the past 2 years. So I figured with my project management experience I can jump more easily to product management.
From my perspective it does seem like there are still a lot of roles open for product people, so I can understand why it seems like a lot of people are trying to jump.
Fortunately, all are willing to learn and work together to figure it out.
In my view the most practical thing to do, if you can swing it, is to have a subject matter expert who's just a general resource for everybody. They help product make decisions about what to build, marketing with how to message and sales with closing the deals. We just brought somebody on in this capacity at my company, which is a startup in a highly regulated industry, and it's honestly just a dream setup for me as a PM. Things that would take me a lot of research or experimentation to figure out instead get answered in a 30 minute call.
Admittedly, I haven’t tried too hard because the freelance work is very comfortable, but every time Ive applied for a PM role it’s been a total bust.
It's very easy to be a product manager in times like these, it's not easy being one where opportunity is rare and hard to find.
I'm told I am one. Because I am the manager of a piece of software the CTO has passed on to me.
Besides leading the develoment, what should I do?
Why did I read the comments section...
And they get paid more to do, so who's really winning here?
Done well, it’s essential to creating products people love. Unfortunately, it’s easy to do poorly. Done poorly, it looks like bad project management: shuffling Gantt charts and micromanaging engineers.
A lot of people here are describing a position I would just call project management with a bit of technical management thrown in.
Doing the presentations and customer feedback on new features? Good thing. (Pls no I wanna die I'm a smol bean introvert dev it's the cost of knowing the Rule of Five I have no brain cells left to communicate I wanna die)