As a software engineer, I know how it feels to work with product managers. With years of experience, I've encountered fantastic Product Managers (PMs) as well as some less-than-ideal ones. Every day, I collaborate with PMs, and I understand the challenges that can arise, particularly when the relationship is strained. In this blog post, I'll offer advice on how to work effectively with a PM as a software engineer.
Two primary difficulties can arise when working with PMs. The first issue is that a PM without an engineering background may not understand the technical complexities you're dealing with, leading to a lack of mutual respect. Secondly, if a PM started their career as an engineer, it can be frustrating to hear them talk as if they fully understand technical subjects like blockchains, big data, or artificial intelligence when they actually don't.
To bridge these gaps, soft skills and communication abilities are essential.
Common Pitfall 1: Technological Ignorance
The worst thing to hear from a PM is something like, "It's just a simple button. Are you sure you can't finish it in five minutes?" Such comments imply that the work is straightforward and that you are incompetent. But, creating even a simple button is not trivial. For example, Google's homepage search button is not just a "simple button." Various states like hover, click, double-click, and other factors like text localization, accessibility, and multiple screen widths must be considered.
Common Mistake 2: Misunderstanding Roles and Responsibilities
PMs are responsible for the product, but they are not your bosses. This misunderstanding can be especially prevalent in hierarchical organizational structures or where an outsourced vendor manages in-house PMs. Practicing methodologies like Scrum can help set boundaries and manage expectations. Frequent changes in requirements can be detrimental to the project, leading to non-reusable code, bugs, and technical debt.
Common Error 3: Lack of Clear Objectives
It can be frustrating when a PM has no clear vision and hasn't defined specific requirements. Engineers thrive on tackling challenges and require clear goals. Poorly defined requirements lead to a product that's hard to measure in terms of impact and success.
Final Thoughts
To navigate these issues successfully, here are my three recommendations:
- Treat non-technical stakeholders with empathy and kindness, while educating them on the complexities of your work.
- Understand that the PM is not your boss; collaborate and be willing to share credit for successes.
- Stay informed about industry trends and be prepared to construct a persuasive argument when you think the requirements are flawed.
Remember, software development is a team sport. Like any team, success depends on effective communication, collaboration, and leadership to achieve a common goal.