Live data from Hacker News

More product, fewer product managers

kitemaker.co

191–200 of 314 posts

Re: More product, fewer product managers

#191

Not related to number of PMs, but rather the type that I prefer to work with: I’ve worked at 4 different companies in the industry, ranging from I reject the idea that “technical” folks are smarter than “non-technical” folks - in fact, as an engineer I often get caught in the weeds and lose sight of the big picture, and need a PM to help pull me out. However, in my experience, the easiest PMs to work with as an engin…

Now if only companies (like JPM where I’ve worked also) actually recruited and hired PMs with those technical skills instead of whatever bizarre criteria they use.

No I’m not salty at all :p

Re: More product, fewer product managers

#192
post #179

I've been a PM in a few B2B companies, and the reality of the job was never even close to the ad, i.e. we (PMs) never had authority over either Engineering or Marketing. "Product-led" is today's buzzword, but I'd have to personally experience it before I believe it.

Yeah, IMO "product-led" is just something that sounds nice when you package it up with a bunch of truisms and sell it as a consultant. There's a nice little industrial complex of consultants, "coaches", and other thought leaders who haven't shipped any product in a decade or more but will gladly sell you their silly services.

We're just here to do a job like anyone else, with hopefully a reasonable area of accountability. The thing that "drives" a particular initiative is what matters the most at the time - could be a big marketing push, engineering quality push, something we know sells well into enterprise markets, etc. It's fine.

Re: More product, fewer product managers

#193
post #70

Earlier quoted context omitted.

I don't believe in Product Managers or Project Owners as a net good towards building a better product or a better company. The most successful teams I have been in had no dedicated product role, instead, all decisions were made by the developers. My current view is best to remove all type of non technical people or even mildly technical people from the developers' way and let them build in peace.

In that scenario, who is driving product requirements? For example, in an area with strict financial/regulatory compliance laws, are you expecting every engineer to be an expert in those laws? And have contacts at the government agencies implementing those policies?

I think a major complaint surfaced about the PM role is: Its rare for even your PM to be an expert in that area. Ideally, they should be. Realistically, there's one guy in another branch of the company with a totally unrelated title that everyone eventually figures out is The Guy on this product domain; and the PM's role becomes "interface with Jim".

I don't generally find myself in the Anti-PM camp; but I think one of the valid criticisms of the role is that high quality hiring for it is so extremely difficult that maybe its existence is an indication of a structural problem. As the article says; if the ratio of PMs to Teams should be less than 1:1, maybe the correct lens to view this role through is more of a higher-level product lead, or a separate product branch who act more like free agents that attach themselves to teams temporarily, splitting time, where needed.

I will say, I've worked in two roles where this was the case; one a very large public tech company everyone reading this would recognize, and another a 30 person startup; giving PMs higher cross-team authority felt, to me, like a really good decision. One small positive byproduct I actively observed: when speaking with our PM, who was shared with four or five other teams, he was constantly aware of all the other work they were doing, and would actively make recommendations about how our little feature could plug-in with their little feature to increase the quality of the overall product. One small negative he communicated: because the company had no entry-level PM roles, which is where he started before they refactored the org chart, its non-obvious how you backfill these roles or create an entryway for new talent to breach the industry. Their current solution to this is "well, we can't really promote internally unless an EM or Engineer wants to switch domains" which they genuinely did try to support.

Re: More product, fewer product managers

#194

The problem with most PMs is that they are not doing boots-on-the-ground work. A good PM should be constantly bridging the gap between engineering and the user. 1. Map the product or idea being built to those who will use it. Present it, get users feelings on it, if it is viable and needed. Throughout development, gather continuous feedback by demoing, shadowing, and adapting to new feedback. Plan and execute a launc…

I've always found PM's that come from a UX/Design background to be more willing to engage with the actual people we are building software for. IME, it's always been BA/MBA types that want to draw up documentation and then chuck it over a wall (development) and call it a day.

Re: More product, fewer product managers

#195
post #70

Earlier quoted context omitted.

I don't believe in Product Managers or Project Owners as a net good towards building a better product or a better company. The most successful teams I have been in had no dedicated product role, instead, all decisions were made by the developers. My current view is best to remove all type of non technical people or even mildly technical people from the developers' way and let them build in peace.

The best PMs I’ve worked with were HIGHLY technical, either in the same areas as the developers or in adjacent areas, like product design, or the domain of the product PM for retail company did long stints in merchandising at Costco PM for spreadsheet company was a former banking analyst Most companies hire under qualified generalist PMs who have to learn everything about their market from scratch; it’s very challeng…

Pffft, they train the juniors? Hahaha, that’s funny.

Re: More product, fewer product managers

#196
post #178

Earlier quoted context omitted.

My team was product managed by a gutless PM who essentially made senior devs & tech leads do all the legwork. Requirements gathering, mean user upset about a bug, weekly status call, need to break some bad news re: priorities? - send a senior dev or tech lead. Skipped most of the agile ceremonies too, busy guy. Never wrote or edited a JIRA ticket, that was for tech org to manage. He PMd 2 other tech teams the same wa…

> Management worshipping at the throne of agile become really enthralled with these guys and can derail an org for years. In theory a PMs stakeholders are the users, but in practice it is buffing the egos of the senior management that hired them. Can become a self reinforcing closed loop between senior management / agile consultants / PMs. Beautifully put!

This was the way in almost every place I've worked. If you did a good job at managing upward and schmoozing and stroking the senior management's ego, and had those smooth "ivy leaguer" mannerisms, then it didn't even matter if you did your job. You were the Golden Boy and destined for greatness. But if you were too busy actually doing your job and didn't properly pet your management chain, you were setting yourself up to be the scapegoat.

Re: More product, fewer product managers

#197

Earlier quoted context omitted.

Why not also be the developer if you can do that much already?

Because if you’re working on a project big enough, you don’t have the time to be a good dev or a good manager. As a developer I wanted time to think about how best to solve the problem I was facing, not writing documents, refining the big picture, get a buy in from the stakeholders, giving reports, making sure the other parts of the project kept getting along and so on. It was important for me to be kept in the loop,…

When I was a product manager for large computer systems back in the dark ages, I can pretty much guarantee you that none of the engineers wanted to spend probably the majority of their days on the phone with sales reps, in customer meetings, providing updates to management and other groups involved with product launches, writing technical sales docs, and reviewing marketing materials, etc. Many engineers liked sitting in on a customer meeting now and then as a change of pace but they (properly) wanted to spend the bulk of their time focused on actual engineering.

Re: More product, fewer product managers

#198

The problem with most PMs is that they are not doing boots-on-the-ground work. A good PM should be constantly bridging the gap between engineering and the user. 1. Map the product or idea being built to those who will use it. Present it, get users feelings on it, if it is viable and needed. Throughout development, gather continuous feedback by demoing, shadowing, and adapting to new feedback. Plan and execute a launc…

That's why the best PMs have some kind of engineering background or are former eng. As small as it may be it is a requirement nowadays.

Re: More product, fewer product managers

#199
post #141
post #121

Earlier quoted context omitted.

This tension is why it's a good idea to align everyone's incentives. Bonus the product team on reliability (as well as velocity), and the ops/sre team on feature velocity (as well as reliability), and it'll balance itself out.

Who is bonusing who? I think some people simply can't get rid of the idea that there has to be some external paternalistic figure that looks over developers' shoulder and guides the poor hapless saps and their incentives. Do they give candy to the good boys/girls and coal to the bad ones? You might be thinking of Santa. The developers and sre's incentives are the same as everybody else in the company: have a great, e…

> The developers and sre's incentives are the same as everybody else in the company: have a great, easy to sell, popular and reliable product.

The hard part is how do you design a compensation package for a developer or sre worker bee, to incentivize these? How do you make their bonus depend on something as nebulous and hard to measure as "greatness" or "popular"?

For most employees, the candy/coal model works. You're not going to find low-level individual contributors who work because they just want to make a great product.

Re: More product, fewer product managers

#200
post #70

I've spent some time interacting with product managers as an engineering manager, or head of a functional area. I've also been "acting" PM for an internal product at a medium size tech company. I think product management entails some of the most important things a company does. But it's really hard work, and many less capable PMs gravitate away from it and more towards either "driving" (i.e. micromanaging) the engine…

I don't believe in Product Managers or Project Owners as a net good towards building a better product or a better company. The most successful teams I have been in had no dedicated product role, instead, all decisions were made by the developers. My current view is best to remove all type of non technical people or even mildly technical people from the developers' way and let them build in peace.

I don't understand, how do you handle prioritization decisions: if you have a 100+ customers that all want something, how do you create understanding of all needs, how do you distill that to an integrated roadmap, and how do you align the roadmap prioritization decisions across 20+ teams?

How do you organize updating of documentation, training materials, enablement of support, pricing decision, updating of price lists, enablement of sales, presales, and customer success teams? How do you manage the input towards analysts like Gartner, that have a big impact on the decision process of your customers?

How do you evaluate the offering of the competition compared to your offering, how do you determine where you should be in 1,3,5 years to have a competing product in the market?

Most PMs are mostly concerned about what should be built to create a valuable product for customers, that provides healthy stream of revenue for the company. Most developers are concerned about how it should be built. That is a completely different responsibility.

Post reply on HN