The problem is, it's hard to measure how good a PM is, even harder than for engineers. The instinct is to use product KPI's to do so, but especially at BigTech company, distribution advantages and traction of previous products will be the dominant factor here, and the best way of raising many product KPI's are actually user-hostile. Someone who has been a successful FAANG engineer who goes to a startup might lean towards over-engineering, but at least they should be sharp on the fundamentals. Someone who has been a successful FAANG PM might actually have no idea how to get PMF.
> Here's what to do instead: Find your most socially competent engineer, and have them talk to users a couple times a month
This is actually a great idea, but what will happen is this socially competent engineer will soon have a new full-time job gathering those insights, coalescing them into actionable product changes, persuading the rest of the org to adopt those changes, and making sure the original user insights make it into the product. Voila: you've re-invented product management.
But I actually think it's good to source PM's from people who've been engineers for a few years. PM's used to come from a technical background; Google famously gave entry-level coding tests to PM's well into the '10s. I dunno when it became more fashionable to hire MBA's and consultants into this role, but it may have been a mistake.
This is a names vs. structure thing. For a moment, taboo the term product manager.
What I'm suggesting is a low risk way to see if an engineer has an aptitude for aligning the roadmap with what the users want. If they aren't great at it, they can go back to engineering. We also know for sure that they are technically competent since they are currently working as an engineer, no risk there.
The conventional wisdom (bad meme) is going to the labor market with a search term for people who claim to know what the users want, any user, any problem, doesn't matter. These people are usually incompetent and have never written software. Then hiring 1 and potentially more of the people that respond to the shibboleth.
If you want the first case, then you can't say "product manager" because people will automatically do the second case.
I agree your assessment about the value of good PMs. The issue, in my experience, is that only about 20% (at most) are actually good. 60% are fine and can be successful with the right Design and Engingeering partners. And 20% should just be replaced by AI now so we can put the proper guardrails around their opinions and not be misled by their charisma or whatever other human traits enabled them to get hired into a job they are utterly unqualified for.
But not lately. Lately it’s been people who have very little relevant domain expertise, zero interest in putting in the time to develop said expertise beyond just cataloguing and regurgitating feedback from the customers they like most on a personal level, and seem to mostly have only been selected for the position because they are really good at office politics.
But I think it’s not entirely their fault. What I’ve also noticed is that, when I was on teams with really elective product managers, we also had a full time project manager. That possibly freed up a lot of the product manager’s time. One person to be good at the tactical so the other can be good at the strategic.
Since project managers have become passé, though, I think the product managers are just stretched too thin. Which sets up bad incentive structures: it’s impossible to actually do the job well anymore, so of course the only ones who survive are the office politicians who are really good at gladhanding the right people and shifting blame when things don’t go well.
That good taste doesn't translate between domains very often. Good taste for developer tools doesn't mean good taste for a video game inventory screen. And that's the crux of the problem. There is a segment of the labor market calling themselves "product manager" who act like good taste is domain independent, and spread lies about their importance to the success of every business. What's worse is that otherwise smart people (founders, executives) fall for it because they think hiring them is what they are supposed to do.
Over time, as more and more people realized that PM is a side door into big companies with lots of money, "Product Manager" became an imposter role like "Scrum Master". Now product orgs are pretty much synonymous with incompetence.
Taste on the other hand is about creating an overall feeling from a product. It's holistic and about coherence, where intuition is more bottom-up problem solving. Tasteful decisions are those that use restraint, that strike a particular tone, that say 'no' when others might say 'yes'. It's a lot more magical, and a lot rarer.
Both taste and intuition are ultimately about judgment, which is why they're often confused for one another. The difference is they approach problems from the opposite side; taste from above, intuition from below.
I agree with your assessment otherwise, PM can be a real smoke screen especially across domain and company stage.
That’s definitely one of the biggest problems with product management. The delusion that you can be an expert at generic “product”.
We used to have subject matter experts who worked with engineers. That made sense to me.
The counter to that is "the proportion of 'really good engineers' to product engineering teams has got to be in the single digits," and I would agree with that, as well.
The problem is what is incentivized to be built - most teams are working on "number go up?" revenue or engagement as a proxy to revenue "problems." Not "is this a good product that people actively enjoy using?" problems.
Just your typical late-stage capitalism shit.
In most of my engineering jobs, the Product Managers were much closer to our users than the engineers.
Good product managers are very valuable. There are a lot of bad ones carrying the product manager title because it was viewed as the easy way to get a job in tech without having to know how to program, but smart companies are getting better at filtering them out.
> Find your most socially competent engineer, and have them talk to users a couple times a month
Every single time I've seen this tried, it turns into a situation where one or two highly vocal customers capture the engineering team's direction and steer the product toward their personal needs. It's the same thing that happens when the sales people start feeding requests from their customers into the roadmap.
For example, I had one product manager who made themselves irrelevant because they wouldn't work with sales. The company needed to sell the product to pay us, and sales talked with potential buyers about what might swing their purchase decision and what they would pay extra for. Since the PM only talked to users and ignored sales when doing product design and product roadmaps, the way sales input got integrated into product development is that we frequently got top-down directives from management to prioritize one-off requests from sales over the roadmap. Needless to say, this didn't lead to a cohesive and easy-to-understand product.
Before I saw that PM failing, I hadn't thought about the relationship between product and sales.
> Find your most socially competent engineer,
These usually get promoted to product management anyway, so this isn't a new thought.
It's not.
Engineers are having more and more minutia and busy work taken off their plate, now done by AI. That allows them to be heads up more often, more of their cognitive capacity is directed towards strategy, design, quality.
Meanwhile, users are building more and more of their own tools in house. Why pay someone when you can vibe code a working solution in a few minutes?
So product managers are getting squeezed out by smarter people below them moving into their cognitive space and being better at solving the problems they were supposed to be solving. And users moving into their space by taking low hanging fruit away from them. No more month long discussions about where to put the chart and what color it should be. The user made their own dashboard and it calls into the API. What API? The one the PM doesn't understand and a single engineer maintains with the help of several LLMs.
If it's simple and easy: the user took it over, if it's complex: it's going to the smartest person in the room. That has never been the PM.
Yet the PM always has the last say on what goes in the product, NOT the engineer. Funny how that works...
None of your conclusions are consistent with experience (interviewed 900+ SaaS management teams)
I agree completely that these are the important qualifications to be setting direction for a product.
> Find your most socially competent engineer, and have them talk to users a couple times a month.
This doesn't necessarily follow from the above, but in Anthropic's case specifically, where the users are software engineers, it probably would have worked better than whatever they have going on now.
In general, it's probably better to have domain experts doing product management, as opposed to someone who is trained in product management.
Unfortunately, he’s already two of our SEs and the CTO and we’re starting to run low on coders.
What are we going to do when we need a customer success manager or a profserv team?