
We Need Fewer Product Managers - Athas
https://hackernoon.com/we-need-fewer-product-managers-50e47dfd95a0
======
commandlinefan
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.

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

~~~
lostcolony
"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.

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

~~~
lostcolony
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?

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

~~~
lostcolony
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

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

~~~
Myrmornis
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?

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

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

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

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

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

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

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

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

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

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

