10 Guaranteed Ways to Annoy Your Product Manager as a Senior Engineer

As response to Irina Stanescu's article

There are many ways to drive an engineer crazy. Irina Stanescu wrote about the most common ones here, and actually I have seen most of them in real life 😟
On the other hand, there are many ways engineers can drive the product manager crazy! Let's take a look:

10 Ways Engineers Drive Product Managers Crazy

1. "That's technically impossible" - without explaining why, and without offering any alternatives. Some product managers have a rough technical understanding of what is and is not possible

2. "We need to refactor this first" - suggest a complete overhaul when they ask for a simple feature. Refactoring may make sense, but not everytime.

3. "Did you create a JIRA ticket for that?" - respond to every casual Slack message with this, even for the smallest questions.

4. "That'll take 6 months" - give extremely padded estimates for simple features, then deliver in 2 weeks, making all their roadmap planning meaningless. A good product manager knows that estimates are not promises, but extreme sandbagging won’t help.

5. "But what about edge cases?" - bring up 17 obscure edge cases that affect 0.001% of users during their carefully planned demo to executives. It good to have edge cases in mind, but not every edge case needs to be addressed.

6. "We should use [latest trendy tech]" - propose switching to the newest framework right before a major release because "it's more scalable." Also called “shiny object syndrome”.

7. "That's not in the acceptance criteria" - maliciously comply with exactly what was written, ignoring obvious implications, then act surprised when they're unhappy. (Yes, I have actually seen this.)

8. "We need to address our technical debt first" - bring this up at every roadmap planning session, but never provide a concrete list of what needs fixing. If it’s so bad, you surely know where the debt is.

9. "It worked on my machine" - dismiss all bug reports with this classic, then spend weeks debugging the production issue that "couldn't possibly exist."

10. "We should make this more generic" - turn their simple feature request into an enterprise-grade framework that could theoretically support every possible future use case, adding 3 months to the timeline.

Please don't actually do these things if you want to maintain a healthy working relationship with your PM.

Why This Guide Exists

While these behaviors might be tempting, especially after your PM has committed to impossible deadlines or changed priorities for the fifth time this sprint, they're not particularly constructive. The best engineering-PM relationships are built on mutual understanding, clear communication, and collaborative problem-solving.

A Better Approach

Instead of these tactics, try:

• Explaining technical constraints clearly and early

• Offering alternative solutions when something isn't feasible

• Being transparent about real challenges and timelines

• Working together to find the right balance between technical excellence and business needs

• Setting realistic expectations early

• Teaching them enough about technical concepts to have productive discussions

Your PM is trying to make the product successful, just like you. You just have a different perspective on how to get there, but you are on the same team working toward the same goals.

The article by Irina

8 Guaranteed Ways to Annoy Your Senior Engineer

---

What I read

As usual, I will list some of the best articles I read on the Internet. I will keep a list of the best articles (currently >800) at https://www.digital-product-management.com. These are today’s picks:

Ignoring security alerts makes sense: When risks need to be addressed and when they can be ignored.

What’s Your Shape? 12 skills PMs must learn to build products that are valuable to their customers and their companies.

Getting buy-in to get things done: How to recognise buy-in. How to achieve buy-in.