I forced every engineer to take sales calls and they rewrote our platform

> At the end of it, they were sketching a completely different architecture without my "PMing". Because they finally understood who was actually using our product.

I cannot help but read this whole experience as: “We forced an engineer to take sales calls and we found out that the issue was that our PMs are doing a terrible job communicating between customer and engineering, and our DevOps engineer is more capable/actionable at turning customer needs into working solutions.”

Or engineers are little bit full of themselves and know better how user should experience the product. If user is "holding the product wrong" it is a problem of a user and not a problem of stupid design, created by a person who knows in which order these buttons should be pressed. People around Desktop Linux could write a complete book about dismissing user's complaints.

The moment you have stubborn engineer who knows better than PM and user, it is really difficult to get anywhere. However if you will put such engineer into line of fire from a users that's suddenly not engineer's friendly PM trying to tell the engineer that this is wrong, these are frustrated people who would like to skin engineer alive as a punishment for using his "awesome" creations! That induces fear, but absolutely also crushes his ego, because somebody is berating product of engineer's genius like it would be a retarded hamster.

From my perspective, it is not about showing that PM is an idiot, it is about humbling your engineers. Their ego will grow again and this exercise will need to be repeated.

Assuming your PM is for product manager not project manager.

I would think the engineers usually get their kick out of making things fast or easy to maintain. If you have a product manager and the customers hate the product, how is that the engineers fault?

I've built a couple useless features that I wouldn't want to use and couldn't explain how to use. But if you have a product person, they get to design is BECAUSE they're in the line of fire.

That's a comfortable position to be in as an engineer, except that you sometimes have to build things more than once.

There are two separate problems, and they aren't mutually exclusive, but this post seems to be specifically about the latter case (if one believes the story, of course):

- The PM(s) are bad at listening to customers or turning customer feedback into a focused set of requirements.

- The engineer(s) are bad at following the requirements or going back to the PM(s) when the requirements aren't clear.

In the first the PM(s) can just lack understanding of what the product does or interest in why customers use it, can be overconfident in their ability to "see what the customer actually wants", or just actually want to build something else but are assigned to this product.

In the second, the engineer(s) can just lack understanding of what the product does or interest in why customers use it, can be overconfident in their ability to "see what the customer actually wants", or just actually want to build something else but are assigned to this product.

In either case, it results in the product not fitting the customer needs. I think there are better ways to solve either gap than just having the engineers join sales calls to hope it works out, but I suppose any approach is better than letting the problem sit.

Lots of product managers have never studied product development. You'll find philosophers, designers, physicists, even musicians in the role. Many have great people skills, but little understanding of customer service, building products, or scaling a business. And funnily enough, those are all real careers and degrees.

The result, which you often see in companies with 300+ employees, is that engineers have far more experience building products than their PMs, what engineers usually lack is knowledge of the customer and their pain points, and a roadmap that leads to successful outcomes. In other words: a real product manager.

It's not enough for PMs to throw around cliches like "I represent the customer" or "the product has to be built around customer needs" if they don't understand how to actually build and ship software.

Last year I dug into this and found it's not unusual. Many software companies hire smart people as CPO, Product Director, or Head of Product because they have leadership skills, people skills, and some knowledge of the industry. But most have little to no background in business, marketing, economics, or product development. Some companies go even further and promote an engineer with project management experience to Head of Product. And, of course, people in those roles tend to hire others who look like them, with similar experience. One day their CEO realiseS their product isn't selling, customers aren't happy, or engineers are left to figure out what to build.

To put it in perspective, imagine a company making a lawyer their Engineering Manager and asking them to build an engineering team. What are the chances they'd do better than a computer scientist or an actual engineer? Pretty slim. Sure, there are exceptions, but what usually happens is their engineers aren't motivated and complain about the lack of coaching, vision, purpose, and the poor quality of their tools, processes, code, and work environment.

Bottom line: companies need to audit product leadership roles as a priority and figure out who's really in charge of the product. Run an internal survey to check whether your CPO, Director, Head of Product, and Product Managers have studied business or have actual expertise in it. If not, you're in trouble.

I support every single word of this comment. Good product managers are unicorn masters of discovery and delivery who are so rare that they climb up quickly in corporate hierarchy to strategic positions leaving holes in product operations. I have seen products running A/B tests without understanding how they work, designing UI sketches without any knowledge of UX, pushing features to roadmap based on a feedback of a single user etc. Maybe it makes more sense to abandon this role instead of fixing it and split the required skills between UX designers, business analysts, marketers, engineering and project managers etc.