One of my earliest memories when I started working with product teams was the underlying feeling within my team that the Product Manager was actually working against us. In countless meetings, I had to hear complaints that things were not straightforward, and that the product team didn’t understand anything. In hindsight, I see that this was a sign of immaturity within the team and not an issue with the product.

Let’s first get one thing straight…

A Product Manager in a software engineering team is responsible for defining the product vision, strategy, and roadmap while coordinating with stakeholders and prioritizing features based on user needs and business goals. They facilitate effective communication, use data to make informed decisions, and continuously improve the product through feedback and iteration.

Considering what was written above, it’s also important to mention what is not part of the role of a Product Manager:

• Writing Code
• Micro-managing Development Process
• Designing User Interfaces (UI)
• Handling Sales and Marketing Activities
• Conducting Quality Assurance (QA) Testing
• Performing Project Management
• Providing Direct Customer Support

With emphasis on the part about Micro-managing the Development Process, it’s not uncommon for many teams to feel micro-managed by Product Managers, but this is often due to a lack of effective communication agreements.

Communicating is the key

During your software development lifecycle, your Product Manager needs data in order to make commitments with the business. If this data is not available, most likely your PM will have to ask the team for input. So, as an engineer or engineering manager, the first thing you should be asking yourself is, “Am I enabling my Product Manager to make proper commitments?”. From my personal experience, when the product team comes with a question, it’s not because they don’t know about the subject, but because once the team has spoken, they’re free to commit in a way that’s not harmful to the team.

“I believe in God, everyone else should bring data.”

Making good decisions depends heavily on the amount and quality of data that you have; that’s why your Product Manager needs this data! I know teams that don’t like to estimate tasks, but then how are you going to be able to tell when something is going to be delivered? If your PM has to rely on “guesstimations”, they will probably set the team up to fail.

If you’re an Engineering Manager, you should be obsessed with performance metrics for the applications that you’re developing and for the team that you’re managing. Because without these metrics, you will not see when adjustments need to be made, when processes need to be reviewed, and even when someone deserves to be rewarded.

For the managers reading this

You should set the example for your team. Every part of the Tech Organization has a reason to exist. When the team vilifies Security, this results in Security Incidents. When the team vilifies SRE, that leads to performance issues. Therefore, you should be the one fostering a collaborative culture and setting boundaries that are good not just for your team but for the whole organization.

Furthermore, remember that by villainizing Product Managers, you’re actually poking holes in the wall that holds stakeholders’ pressure from the team, and a team operating under high pressure is a team that will eventually fail.