Product vs. Engineering
<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>
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 (Source):
- 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.
- 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).
- 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 serve 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, sometimes including customers' basic needs.
MUI
At MUI, we rely on 3 and 2, depending on what’s more relevant for a product, and hopefully never 1.
Why? We build a product for engineers who seek peak execution.
Now, we tailor the relationship based on the users' needs for the product:
- MUI Core: 3.
Why? It's about competition in a mature space. How are the best products built? By having somebody who 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 who need 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.
- Rest: 2.
Why? Our default.
In practice
How do you implement this in practice? It means that the Engineers take more product responsibilities and the PM takes more GTM responsibilities
The place of the role
Where do the PM roles sit in the team?