You still need to aggregate and contextualize these in terms of overall business and product strategy. Yes, engineers can do that too and some percentage of engineers are good at this as well - and being able to understand and formulate product strategy can be an important part of an engineering leader's skill set - but that's not that common and ultimately you need some level of specialization and you can't run an org expecting everyone to be able to do everything.

I've done both Eng and Product and most engineers don't have sufficient understanding or appreciation for the importance of product strategy. It's also important to be able communicate strategy coherently at some scale, especially if execution isn't expected to be completely top-down. At some point, engineers just have too much else to do and you need coordination.

Edit: I'll also add that engineers aren't the only ones doing work - Product Managers are expected to be able to coordinate across functions and get everyone on the same page, not everything is about just providing input to engineers.

The same reason when every year a new iPad comes out, you have a thread on Hacker News with engineers complaining they can’t run Kubernetes cluster on it even though it has the technical capability to do it.

Engineers don’t understand iPad’s product positioning, that it’s not built for them and they’re not the target market.

Want to get a portable Docker developer machine?

MacBook Air is cheaper and lighter than a 12.9 iPad + keyboard.

However, given the chance they’d be happy to ram the iPad with never ending list of features.

Companies did that before the iPad and failed, because they couldn’t say no to ideas that sound great and focus on what’s really important.

More often than not, engineers lack the people skills and business experience to know what questions to ask and how to dissect the answers they receive.

The “Mom Test” is a great example of that.

I think you’re getting bad answers here. It’s not just about talking to customers and understanding what they want, it’s about taking that and matching it against bigger business goals, budgets, and priorities plus making sure you’re not duplicating or messing up things other teams are planning plus prioritizing within all the features all the customers want. If you have time to do all that then why is the company paying you an engineering salary to write code?

You could, and probably should. The challenge is with the fad of scale. Every company wants to be the big guy hence bunch of hiring bunch of initiatives. It is common for people to subscribe to the ritual that a proper team should have some combination of PM, UI designer, UX designer, frontend, backend, devops (which is actually ops), QA, scrum master, customer success, support, data engineer, etc. Like graft different sticks together to call it a tree. OR you could grow a tree organically, naturally. Someone in your team is good at empathizing with customer? Good, do more talking with customer. Good with motivating colleagues? Good, do more motivating. It just doesn't quite fit the narrative of scale

Yes, I continually dislike why engineers are so discounted in terms of parsing customer problems... we build the damn things, we also happen to know how to use the mobile apps, web apps, and desktop apps we build. I'm likely heavily biased and bitter at this point, but I've yet to work with a good "product manager" - and I still don't know what a good one would look like or do.