Introduction

Every company has a different philosophy about the product development process and where PMs fit into that process. Below are the three most common types, with pros and cons.

<aside> 💡 "engineering" in this paragraph includes all the hard skills required to build the product: developers, designers, etc. They focus on the “how” to make things happen.

</aside>

1. PM drives engineering. This is a "throw it over the wall" approach, where PMs gather requirements, write the quintessential product requirements document, and hand it off to engineering to spec out the technical specifications. Contemporary organizations may do this process in a more agile and collaborative way. Still, the expectation is that PMs know best about what customers need and that engineering is there to serve.
   • Pro: Engineering can focus on coding without a lot of distraction; this tends to work well for Waterfall development shops with long lifecycles.
   • Con: Engineering loses sight of the big picture and does not develop empathy for customers, which can lead to a poor user experience. Often there are unhealthy tensions when technical debt and “plumbing” work need to be prioritized over customer requirements.
2. The PM-engineering partnership. In these cases, there is a strong yin-yang between PM and engineering, with joint discovery, decision-making, and shared accountability. Engineers join PMs in customer interviews, and PMs are in sprint meetings to help unblock tasks or clarify requirements. But the two roles respect the line where one starts and the other stops. PMs understand what’s being coded but don’t tell engineers how to code, and engineers have empathy for customers’ needs but leave the prioritization to the PMs.
   • Pro: A streamlined prioritization process that values technical debt and plumbing projects; better design processes leading to a more positive user experience; higher performing teams with improved product velocity, quality, and, typically, happier customers.
   • Con: Breakthrough innovation may not get greenlit (multiple owners?); time-to-market may seem to lag (though I’d argue that what’s released is far better aligned with customer needs and more likely to successfully scale).
3. Engineering drives products. More technically oriented product companies (cloud, big data, networking) tend to be engineering-driven, where engineers are advancing the science in their domain and PMs validate solutions or create front-end access points (UIs, APIs) to tap into this new technology. There can be a collaborative relationship and feedback loop between customers, PMs, and engineering, but typically PMs are serving engineering in these companies.
   • Pro: Breakthrough technology can offer customers things they didn’t even know they needed. VMotion at VMware was a great example of this. An engineer thought it would be cool to do, a PM figured out how to monetize it, and it became a billion-dollar game-changer for the company.
   • Con: Engineering chases the shiny new thing, over-architects the solution, or iterates forever, seeking perfection before getting customer feedback. PM input on priorities is ignored, which sometimes includes the most basic needs of customers.

Source

At MUI we favor, in the order: 3, 2, and 1. Why? We have an engineering DNA. We tailor the relationship based on the users' needs:

• MUI Core: 3. Why? it's about competition in a mature space. How are the best products built? By having somebody that owns both the product and implementation (engineering + design) side. One brain makes better product/implementation decisions knowing the full range of the implications and the constraints. This is superior to having a small committee (PM partnership) of people that needs to sync. Finding strong engineers/designers with a strong product focus is hard. But this is how to differentiate. MUI Core has three major upsides that make this approach practical: a. It's engineers building a product for engineers that lack design skills (mostly) b. the size of the OSS community yields a strong feedback loop any junior can grow from c. a small group of core high-performing individuals can reach millions of people, d. design quality execution on its own is a major reason why people use the product. In this option, we still have a PM to empower the implementation team. This is how Bootstrap, Tailwind, and Semantic-UI have been organized.
• MUI X: 2. Why? We have paid users and longer feedback loops, we have to be more aligned.
• MUI Toolpad: 2. Why? Our audience is less focused on pro-code engineering.
• MUI Store: 1. Why? It’s a traditional application,

The place of the role

Where do the PM roles site?

Source

Product Manager = Project Manager?

No, a Product Manager does not own project management. The team is responsible for the execution, it’s most often an engineer who will take the Project Manager role for his own topic. The Engineering Manager is responsible for making this happen.

What differs between the TPM role vs. the PM role?

At our stage and at MUI, TPM is almost equal to a PM role, the only difference being that a TPM is a person that (can) own a technical product, e.g. MUI Core or MUI X, focusing on the why? and what?