Live data from Hacker News

We Need Fewer Product Managers

hackernoon.com

21–30 of 33 posts

Re: We Need Fewer Product Managers

#21

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 a…

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?

Re: We Need Fewer Product Managers

#22

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 a…

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.

Re: We Need Fewer Product Managers

#23
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.

Re: We Need Fewer Product Managers

#24
post #16

Earlier quoted context omitted.

"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 equiva…

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…

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

Re: We Need Fewer Product Managers

#25
post #13

Earlier quoted context omitted.

"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 equiva…

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…

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?

Re: We Need Fewer Product Managers

#26
post #16

Earlier quoted context omitted.

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…

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.?

Re: We Need Fewer Product Managers

#27
post #13

Earlier quoted context omitted.

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…

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.

Re: We Need Fewer Product Managers

#28

Earlier quoted context omitted.

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 t…

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.

Re: We Need Fewer Product Managers

#29
post #13

Earlier quoted context omitted.

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…

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 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.

Re: We Need Fewer Product Managers

#30

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 a…

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?

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.

Post reply on HN