Engineers' views on Product Managers

In the early days of my career, I had the privilege to work with an amazing PM. He had a Bachelor of Science in Astro Physics from CalTech and the world record for solving Rubik's cube blindfolded back in 2006.

I used to build games back then and he was my product manager. He had absolute clarity of thought when it came to writing PRDs. He used to work out all possible scenarios in his mind how a user would use the feature and then write down what should happen in each of the scenarios (including but not limited to actions to be taken on back button press, home button press, popup closures, analytics event parameters, etc.) The specs were so clear that it would be difficult to find a spelling, grammatical, or semantic mistake let alone a logical error in it. And he used to give prizes in case you found any mistake in his PRDs. Prizes would range anywhere between a bar of chocolate, a pizza, or a bottle of expensive Whiskey.

It helped us as developers handle all cases because they were part of the PRD and it would help the manual QAs because they just had to make sure that the cases described in the PRD were taken care of. The only bugs we would see were the ones arising because of an individual's device configurations (This was a time before Android had enabled "developer options" and users could play around with developer configs in the Settings app).

One thing he was obsessed with was speed. As a speedcuber, he understood doing things in a matter of seconds rather than in minutes. He trained himself to type 110-120 words per minute (wpm) and he used to send us Typeracer links from time to time to see if we were any match to his typing. We struggled to get even 40-50 wpm.

Because of his ability to think clearly and write quickly, he would write down a lot of specs. He would write down what feature to add or finetune when a particular metric goes up and also what feature to add or finetune when a metric goes down. So when the metric eventually got affected, he had the spec ready for us and he would never grieve for the spec that never saw the light of the day.

Ever since I worked with him, I have had a high bar for the PM role. In a true sense, he was an enabler for the Engineering team. I've never met a PM who has set such a high standard for himself/herself.

A good PM is the one who started of as an individual contributor, and eventually grew to become a PM. Basically, lead by example, and not by authority.

Anyone who is willing to take the time to understand the nature of the problem they are solving before jumping the gun in making decisions/estimates is someone I instantly respect. I have seen this trait in both managers having no software expertise before as well as people with a background in the domain although the latter is more often seen doing this.

Knowledge of the domain, gives business context to engineers also so they understand the "why" aspect, considers the view point of engineers as well, doesn't use big strategy words and tries to show the logic and backs his assumptions with data.

I think one of the traits of a good PM is theh are willig to take on responsibilities away from an Engineer that can help boost up the productivity of the Engineer and also reduce pain.
For one example an engineer having to be stuck between implementing and negotiating minor intricate details with the third party: in this case a good pm can take a download from the Engineer and drive the negotiations himself so that Engineer can feel less burdened and can find more focus time.

This is a one very specific example based on experience but yeah it does help boost things up.