Live data from Hacker News

The product manager role is a mistake

sollecitom.github.io

291–300 of 370 posts

Re: The product manager role is a mistake

#291
> These PMs you hire have no vision, charisma, expertise, strong beliefs, or technical skills. So what do they do when you give them that kind of power? They play it safe, and they play politics.

I can relate with that.

I was working on an operation that has the incredible track record: 74% of reliability (in a daily batch), 2 Engineers to serve 12 Analysts, stack running an old version of Haddop and Spark (2 majors down at least) and the company hired a technical PM.

The first measure of this PM? Setup meetings with consulting behind our backs, plus tons of politics with upper management, and the cherry on the top was he thought that was a good idea to move the Data Engineering team to a Front End team since “it’s more or less the same and a developer is developer everywhere”.

Final result: everyone quited and he eventually was fired with 1 year of delay.

Re: The product manager role is a mistake

#292

Earlier quoted context omitted.

Yeah the "handing control of the company over" thing struck me as odd as well. I haven't ever seen that particular problem. In the good cases I've seen, it's just as you describe, with EMs and PMs working together with high trust to get to a decent level of consensus between them, and then parlaying that consensus into leadership buy in for their roadmap. In the bad cases, there is some breakdown in trust between the…

Handing the company over to PMs is a very common problem I’ve seen at smaller startups. It’s generally not that they are above the leadership team, but that that the leadership team have abdicated responsibility for product development to the head of product.

Interesting. I'll take your word for it. I'm glad I haven't seen that.

Re: The product manager role is a mistake

#293
post #278

Earlier quoted context omitted.

My experience with product managers is that they wedge themselves between the business and the technical teams and then wield political power while doing very little. I'm currently trying desperately to get two different PM's to talk to each other so we can be consistent with permissions sets across two different projects. Both projects use the same set of API's. One of the PM's is basically incognito, the other has…

I wonder if part of the gap here is about whether a company is B2B or B2C. In my experience at a largely B2B company, the product managers are people that aren't necessarily technical, but have experience in the relevant domain and meet with customers to find out what they need and coordinate launches etc., with them. I don't know if the same role makes as much sense at a B2C company, so maybe people are B2Bs see the…

Same experience, but I have one hypothesis: in B2C the “client” after some point become some abstract entity where people ship code/product to. A great PM can talk with those masses and extract exactly what needs to be done. This is a very hard skill.

In B2C the customer is way clearer and the relationship is everything and it’s quite hard a bad professional hide for long.

Re: The product manager role is a mistake

#294

Earlier quoted context omitted.

Yeah the "handing control of the company over" thing struck me as odd as well. I haven't ever seen that particular problem. In the good cases I've seen, it's just as you describe, with EMs and PMs working together with high trust to get to a decent level of consensus between them, and then parlaying that consensus into leadership buy in for their roadmap. In the bad cases, there is some breakdown in trust between the…

My company is product led. That means PMs have huge influence on what gets built. The how is still left to the engineers. I think it works pretty well. We ship a lot of great stuff.

I think what I described is system where PMs have huge influence on what gets built. But also a system where engineering and strategic leadership also do. Personally that seems like the the balance to me. I think all three things - tactical product decisions, execution decisions, and strategic decisions - are important and separate.

Re: The product manager role is a mistake

#295

Confusing article. “We should get rid of the PM role” but also “We still need people dedicated to do PM things… but don’t call them PMs, they’re just everyday great people.” I feel like the author had a bad experience working with a PM (the MBA comment is telling) and now wants to throw the baby out with the bath water. Business scale creates + requires role specialization. Sure, there are shitty PMs, and it’s a hard…

It also says that you just build teams where everyone is amazing (good luck pulling off that piece of recruiting magic) and then says “… give them good problems to solve…” Who exactly does the author think should decide what problems the team should prioritize? That is the primary responsibility of the PM role. Seems like the author has indeed just had a bad experience with a PM who failed at that.

Re: The product manager role is a mistake

#296

Earlier quoted context omitted.

If all you want is someone to do team-level project management toil, a line manager can do that (or hire them a part time assistant if they don't want to and you don't want to invest in better automation). This is not a whole career-level job.

I get the feeling you don't work on massively complex projects. We have loads of project managers where I work and I thank my stars we have every one of them. The coordination and planning required is ferocious for the work we need to deliver. It is not trivial and it would quickly fall apart without them.

Some of what you described in the comment I replied to fits the description of complicated company-spanning project management - a valuable role I have typically seen referred to as "program management" - but some of it, the team level dealing-with-task-backlogs type stuff, are things that managers and team members can just do in the course of their work.

But you're right that my comment focused only on the latter thing and ignored the former one.

But setting that aside, there is certainly a personality thing at play here. If I worked where you work, I would probably be more skeptical of the value of all the time being put into project management, and if you worked at my favorite companies that I've worked at, you would probably feel like it's a poorly managed mess (I've had lots of coworkers who felt that way!).

To some extent different folks just like different strokes, and that's one of the things that makes it really hard to do things that require lots of people to pull in the same direction.

Re: The product manager role is a mistake

#297

Earlier quoted context omitted.

Every thing you just said rings true. I went from 20 years engineering into engineering management, and took my first PM role last year. I took the role at a twenty year-old software company that's never had good product management, and the place is horrible. Over and over, the staff were pounded with "we are an engineering first company." Well, that means the engineering teams were allowed to do whatever the hell th…

This certainly sounds like your company is having a gap. But the gap sounds to me more like the lack of technical leadership (a strong lead, principal engineer, etc) than a PM. 10 out of 10 PMs I worked with (and it had been more) wouldn't commend on software architecture and internals and wouldn't prevent the needless complexity and unmaintainability aspects. They can at most point out that feature development and b…

If TLS version support was materially affecting your client’s ability to integrate with your products’ APIs then the Product Manager should have picked this up and worked with the development team on a way to remove this friction.

I can think of a bunch of different ways of solving this that would take a few days to build out.

Re: The product manager role is a mistake

#298

Earlier quoted context omitted.

Just to offer you another perspective: In all of the (B2C) companies in which I have worked as a PM (three, across two different industries), I have been closely involved in shaping and controlling the evolution of the product. My normal month has always consisted of creating anywhere from four to twelve unique proposals (PRDs) for new features for the company to build, with the number created varying based on the si…

My experience was B2B. I was certainly expecting a lot more of the problem identification and solution generation work that you described. The difficulty was that the owners at the top had unshakeable ideas about what the product should be. That's ok, single minded vision can be good and all that. In my very hands-on sales engineering role I'd make things that my prospects were asking for, put them in the product, th…

>The problems arose when we put in the product management process - the whole committee/requirement/signoff thing the article describes and I mentioned in my earlier comment. That created a formal bureaucratic mechanism for various players to stop all the ideas I had. Before, they'd be fait accomplis necessary for winning a big deal. Now they were just ideas divorced from value from some guy who should've known his place.

precisely, the introduction of a PM means that the people who actually implement the product are put below pure talkers. You suddenly go from being able to influence the product daily to everything being up for a vote and every vote being overriden by the PM. The PM gets to decide which issues are important enough to be included even though he really doesn't know better 99.9% of the time. 99.9% of the time he didn't talk to customers about it, he just has his own opinion and was put into this artificial leadership position that ruins the fun of the job for everyone else. Oh sure he talked to leadership but that ends up being about how to achieve his own dreams and goals, certainly not to help make the ideas of engineers a reality. I've literally never seen a PM that goes and asks what ideas of the engineers we can help make reality. Just let that sink in for a moment: Isn't that what a product is? Ideas of engineers? I mean it really is. The whole agile movement is one of the strangest gaslighting ventures that human psychology has ever produced. We are told that there is no boss while actively being micro managed issue by issue, hour by hour almost, while literally being asked every single day in the standup when X will be finished.

Re: The product manager role is a mistake

#299

Earlier quoted context omitted.

Every thing you just said rings true. I went from 20 years engineering into engineering management, and took my first PM role last year. I took the role at a twenty year-old software company that's never had good product management, and the place is horrible. Over and over, the staff were pounded with "we are an engineering first company." Well, that means the engineering teams were allowed to do whatever the hell th…

This certainly sounds like your company is having a gap. But the gap sounds to me more like the lack of technical leadership (a strong lead, principal engineer, etc) than a PM. 10 out of 10 PMs I worked with (and it had been more) wouldn't commend on software architecture and internals and wouldn't prevent the needless complexity and unmaintainability aspects. They can at most point out that feature development and b…

I agree. Founders who are bad engineers surround themselves with non-technical people who don’t question them.

Re: The product manager role is a mistake

#300
post #240

Earlier quoted context omitted.

Well, the Empire State Building was famously built as a series of sprints... You need a formal design. This doesn't mean you need a formal project. Some amount of planning ahead very obviously helps, but how much is debatable, and when you have people whose sole specialization is "planning ahead", you are certainly past the point where it's too much. Anyway, the most valuable people are the ones "planning behind", lo…

Think of the "formal project" is the API by which executing the design can be understood by all stakeholders. It is a high level abstraction that allows all parties to understand what they need to do and when they need to do it. For large projects it is simply essential - you need your external vendors to plan their availability, months or sometimes years in ahead, so that they can commit to the timeline. If you're l…

> If you're lucky enough to work on large software projects where there are no managers or other stakeholders asking "and how long will this take, exactly?" then maybe the design is enough.

How well can your project managers answer how long will this take? Because on my experience, 10000% delays are all but routine (ok, on construction it's usually bounded to something around 1000%). And how much value do people that can give you an estimate between 1% and 10000% of the target?

> But pretending planning ahead on large projects that is something that will just happen by osmosis

I'm telling you that planning ahead has a small value, following up with the plan has a high negative value, and the thing with a high positive value that is reexamining the plan is fought against by the practitioners.

Post reply on HN