What things do engineers say or do that really annoy you as a lead product manager?

A pet peeve of engineers is when lead product managers present solutions instead of problems.

It’s annoying because an engineer has to decipher and reverse engineer what the requirements are. They’re meant to own technical implementation; lead product managers own things like problem, customer and strategy.

Not many lead product managers are aware they do this. The ones that are stop doing it and their working relationship with engineers improves.

As an engineer, I’d love to know things engineers say or do, habits or traits that piss off lead product managers that engineers might not be aware of.


As a lead product manager myself I would love to give a list of requirements and have zero problem afterwards, but the reality is that sometimes some requirement just pops up after we start working on the feature. You do 100 alignments with stakeholders and they say it is okay, then when you change their system they come running for you saying something they did before is now not working and they need it back ASAP.


@SamanthaYuan, That’s a little different than sitting on a user story for 9 business days and then saying “I didn’t understand ___” on day 10.


@YuriRoman, We had a guy who consistently rolled stories from one sprint to the next and he always would say something about not understanding something technical (that should have escalated to the technical lead) or not understanding something about the expected outcome (which should have been escalated to me), but he didn’t say anything until we were closing the sprint. Not the only offender I’ve encountered, but the absolute worst offender. When he was on, he was great, but I think he mostly did it to be lazy.


This sounds like the Engineering Manager’s responsibility. The EM should counsel him about raising concerns sooner.


What do people mean when they say PMs should not offer solutions? I have never seen a successful team where PMs are not heavily commenting on work to drive the solution in a certain direction. I would say it is more of don’t jump to one solution before you have let designers and engineers explore different ones together with you.

However, if anyone argues the only thing a PM should do is to set requirements and let everyone else figure it out, then a PM should also be a very low paid role. Any strategy consultant can do that.


@PriyaVarma, It’s a collaborative thing. As a PM, I shouldn’t be showing up to refinement with a mock-up that’s never been seen before, it requires lots of work between different sets of stakeholders.

As I progress through my PM career and am getting ready to move into a management position, what I have found is most efficient is clearly outlining the most important problems, working with designers and engineers on the core of the problems, and providing the voice of the customer, but at the same time not getting so hands on that I’m the one driving all the changes. I meet with these teams regularly and provide feedback, but my time is best spent out talking to customers and selling the product. You need to give your stakeholders the autonomy to experiment and drive solutions based on your input.


@Priya, You’re the stakeholder. Not the designer and not the engineer. While your input is invaluable, you should be like “we need to add a button here that send an email”. It should be “our users need a way to send an email”.

Then you work WITH the team to decide on a solution.


Okay, but many people here seems to say PM should let others find out the solution instead of everyone in the team working towards a solution.

PS: everyone are stakeholders, so saying PMs are stakeholders is like saying PMs are people.


Engineers are really stakeholders. You could make the argument, but I disagree. I’m an engineer by the way.

I think most people are saying this because as a PM generally you don’t know shit about anything technical. You need to rely on your engineers to come up with a solution because you don’t really know the implications of your decisions. Generally speaking.


The whole stakeholder theory comes from economics, and was mostly focused on also taking into account employees and other ’stakeholders’ than pure business interests as maximizing profit.


Thinking of every possible edge case known to human kind so they don’t have to do a project they’re not excited about.

It never works for them but the tactic doesn’t change. It just frustrates everyone involved.


If an edge case is possible it needs to either be addressed or intentionally made impossible. “Its an edge case that we don’t need to worry about” and “no users will ever do this” are stakeholders biggest hand waiving tools and comes back to bite their backs (or more accurately the teams downstream from their decision making) more often than not.


@Donovan, This just isn’t true of all edge cases. Sometimes things just don’t work properly for a small % of people and it’s not worth the effort to fix for it because it’s a minor problem.


@Cathryn, Not for all edge cases. They are called edge cases for a reason. Would we start building 10 feet balcony rails because it is possible for someone to jump off shorter ones? Not a great analogy but you get the point. I am working on a product which is heavily regulated - it is impossible, yes impossible for us to deliver without letting some edge cases fall through the cracks. We still document everything so we know what we are getting into.


Are you not familiar with the Pareto principle, aka the 80/20 rule?


I am talking about neglecting to prevent against a user having a terrible experience… this is different from choosing not to cover specific use cases.


@AnaRodriguez, Real-world value generation tends to mean compromises though. Without unlimited time or unlimited budget, 80/20 is a good way to deliver the most value in the shortest timeframe.


@DonovanOkang, Some edge cases. Sure. But most of the time they’re not. I wrapped a project up about a year ago and have documentation from a dev lead who insisted they build for a huge list of edge cases because he didn’t want to do the project and wanted to delay in order to properly plan. To this day only a handful have been validated, most of which we did end up accounting for. 90% of the others have never happened. I’m glad he documented them though, so I can go back and refer to the times I’ve been correct.

  1. Having to be babied. Constant reminders to attend a meeting or answer a stakeholder’s question. Needing so much praise for fixing a bug. Also, why can’t the devs all get in a room and figure out a solution. Why does Product need to come in to arrange the meeting and make sure they are all talking to each other?
  2. Constantly needing support. I just had someone very senior, maybe a level above me, ask me which developers should work on our project. I’m like dude, they don’t report to me. Product doesn’t staff projects. (might be the same as 1)
  3. Can’t give a straight answer. I asked my tech counterpart if something is possible. And he spent like 20min on the question. And then gave some lame ass answer on how the new product should be so amazing that people will want to switch. He’s pretty senior, so he should be able to read between the lines.
  4. Having other priorities which aren’t the priorities I gave. That’s what I hate about this whole matrix org. I don’t know what people are working as their time may be on other projects too. This isn’t the devs fault, but it’s annoying.
  5. Lack of focus. You aren’t a PM. If there is new tech that will help solve a problem, great. But how about you take care of 1-4 before you start looking for new problems?

I’ve worked at a few companies; all tech first. I’ve seen this in so many places. I’m honestly thinking of becoming a dev b/c of it.