The best Engineering Product Manager I had the pleasure working with was/is Elaine Hamilton.
In a lot of Engineering projects, there is a need to project management so that the time, cost, and scope constraints on quality produces the most quality in the product. Whether it be about bridges, cars, etc. Software Product Management is no different. In some places they split up the Product Management from the product side and an engineering side. Some places have one product manager tilted more towards the End user (interesting, I ran into Ben Horowitz’s blog as well as a doc as well as Gopal Shenoy) . Other places have the product manager tilted more towards the engineers and schedule driven. Some say Product Manager and Project Manager rather than Product Manger versus Engineering Product Manager. Some places just have a Project Manager.
From my understanding and from the places that I worked, there are some fine differences in regards to Project and Product Manangement, but both refer to some of the same over all goals. To deliver on schedule while considering risk (whether it be engineering or outside factor risks) and the product requirements.
Why I thought Elaine was the best one so far…
1) She went off her analysis through given data and presented those data by various means.
There are tools out there. Yes, she used gantt charts based on estimates not just for development but also to account QA testing times, pivot tables, Charts on bugs, etc. to try to get the best estimate for when the project will get shipped from start to finish.
2) She made sure that the requirements are concise and clear for everyone.
She went around collecting all the data first to make sure that all the requirements were understood before hand and then laid everything down before everyone. When asked if the requirements were changed she would be the deciding factor. She would not budge from those requirements unless there was a logical reason to do so given the data. She took ownership of the requirements once the requirements were passed to her.
3) She was the neutral third party stake holder.
We had lunch at one time to discuss some of the project status and such. She asked me the question “Do you think Dev should have a lot of control?” I stated, “generally Dev does have a lot of control, but I don’t think that would solve the issues for the end users all the time.” She asked me the question “Do you think QA should have control?” I answered the question with “Though, QA is the means to advocate for the end user, they should not have total control either. There needs to be a third party arbitrator that collects the data, tries to understand the risks involved, and then make the decisions of going forward or not; such as a PM.” On some of the things that I talked about in terms of risk, she listened and fought against development based on the data that we could do something better for the end user. At times she did side with the development when it was too risky to take changes. She was the means to arbitrate the discrepancies on bugs.
4) She listened.
She patiently listened to each and every party and took in the data and ideas before making a decision. She never talked over someone else that I recall. She took in their point of view and considered it and stated a question that may make the other person reconsider.
I am unsure how Mozilla is defining the roles of product/project managers. I believe that it may be because I am ignorant of how PMs are being defined in Mozilla, because Mozilla works in a different fashion to a degree than most other places that I worked. Maybe it’s just a blog or a post or something that I missed somewhere along the other materials that I am required to read.