3 Advices On How to Work with Product Managers

Apply this before is too late!

Apr 09, 2025

I’ve been working with real Product Managers for the last 9 years. As a Senior Software Engineer or Tech Lead, the role of Product Manager will look after you for estimates, deadlines, and multiple varied questions.

Over these 9 years, I’ve had great experiences working with PMs. Some of the best include Carolina, Giona, and

Fede Casabianca

. I’ve also faced less pleasant experiences with other Product Managers, but working with them as well I learned important lessons that helped me grow in my role and responsibilities.

In today’s session, I share with you 3 advice that I would love to know before working with some Product Managers.

Let’s start with the first one.

🧑🏻‍💻 Avoid technical aspects

☝🏼 The product manager wants to understand how the technical implementation works.

👉🏼 This is, simply, not her/his business.

This is the most important advice from this whole email.

Sometimes, we have Product Managers who are willing to understand the technical aspects. Sometimes it is because of true curiosity, and other times because of micromanagement reasons.

If you join that with the fact that we engineers are willing to explain, in any audience, our brilliant solutions…

You have the perfect storm.

☝🏼 Do not get into the trap; Stay sharp, and avoid talking about technical aspects. Let’s see this with an example.

You are in the daily meeting, commenting that you will pick up the ticket about “Refresh widget in real-time“.
The PM asks: “Hey, how do you plan to do that? Please remember we need a close to real-time, at least.”

❌ Instead of you saying this:

Well, to solve this, we will use AWS SQS + SNS managed services in the backend and then, via websockets, we will … (you know the rest).

✅ You say this:

We have clarity in the specs and during the implementation some concrete details would have to be answer from Product perspective. In any case, thanks to the technical analysis done, we know what is the right pattern for this problem, and we will use metrics that will indicate we meet the expectations.

I know: the PM is someone you are working with every day, and maybe you don’t want to look rude or abrupt. Do not worry, you are doing that; You are helping yourself, your team, and the PM as well, ensuring the communication works properly.

👉🏼 By doing so, you achieve multiple things:

You stay in the Product language.
You communicate that the technical solution is not something you just came up with, but something that passed through an analysis that ended in a consolidated solution.
You will meet the expectations set by Production, with numbers and not with feelings.

That last point leads to the second advice.

📊 Talk with numbers, not feelings

☝🏼 You need numbers for talking to Product Manager; that’s part of their language.

See this scenario:

You are in a meeting with the Engineering Manager, PM, and yourself.
PM raises the point about concerns related to the current stability of the application you own, experiencing many production incidents in the last 2 weeks… or so.

❌ Instead of you saying this:

From I remember, in the last 2 weeks we had 2 production incidents only, which I think had no impact on our customers.

✅ You say this:

Here I have the report from the observability tool (like NewRelic or Datadog) where we can see we had 2 production incidents in the past 3 weeks and both of them were Severity 4, the lowest posible and also meaning no impact on customers. Moreover, we can see the trend of production incidents is going down since we introduce the last technical improvements.

👉🏼 By doing so, you achieve multiple things:

Feelings are no longer in the conversation, only numbers, and with numbers the clarity comes to the conversation.
Suddenly, there are not many production incidents, but only 2, and in a longer period of time.
And with Severity low, based on the company’s standards

In the example above, we see the feeling from the PM was not accurate. Please note that it might be the other way around: the PM could get the right feeling!. In any case, you are talking with numbers, not feelings, so the truth is exposed and improvements can be implemented.

Numbers also apply to the next advice.

🧐 Agree on SLA and SLOs

☝🏼 We cannot put a watchdog in every input and output, but we can trust in SLOs.

See this scenario:

PM raises the concern about ensuring a feature must work all the time.
And, because this PM is very technically oriented (see the first advice), she/he asks us to put a watchdog counter in every input and output interface on whatever number of microservices we have to support the feature.

Basically, the Product Manager is asking: Is my feature working well all the time?

First, please do not fall into trying to explain the technical aspects of why you will not implement the watchdogs. Remember the first advice above!

❌ Instead of you saying this:

Look, even though technically speaking is possible, that’s very expensive and we where including extra complexity on … (you know the rest).

✅ You say this:

I see the goal here to have visiblity and certain about the feature works properly, which makes sense. Let’s define an SLA, so what you, as a PM, need us to guarantee so that the feature is not impacted, and SLO as the stricter internal target we set as a dev team to ensure we meet that commitment without operating at the limit.

👉🏼 By doing so, you achieve multiple things:

You set a clear standard for what must be guaranteed from both the product and technical sides. This helps the PM know exactly what is being committed without ambiguity.
You establish measurable targets using SLAs for external commitments and SLOs for internal benchmarks. This approach ensures that all performance indicators are based on facts rather than subjective opinions.
By agreeing on SLAs/SLOs, you steer clear of getting lost in technical minutiae (like implementing watchdog counters). It allows you to focus on delivering outcomes rather than overcomplicating the solution.
The mutual understanding of service levels builds trust between you and the PM. It demonstrates that both the technical team and product management are aligned on ensuring the feature works as intended.

From the 3 advice I wrote in this email, you can see that we have to focus on speaking the Product Manager’s language and work on top of that.

Let’s wrap up for today.

✨ Takeaways

To finish today’s issue, let me summarize some takeaways that you can take action on your next interaction with your Product Manager.

Avoid diving into technical details:
- It's not the Product Manager’s business to know how the implementation works under the hood.
- Keep communication in product language, and avoid the trap of over-explaining technical solutions.
Speak with numbers, not feelings:
- Back your points with data, not impressions; it brings clarity and credibility to the conversation.
- Use reports and metrics (e.g., from observability tools) to ground discussions in objective facts.
Agree on SLAs and SLOs:
- Define measurable expectations (SLA) and internal targets (SLO) to answer the real question: “Is the feature working well?”
- This approach avoids unnecessary technical debates and aligns both teams around shared outcomes.
Be strategic in your interactions:
- By keeping boundaries around technical discussions, you protect your role and improve collaboration.
- You help everyone focus on what matters — product goals, delivery, and measurable impact.