We Need Fewer Product Managers | Hacker News Reader

We Need Fewer Product Managers

hackernoon.com

65 pointsAthas31 comments

I've been coding professionally since 1992. I've witnessed the gradual decline of this profession from a fairly respected research-and-design type position to a clock-punching, time-tracking factory-assembly-type job - at least in the minds of the hordes of project/product managers who see their position as making sure that they squeeze every ounce of "productivity" out of the "lazy, slacking" programmers by accounting for every single minute spent in the office and making sure it matches up with an estimate from two months ago.

> We have roles (hats) for these things: project managers, UX, researchers, data scientists, business analysts, team managers, coaches, etc. Do product managers often wear these hats? Sure. Do you need a product manager to wear these hats? No.

Yikes, some problems immediately spring to mind:

1) It's significantly more overhead (both financially and logistically) to have seven specialists doing the job that one generalist was previously.

2) Someone still needs to "herd those cats". Someone has to take the UX research and distill it into project requirements, someone has to take the business analysis and figure out what that means for the product, and so on.

3) It's ok to have generalists with changing job duties. Companies do this all the time with job titles like "software engineer" or "full-stack engineer".

I get the frustration with vague job descriptions and unclear responsibilities, but I don't think the answer is more specialization necessarily.

>"herd those cats"

I'll do it.

No matter how it is worded, someone needs to be the shield for the development team. There is a constant stream of requests from customers, but the team should not be exposed to all of them. That is the responsibility of the product manager. A coherent system, and decide how to use the limited ressources to develop the product the best way.

"Herd those cats" - that's where "self organizing teams" come in. Turns out, most groups of people who are told "Hey, you're all accountable for (X). Work together on it" will actually work together. That includes figuring out what the business actually needs (not what they say they want), and what tradeoffs may be necessary. I've been on a project in the past that for most of its life had no product owner (or equivalent), just devs, QA, and a team lead, and we delivered what the business flat out said was the biggest success our department had ever given them. We still had internal issues on our team that we had to work around, we still had disagreements, but when everyone is invested in the success of the product, you learn the domain, learn when you need to ask questions, when you need to listen, and when you need to overrule the business (and how to do that in a way they can appreciate).

You should have someone in charge (a technical manager say) to handle personnel disputes and otherwise play tie breaker in the event of disagreements, but that's a very specific, and very different, role, compared to what product/project owner/manager entails.

What are your individual incentives and expectations, and who sets them? Who has the power to say "Look, this will be cheaper and better for the business if we spend $50,000 on this SaaS and 3 person-months of dev time integrating it instea of building it in house from scratch"? Are you all individually measured on value to the business and not engineering productivity?

My worry with unmanaged teams is that they work well when the right option, with all the data, is to just let some engineers do the engineering they're familiar with / excited about, and very poorly when that's not the right option. So if you don't know in advance which case you're in, you want someone who's able to herd the cats if necessary.

If the technical people don't understand the tradeoffs and prioritize the business' actual needs (sometimes even above the business' stated wants), why do you think a non-technical person (which is 100% of the POs I've encountered) will be able to?

Because the non-technical person has time to dedicate to learning about business' needs while the technical person is busy doing technical stuff for most of their day.

And then they have to communicate that to the dev team, and sit with the dev team to come up with proper stories, which effectively saves little to no time (and leads to a game of telephone; is what the PO telling you -really- what the business needs or just what they heard the business tell them they wanted?). Or, be technical enough that they don't need to communicate it to the dev team in the first place but can just write the stories. I've yet to encounter one sufficiently technical

Because technical people aren't often incentivized to prioritize the business' actual needs. This isn't about skillset, it's about how long you're going to stick around at the company if you're doing a different job from what management expects you to be doing.

Yeah, I see your point and I've been on similar teams. But I think you're:

1) Drawing a lot of conclusions from a single data point (the project you were on)

I've been on teams like the one you're referring to as well. I've also been on teams full of great people who needed someone to manage all of those things. Some teams are better at self-organization than others, and I don't think it's a fatal flaw for a team not to be capable of that (to the extent that a business requires, anyway).

I've been on many more teams full of excellent people who were incredibly relieved to have someone else do all the organizational work, even if they themselves could've done it quite easily.

Organization is overhead. Your team lead was likely filling in the role of "product manager" even if it didn't seem like they were (and in fact, the great ones sometimes make it seem like they're not doing anything at all).

2) Misinterpreting my point

The article's suggesting more specialization, whereas it seems like you're arguing for less. The article is suggesting that the role of "product manager" should be split into multiple roles, whereas it seems like you think the role should be subsumed by developers and team leads.

Team organization becomes exponentially more difficult if your team is composed of many different roles and specialists. That's what I meant by "herd those cats".

Oh, of course we filled in that role, and to a point that's what I mean by team lead. But the standard is having both a team lead, and a product owner. Why? What is the PO doing that the team and it's lead aren't better able to do? If there is something, by all means, have that person, but typically there isn't. Which I think is this article's point

> What is the PO doing that the team and it's lead aren't better able to do?

I think you've either been very lucky with teams or you've had terrible luck with product managers.

Let me turn it around, actually: Why have a team lead at all? Why can't the developers just collectively meet with higher-ups, decide on timelines, etc.?

Oh, the team does. The team lead serves largely as tie breaker, and as the person to help bring everyone back on track if discussions go off on a tangent. But the team lead is not there (and frankly would not be able to) decide by fiat on something the team was not amenable to; that can't work.

My takeaway from the article was less that you should have each one of those roles filled out with a dedicated person, but more that those roles can be fluid and accomplished by many people on the team. Developers and designers can talk to customers. You can experiment with bringing in representatives from customer success, sales, or whatever for the team to work with to analyze business requirements. Developer leads can manage the projects and meetings. There's cases where having a dedicated product manager helps with these, but keeping those roles fluid in the early days can be helpful.

> My takeaway from the article was less that you should have each one of those roles filled out with a dedicated person, but more that those roles can be fluid and accomplished by many people on the team.

I guess that wasn't really my takeaway, and even if it was I wouldn't agree with it really.

Why it wasn't my takeaway is quotes like:

>> If you need advocates, evangelists, analysts, persona specialists, domain experts, coordinators, strategists, stakeholder herders, project drivers, etc. then hire them, and give them the right title

>> Consider hiring in apprentices/interns to fill “mixed” hats — research, data science, UX, etc.

I can think of a few kinds of manager who ought to be culled (mostly upper), but somebody who can give me crystal clear requirements with clear priorities is of immense value to me as a software developer. It takes a massive weight off my shoulders.

The alternative is fielding a stream of requests from different people with different agendas and trying to figure out both what their deal is, what the hell it is they are actually after (because most people can't explain their requirements coherently and have to have it teased out) and using subtle social cues to figure out how important their requirement really is so it can be prioritized.

I've noticed that PMs who can't do this are pretty common though. It's a job that seems to be filled frequently by unqualified people.

Don’t you find that formulating requirements optimally often benefits hugely from, or requires, technical understanding of what might be possible, and that this understanding is usually absent, by definition, in a PM?

It depends on the product, but probably not. If it's a very technical product where the customer is also technical then yes. If it's a user-centric product then I'd much rather they just had domain experience (and maybe UX skills).

The best PM I ever had was non technical, had no UX but had significant domain knowledge, and was pretty clear on the limits of his knowledge.

The worst PMs I've worked with are the ones that had a little bit of technical knowledge - just enough to be dangerous - and tried to direct the team to implement a half-baked solution where, more often than not, the actual problem they were trying to solve was shrouded in mystery.

Yes, it's that last scenario that I particularly have in mind. PMs are typically led to believe that they should acquire some technical understanding and furthermore that they will be better respected if they do. This leads, as you say, to poorly designed solutions.

I'm not personally convinced that requirements-gathering is an inappropriate activity for an IC engineer.

Formulating/eliciting requirements is aided by technical knowledge not so much in understanding the potential solution space (though that has some value) as in knowing what questions implementers are likely to need to have answered, so that you can both provide a good starting point (it's still going to be iterative) and avoid doing unnecessary work or overspecifying in a way which constrains implementation inappropriately.

But if you have non-differentiated team roles, developers should be doing that, not the PM, and if you differentiate roles, analysts and not the PM should be doing it. Product (or project, either way) Management is a distinct skillet from business/system/domain analysis, and your PM has no more business doing the analysts work than coding. The PM has an oversight role and might ask questions to refine the analytical work product just as they might on a demo of a software product, but they aren't the person who should primarily doing the work.

This is really a rant against management. Reading it reminds me of my way of thinking early in my career before I had encountered a good manager, and also really understood how hard it can be to get even well meaning people working on the right things and moving in the same direction. A collection of specialist individual contributors sounds great, but in practice, it just doesn't work.

We need good managers for sure. But I like the fact that the author is trying to draw a line between management practice and thought process.

A regular manager is better than an amorphous product manager.

If your manager tells you to do X, it's pellucidly clear that you need to do X. That's the person that does your evaluation, can fire you, can maybe get you a raise or a bonus, that approves your vacations. If you think it is a bad idea, you can argue that with your manager. But at the end of the day, if you aren't convincing you are probably going to do X or start looking for a new job. On rare occasion maybe you can take the risky step of going over your manager's head, but it is unlikely to end well.

If a product manager tells you do X, is that an order? suggestion? request for a favor? If you don't agree that X is a good idea, what are your options? What if the product manager for product A tells you do X and the product manger for product B tells you to do Y?

I understand that companies on the one hand don't want a rigid system where cross functional teams communicate with each other solely by going up across and back down, but on the other hand don't like to have e.g. a programmer managed by someone that's never programmed. But a dotted line on an org chart are the corporate equivalent of code smell -- a problem waiting to happen.

I don’t quite understand this piece. Perhaps there is some exaggeration in the use of product and product manager in titles, but I think it’s superior to previous exaggeration in project management.

It seems like this author has a complaint against product management, but doesn’t quite explain who hurt him or why.

The recommendation is for various different titles to serve in the role- analyst, domain specialist, etc. But I think this is just syntax sugar for product manager. I don’t think you go to school to be a product manager. I think you go to school for a skill and then add product management skills (eg, be an engineer, learn product management to design products and lead teams). This approach is better to the leader being a project manager with no domain expertise but able to track schedules.

I don’t think it’s important what you call the product leader, it’s more important that you have someone with knowledge of the user and the problem domain “in charge” rather than just a procedural person following the project.

Finally, you need a metaphor for all products to help with oeganization. I prefer product over project as it better puts the user as the measurer of value (ie, if user is happy then project is succeeding) rather than the project itself which frequently can continue on intertia for some time without any user value.

Product managers produce less quality than self organized teams because even a good listener will not be able to coordinate all the small things that go into a great product where every domain specialist can contribute there sense of quality.

This inefficient centralization however is necessary in higher complexity orgs because otherwise the higher level has nothing to control, no levers to push and pull. (they can't track down and keep in touch with EVERY individual)

The downside of self organization is lack of focus outside a certain scale. The free market is a quintessential example of higher level emergent quality resulting from individual self organizing self centered interaction. It produces "goodness" but not in a mission directed way.

The JavaScript ecosystem is another example. And like all ecosystems (as opposed to just "systems") it can be messy and confusing despite what it does.

Efforts to tame these types of wildness often fail. Efforts to scale without becoming this type of wildness also often fail. As orgs grow, the focus on controllability requires more and more gatekeepers to maintain eventually choking actual output.

I’ve had many managers; by far the best were former peons that had actually worked on the project/technology they’re driving, or at least used it.

Better still, those that never became 100% managers; more like people still being regularly exposed to the tech so they know firsthand. And since frankly tech is more fun than spreadsheets, this meant fewer meetings and shorter interactions overall, just getting stuff done. It meant using technology to help the project rather than periodically re-explaining everything to somebody and shoehorning it all into someone’s idea of a project plan. It meant that estimates could be meaningfully judged instead of being made-up numbers.

Most teams I've worked on had a tech lead, a UX designer and a product manager. Why can't one of the first two people play the PM role? It's not as if being a PM takes up a person's whole time. In fact, on most of my teams, the PM was also the PM for a few other teams.

Having fewer people wastes less time in coordination.

I understand there would be some situations where you need a PM separate from other roles, but that shouldn't be the default. Just as most teams don't have an interaction designer, a visual designer, an animation designer, and a sound designer — all those are performed by one UX designer — most teams shouldn't have a separate PM.

Is there anything I'm missing?

> We need fewer product managers.

We need MORE:

- internal startup co-founders,

- UX,

- customer advocates,

- domain experts,

- service designers,

- complexity untanglers,

This suppose to be a sarcasm?

The piece is spot-on in that companies as they grow fill up with mid-level “PM”s who fill time with meetings. One problem with the article is companies don’t always use the P to mean product. They may distinguish Product and Program/Project, but the criticisms of the article, where not specifically about the word “product”, apply to the others.

Reply on news.ycombinator.com