This is honestly a great point, but it does get obscured a bit because it comes off as hackers being cranky that they have to answer to a business in order to get paid. There is an analogy in government tech where my wife works. They have a role called "systems engineer," but it isn't what that normally means in software. It's supposed to be a person with intricate domain knowledge of multiple components of interacting defense and intelligence systems, something like understanding at least a bit of the software used to task satellites, perform ground processing of images, some knowledge of the satellites themselves, the crypto hardware at the ground stations. Think of being a member of the IETF or something where you're supposed to have some idea of how the entire Internet works, not just how to write software.

But somewhere along the way it became just a job title and they somehow manage to hire people fresh out of college to do this thing, which makes no sense and leaves them totally out of their depth, but forces them to do something to attempt to demonstrate to higher management there's a point to keeping them there so they can still have jobs. I don't blame the people in these positions at all. It's the blind leadership that has no understanding of what the role is supposed to be, that realistically you can't just put out a job req for this, it has to be someone who has actually worked already as part of these projects.

At least I think this is what you're saying, that ideally product managers should be people who were engineers at some point and understands how the product they're managing works, as well as the customer needs, not because they majored in business but because they've actually worked with that customer and have some experience meeting those needs.

> I think this is what you're saying, that ideally product managers should be people who were engineers at some point and understands how the product they're managing works, as well as the customer needs.

It takes knowledge of the problem and solution domain to maintain a vision and lead a team. But in this case, the scarcity is with the problem domain. People who really understand what problem the product solves, and the best way to think about it, especially when their view leads the industry, are very hard to find. Too hard to build an organization around the implicit assumption of finding them.

My advice for organization building is not to have product managers, or even allow the term into your company. There are people with good product taste, they occur at some rate, and when you find them doing other things like writing software or supporting users you nudge them in the direction of curating a product vision and controlling resources to execute on it. Framed that way, the importance and hardness of the problem are very clear.