 |
| Engineering vs Product Management |
My boys and I are a fan of football (no, not the American NFL, but the soccer kind). In football, like in many sports, there are fierce rivalries. One of the most famous rivalries is between Real Madrid and Barcelona. It is so popular that it has a name: El Clásico. Like El Clasico, far too many organizations view the collaboration between Engineering and Product Management as a rivalry. It is not a rivalry, and there are ways that the relationship can be structured to ensure a collaborative work culture that drives success.
A little bit of history
Product Management is a relatively a new discipline created by the technology companies. Before there was such a thing as PM, the functions were performed by Business Analysts (and still do in huge and non-technical organizations). In technology companies, there were System Engineers who were primarily responsible for translating business/customer requirements into System Requirements Specifications (SRS). Remember SRS?
Functions of a PM
Since the discipline is relatively new, companies tend to assign a variety of functions to Product Managers. If you google for "what's the difference between a product manager and," Google auto-suggests Product Owner, Project Manager, Business Analyst, Marketing Manager and a Product Specialist. Apart from these, Product Managers often perform the role of Scrum Master, Engineering Manager, and Product Line (P&L) Manager. That gives you an idea of the functions PMs perform.
So, what should a PM do?
Successful organizations define the role of a PM sharply. In my opinion, PMs should own their product(s) and all interactions concerning that product with the rest of the company (Marketing, Sales, Support, Finance, etc.). PMs are not Scrum Masters, and they should not be. Making PMs also the Scrum Master is the most common mistake companies make. That is usually a morale deflator for the engineers and engineering leaders. PMs are also not Project Managers or Solution Architects.
Their job should be just to define the product requirements clearly in Product Specs (also known as PRDs). Product Specs include UX wireframes, journey maps, and user stories. Product specs should not mandate design choices or architectural decisions. That should be up to Engineering to decide. Of course, PMs can suggest implementation options (most often PMs were engineers themselves, so this is natural) but the decision making authority lies with the Engineering leaders.
How do PMs collaborate with Engineering?
I view Engineering and PM as the two horses riding the chariot side-by-side (hence the picture at the top of this article). Rounding up the analogy, the Coachman is the CEO, and the chariot is the company (any guesses as to who the passengers are?). For the chariot to run efficiently, the two horses (or two pairs of horses) must ride in sync and be in lock-step. This collaboration starts at the top: the leaders of Engineering and PM must have a great working relationship with each other and set the tone for their respective groups to collaborate effectively. PMs must work very closely with their respective Engineering Director/Manager on the product backlog, sprint planning and prioritization of incoming maintenance issues. PMs should be approachable and available to all engineers and be active in all sprint meetings (standups, retros and planning meetings).
Traps for a PM
In my opinion, there are two kinds of Product Managers:
- The ones that merely translate customer-provided solutions into product requirements
- The ones that understand customer problems and outcomes, then derive product requirements to solve those problems and meet those business outcomes.
Most often PMs fall into the trap of being the first kind. However,
being aware of the trap and allowing yourself plenty of opportunity and
time to learn about the customer's use case, problems and their
outcomes, one can indeed be a great PM. I know, because, I have seen and
worked with excellent Product Managers who do not fall into this trap.
In Conclusion
Product Manager is a challenging role - a role with no reporting authority but all the responsibility for a product (or a set of products). To succeed in being a PM, the person must be an active communicator and collaborator. Moreover, clearly defining the role and refining the collaboration between PM and Engineering can help an organization succeed.
The Author: Bala Pitchandi
About:
Seasoned engineering executive with twenty years of global experience in building world-class software products and high performing teams. Renowned for being a leader in dreaming big, driving innovation and transforming products. A progressive leader, who has built and grown successful global engineering and product teams. Passionate about Diversity + Inclusion, Service Leadership, and fostering a culture based on trust
Post a Comment