The Product Manager is not your enemy: Thoughts for first-time Engineering Managers

When I became a manager for the first time, around 10 years ago at trivago, I believed the product manager should define all the goals for my team. After all, they knew what needed to be built and I had no clue about business concepts.

That was wrong!

If you work for a tech company or a more modern company, there is usually a figure/role called the product manager (or product owner depending on the company structure and the responsibilities). This role is in charge of guiding the product direction and defining the goals.

Ideally the product person joins your sprint plannings and refinement sessions, shares the requirements for a specific goal, so that the conversation to how to achieve it starts.

In short: The product person gives you the “what” and your engineering team decides on the “how” to technically solve it.

Then you meet somewhere in the middle to prioritise.

As the project and the team grew, our code base kept growing and growing too. Our work wasn’t just about delivering features requested by the product person; It was also about maintaining and evolving the technical solutions we delivered.

Aha!

When was then the right time and space to work on tasks like upgrading PHP, fixing services that weren’t cost-effective or refactoring the weakest part of our architecture? Why did those tasks never make it to the product roadmap?

Because I wasn’t communicating their importance strongly enough.

I needed to learn that it was my responsibility to share the full picture of our team’s needs, including technical debt, infrastructure changes, long-term improvements.

The more business understands what good engineering requires, the easier it becomes to find balance between business value and technical evolution.

The turning point was simple but powerful: talk, talk, talk

The more we talked, the more we aligned. And by talking I also mean written communication, like documenting projects, describing the steps, milestones, giving heads up to technical changes… everything. Creating trust and transparency between the product person and myself became my number one priority.

You may feel like you are spending too much time in alignment, but in the same way that at the beginning of my manager journey I did not have any idea about business concepts the product person may also not have technical background. I guarantee you the more information both share the better the quality of the decisions later on.

Building alliances, covering their gaps and vice versa, understanding we both co-own success and should work hand by hand, was one of the most foundational learnings in my path to build balanced teams and achieve goals efficiently.

Also consider, the product person is often the one closer to c-level or senior management, they may be the ones scaling up the information, therefore they represent your team work. It is in your biggest interest that this person understands the reason behind that refactor, or the value produced behind having for example a development environment.

The product person is not your enemy, it is your ally, treat them as one and make their life easier.

Tips for new managers

• Bring product into technical conversations earlier
• Proactively explain the “why” behind engineering initiatives
• Prioritise transparency and ongoing alignment (even weekly if needed)
• Co-create roadmaps that includes product and tech goals (+ innovation )

In a following article, I will share about my experience bringing technical priorities into business roadmap.

I hope this helps! See you in the next