
Spare Me From “Product Guys” - ssclafani
http://techcrunch.com/2011/12/03/spare-me-from-product-guys/
======
mmaunder
Program manager, product manager and business analyst are 3 roles that make me
check that mental "looks busy, does nothing" box. Maybe they're
interdependent. Program manager feeds product manager feeds biz analyst who
feeds program manager. The devs toil quietly in the corner and don't dare
question the symbiosis and CEO is relieved someone is there to do all the work
they make.

If I sound grouchy it's because a biz analyst once tried to suggest I wasn't
senior enough to attend the meeting we were in. [12 years ago. They'll never
find the body.]

~~~
BadassFractal
The PM's job is to clarify whatever questions the engineering team might have
about the details of how the user will interact with the system. She has to
have it all figured out to be able to pull her weight on that kind of
engineer-heavy development team.

Generally speaking it's difficult for everybody on the team to know everything
about the little details, and it's good to have someone with that picture in
mind.

I hear that Pivotal Labs for example always require there to be an on-call PM
when they work on their contracts, to immediately unblock progress.

~~~
neutronicus
Where I worked before I went back into academia, the title "Project Manager"
referred to someone whose main job was running interference between engineers
and upper management. She was always coming up with answers to questions about
how long things would take, etc. so I wouldn't have to and prompting me for
various answers that upper management actually cares about. Definitely helped
me get things done.

That place was emphatically _not_ Silicon Valley, though, so it makes perfect
sense to me that the two positions share little more than a title and not
coding.

~~~
mattmanser
I'd just like to point out to both you and the parent mmaunder said _Program
manager/product manager_ , not _Project Manager_. But if he means a PM, then
fair enough.

Anyone who thinks a good PM isn't worth their weight in gold is seriously la-
la and probably hasn't worked with one.

------
sudonim
I only know being a product guy on small teams.

To me, my role as a "product guy" is to keep the whole product and it's
intricate details in my brain. I work with the CEO and the Head of Engineering
to set the direction for what we're working on today or next. I take in all
the feedback from our metrics, our customers, team members, and the boss to
decide what's the next most important thing we should build. I push back on
business needs when our scope starts to grow too big. I push back on the
engineering team when we don't complete work in a satisfactory way. I'm
responsible for the success or failure of the product.

I enjoy the job, but it's not something I would consider easy. It's not
something where I spend a lot of time looking busy and doing nothing. I could.
That would make me a bad product guy.

There are many ways to skin a cat. The difference between a bad product guy
and a good product guy is that the good one finds a better way to skin a cat.
A good product guy improves the lives of all the stakeholders in the product.

------
moocow01
Not in reference specifically to product roles, I think one of the problems
right now in SV and probably in other tech hubs is the migration of finance,
law, "other fancy profession" people to the tech industry as the bubble has
inflated. You have lots of people who genuinely have no qualifications
specific to the tech business and there only drive is to just follow the path
to whatever is shiny and looks like the most possible path to extravagant
wealth according to Forbes. Usually they are easy to identify because they
transform themselves to fit the mold of whatever is hot.. ex. in 2004 they
were real estate agents / brokers, in 2008 they were social media consultants,
and now they want to be SV product / tech entrepreneurs because it the latest
things in the paper. The problem with these folks is they unfortunately add
little to no value because they spend all their time running around trying to
figure out what is the cool thing rather than trying to understand how they
can use their own skills to best help others.

Honestly Im not too big of a fan of the bubble times. I'll be glad when things
calm down and the finance, law etc types move onto the next shiny thing and
were left with the people who truly enjoy the industry.

------
gatlin
Scott Adams, in the back of "The Dilbert Principle," describes the OA5 model
of running a company: Out at 5. His main goal was an efficient organization
that let everyone out at 5, which meant the product was delivered, which meant
everyone did a fantastic job, and other things that we all take for granted as
being desirable.

One of his big points was that nobody should be doing anything more than 1
degree removed from the core mission. If you're a web host, you're either
directly working on maintaining or supporting the service, or you're
optimizing an internal process relating to the first two (as an example).

Otherwise, you're dead weight. The kind of product guy described in this
article runs afoul of that OA5 principle.

~~~
PakG1
What I don't like about OA5 is that it assumes everyone is able to work at the
same pace at the same time during the day throughout the day. All my best
thinking is really in the afternoon and evenings. Always has been.

Maybe I can hack my biological clock to be better in the morning. Dunno. For
now, my brain doesn't seem to start focusing until about 10am, and then it
doesn't seem to really get into gear until an hour or two later. With that in
mind, it's really difficult for me to get my work done with people who want
OA5. I suppose it would be fine if they're OA5, but they don't force it on me.

~~~
gatlin
That was one of my problems with it, too, even though I do get rolling pretty
fast in the mornings. I think the real solution is to assume that the meeting
time is going to be inconvenient for _someone_ and just try to have a big
stupid group sit-down once a week at most. Small agile teams can do a lot with
impromptu stand-ups.

I think the most important thing, though, is to plan the big stupid group sit-
down at one end of the day so that it doesn't interrupt. I've worked in places
where they would stop us mid-day and ask what we have been doing and what we
will be doing. Surprise surprise, the answers to both are the same 99% of the
time. On top of that, they often pull me off something I'm intensely focused
on to tell them what I was focused. /rant

------
keeptrying
Its very very hard to find a good/great program/product manager.

I've only known one in my 10 years as a programmer. Some tests to use to
figure out if someone is a good product guy:

1\. Ask them if you can meet 3 users who are willing to use your product. If
he can get you to meet 3 - you've probably got a good product guy.

2\. Ask them how people make money now that your product doesn't exist. If
they say they've actually tried to do this without your product and show you
how they failed, they are probably pretty good.

3\. If his documentation that he shares with you is a single prioritized list
of features with measures/time built in so he can re-prioritize the list then
he's probably a good product guy.

Essentially he will take complete and utter responsibility for the product
from upper management.

Very rare to find.

------
pinaceae
Product Manager here. Our software is aimed at field force users in the life
science industry.

Without me, developers would not know what to build. It is all industry
specific, driven by business as well as compliance requirements - in several
distinct regions, worldwide.

When programmers build stuff for that hey will use themselves, yes, a product
manager's value is debatable. but there is a lot of stuff out there a normal
coder will never use, but still has to build.

~~~
nupark2
This is actually why product managers drive me batty; they're neither a
software engineer OR a UX engineer, so they don't actually know how to build
the product, nor do they have the design skills to create a great UX.

The job you describe here would be infinitely better suited to a UX engineer
that has experience and knowledge necessary to build great user experiences,
and a lead technical engineering architect.

The idea that engineers/UX designers can't translate business/compliance
requirements into engineering/UX requirements is laughable. The truth is that
they're the ones best suited to do so, because they're entirely capable of
understanding both the business/compliance requirements and the constraints
under which they must be implemented in UX/engineering.

~~~
pinaceae
if you think this is just UX, you have simply no clue about business
processes. once you have a large number of customers, corprations, which are
truly global, your nice and simple approach will not scale.

our devs are centralized, whereas our product management is out there, on the
ground, from the US to china, europe, japan, etc.

wanna understand sampling compliance in Italy? expense reporting in Germany?
order management in Spain? EPPV in Japan? do you know what EPPV means?

there are no coders out there to cover this broad level of _business_
knowledge.

i started in consulting, with a background in coding as well as business.
worked myself up the ladder, was a system architect for global systems. then
became a "product guy" - because I have all this knowledge and experience now,
in my head. which you can't simply learn or read up. only years of experience
can give you that.

------
lucasjake
Product guy really boils down to Generalist vs Specialist. Maybe it is
'Versatilist.'

The product person can't be an expert in for example, cryptography, and
simultaneously be an expert in photo filter technology, and also the 100 other
things that the product needs.

The end product might need all these things, and need specialists on maybe
5-10 of the items. The product person needs to be able to understand how all
of them work, and make an end product that has market potential.

A product person can build products on their own if they have to. They are
just better and faster when they have a team. If you can't do it on your own,
you're probably not a real product person.

~~~
gujk
Your paragraph 4 contradicts paragraph 2.

~~~
viscanti
Only if the only way to build something is by being an expert. It's possibly
to "adequately" or "poorly" build something without being an expert.

------
baddspellar
I've run software projects on the technical side for going on 20 years now.

In all those years, I've been lucky enough to have exactly 2 good product
managers. The rest have ranged from useless to downright harmful

Here's what made the 2 good ones good: They knew their limitations. They
didn't imagine themselves to be programmers, architects, or user experience
experts, regardless of how many books they read. They never, ever, specified
requirements in terms of architecture or implementation. They might give a
sketch to clarify what they're talking about, but they'd never defend it as
the required (or even a good) approach. They trusted the rest of the team in
their areas of expertise. In turn, we trusted them in their area of expertise.

Their focus was on talking to real customers about the problems they faced,
finding out why current products (ours and competitors) didn't solve those
problems, and getting that information to the people who had skills in
building products. When we had something to show, they'd give us feedback
based on how well it met the customers' needs, and they'd use their
relationships with customers to get some customers to give us feedback on
intermediate results. They did research. If they didn't know something, they'd
say so, and find out.

They trusted us to give them fair estimates. If something was going to take so
long it would miss a market opportunity, they'd work with us to figure out
alternatives.

They'd prioritize, and stick to these priorities unless significant new
information came along, in which case they'd sit with us to make tradeoffs.

What did the rest of them do?

They'd specify requirements in terms of implementation. They'd tell us how
they wanted something architected. They'd attempt to design a UI and tell us
the requirement was to implement that UI. They'd trust their gut without doing
actual research. They'd promise features in a specific timeframe before
getting estimates from engineering.

------
dhotson
Somewhat related:

"What makes someone a great product manager at Google?"

[http://www.quora.com/Google/What-makes-someone-a-great-
produ...](http://www.quora.com/Google/What-makes-someone-a-great-product-
manager-at-Google/answer/Edward-Ho-1)

------
code_duck
When 'product people' are good, they're what makes the product a success. When
they're note good, they're worse than useless. My impression is that it's not
an aptitude you can learn from books. Being good at product design takes an
ability to see the whole picture while also taking details seriously.

------
viandante
I am amazed by seeing developers, people with great attention to details,
generalizing at this levels.

------
mikeleeorg
I was a software developer, then technical manager for several years before
deciding I wanted to become a product manager. This was at a large corporation
where coming up with product specs, marketing plans, and business models were
out of the purview of a technical manager.

I met with several product VPs I respected and asked for their advice on
making the transition. One of them, also a former software developer, pointed
me to the books, "Crossing the Chasm" and "The Innovator's Dilemma". They
opened my eyes to a new way of looking at products and helped me successfully
become a PM.

Nowadays, I try to make sure everyone on my team (in a startup environment)
has read or knows the content of books like these. In a startup, everyone has
a huge role in how the product is defined. However, someone who can take
ultimate responsibility in prioritizing the product's features based on
customer feedback, business metrics, market trends, etc., is still necessary.
That person might be the CEO or cofounder or whomever, but they essentially
have "product management" responsibilities.

------
mathattack
"Product Guy" can translate to "non-technical" similar to "Business Analyst".
95% of the so-called Business Analysts I see (many from top schools and top
firms) really don't know anything about the businesses they're analyzing -
they get the title by a lack of technical background.

Of course the 5% of "Product Guys" and "Business Analysts" that are true
talents are worth their weight in gold.

~~~
derefr
> 95% of the so-called Business Analysts I see (many from top schools and top
> firms) really don't know anything about the businesses they're analyzing

So, what are they paid to... _do_ , then?

~~~
joshwa
_So, what are they paid to... do, then?_

Thrash around trying to understand the business. Some will be more successful
than others, depending on how smart they are. Some will gain a superficial
understanding and claim to have mastered the domain, but let's just say
there's a different kind of "OA5" person who often ends up in the job.

Occasionally, if you're lucky, you'll find ons that has a vague clue about how
to write requirements. Or design UI. Or that cares.

 _(speaking as a Product Manager / UX Designer / Developer, not necessarily in
that order)_

------
URSpider94
Im my mind, the "product gal" or guy brings the voice of the customer into the
product team by:

* Writing user stories

* Prioritizing features for development effort

* Weighing in on design decisions that impact user experience

* Interfacing with current and potential customers to collect feedback

Meanwhile, this frees the devs up to, you know, develop.

In an early-stage start-up, one of the founders usually plays this role, in
addition to a million other things. As the company grows, you need folks who
can work full-time on product management.

A great product manager knows enough about implementation to earn the respect
of the rest of the team, but is not afraid to ask the developers to tackle
really difficult problems, if it's the right thing to do for the customer.

In my experience, a team without a good product guy runs the risk of
delivering a product that nobody wants.

------
blrgeek
Guy from finance background who has no idea what 'product guys' do in non-
consumer tech companies, talking about self-styled product guys.

In a non-consumer company, where the engineers are not the end-users, there
has to be someone who creates and keeps the vision alive.

And normally the product guy comes through after many years of engg. or engg +
mktg experience.

------
jaysonelliot
I've never thought of myself as a "product guy." I'm a user experience guy.

What was surprising to me about this article was that the three books he
recommended are all books I'd consider required reading for anyone who wants
to take on user experience as either a skill or a role.

Does that mean I'm on my way to being a product guy?

I kid, I kid.

------
ebun
Product Manager here. Are most PM's really that non-technical?

I have a B.S. in Computer Engineering and worked as a dev for 3 years before
becoming a PM. I thought that my path into product management was a common
one. Is this not the case?

~~~
devs1010
The product manager at my job is completely non-technical, and this seems to
have been by design (they just filled it from an internal candidate a couple
months ago), basically she is supposed to be the bridge between engineering
and the "stakeholders", so to speak and make sure their vision matches what is
happening. To handle the technical side of things we have another manager that
does have a technical background, loosely termed the "project architect". All
technical decision go through him or the CTO, the fluff stuff and touchy feel
stuff goes through the product manager.

~~~
brettinlj
Recipe for disaster. Spoken from a product manager.

~~~
devs1010
I agree to an extent but they do need someone to basically take all the crap
from the "stakeholders" and it may be better to not waste that on someone with
technical knowledge

------
pacemkr
I've always thought of a "product guy" as a competent hacker who can can
switch hats as he's working to think about business, the users, the design,
the ease of use, the infrastructure, etc. A jack of all trades, one step away
from entrepreneur. Never did it occur to me that "product guy" means something
entirely different to others.

------
ChristianMarks
Whenever I hear the phrase "push back" I reach for my resume.

~~~
viandante
Why?

------
ahoyhere
Being the "product guy" is a shitload of work. I know, that's the role I serve
in the company that I founded. Customer interaction, roadmaps, design,
prioritization of features, plans for growth -- it's _hard_ and it's a _lot_
of work.

It's so much work that I don't even have time to code any more, because it's
so much more than 1 job.

Seems like developers just like to hate on anyone who's not a developer
because the developers can't _see_ the work they don't have to do.

Whether or not many Product Managers in bigcos are full of shit doesn't say
anything about the profession whatsoever. What it says is that most people are
incompetent at their jobs, and lazy. Which is also true of most developers.

It's sad for me to see HN continuing to leap to confirm its own biases instead
of questioning them.

~~~
lucisferre
It's not HN confirming the biases it's real world "PM"s who are often
completely unqualified as well as the many businesses out there who encourage
this because they can't seem to understand what the role is or what would
qualify someone to do it well.

Management, in general, gets a lot of flak from "makers" because of how
convenient it is to (as one friend of mine put it) "hide from the work". That
isn't to say there isn't incredibly important stuff management needs to be
doing, just that there are more people not doing it than there are doing it
well and it's the makers who often suffer for it, or worse are blamed for poor
team performance.

Basically, until that reality changes I'd expect to see a lot more people
slogging on "PM"s.

~~~
ahoyhere
It's not Manager Quarterly confirming biases it's real world "coders" who are
often completely unqualified as well as the many businesses out ther who
encourage this because they can't seem to understand what the role is or what
would qualify someone to do it well.

Developers, in general, get a lot of flak from "bosses" because of how
convenient it is to (as one friend of mine put it) "hide from the work". That
isn't to say there isn't incredibly important stuff programming needs to be
doing, just that there are more people not doing it than there are doing it
well and it's the makers who often suffer for it, or worse are blamed for poor
team performance.

Basically, until that reality changes I'd expect to see a lot more people
slogging on "coder"s.

------
skeptical
I'm surprised so many people here at HN buys the 'Product Guy' crap. My
opinion is even more radical than Aaron Harris'.

I'm sick of guys that think they are more important than developers because
they use a suit and tie or master some extremely subjective skill while I sit
all day and do actual tangible work.

I will not give credibility to anybody to criticize my work if that person
haven't been in my shoes. As a developer, the only product guy I would respect
is the one that has once been a developer and that would have the skills to
sit down and discuss my work from a technical point of view if that would ever
be necessary. Otherwise I reserve myself the right to think that some of the
decisions are stupid. Why wouldn't I?

Paul Graham , Bill Gates, John Carmack, Joel Spolsky and many others were
(are) programmers they didn't reach their status by 'knowing how to manage
people'.

~~~
alexanderberman
This misses the point of what a product manager actually does, though. A PM
isn't there to criticize your work or even to manage developers - that's more
the project manager's job (or perhaps a lead developer's).

PM's at most companies translate customer feedback into concrete specs that
devs can execute on. PMs usually do not have any authority over developers,
but instead try to work alongside them.

I really don't understand why devs hate on PMs - they exist to let devs focus
on code. PMs create customer personas, user stories, UI/UX specs, and business
reports, which are all things that the majority of devs don't want to have to
deal with.

~~~
nupark2
> _I really don't understand why devs hate on PMs - they exist to let devs
> focus on code. PMs create customer personas, user stories, UI/UX specs, and
> business reports, which are all things that the majority of devs don't want
> to have to deal with._

My issue with this is that most PMs do an exceptionally bad job of this.

Understanding the user is a task as complex as developing the application, and
it's something that is best suited to a dialog between an actual UX designer
and the software engineers.

Blindly implementing what the PM tells you to implement is an awful position
to be in, and results in terrible UX and bored/annoyed engineers.

The engineers and UX designers should be driving the product boat. The PM (if
there is one) should be relaying business priorities, and relaying back the
technical/design context necessary to choose those business priorities.

If given the choice, I'd ditch a product manager every single time and replace
them with:

* A UX/UI designer.

* Engineers interested in user experience

* Lead engineering architects

* A _project_ manager to keep tabs on priorities and scheduling.

~~~
aspenblue
The UX designer is supposed to lead the drive towards superior user
understanding, empathy in design through features that respect users.

The developer is responsible for defining what is technically possible.

The PM has to analyze the tradeoffs and negotiate a compromise that best suits
the product, time available, and company objectives.

When the three collaborate, you have ONE product team. No party is superior or
can stand alone effectively.

------
georgieporgie
In my experience, the role of a PM is to 1) make everyone sit around in a 1+
hour _daily_ meeting, during a ridiculous crunch cycle, instead of discreetly
coordinating as necessary, and 2) make _horrible_ UI changes and yell
(literally) at developers when they push back out of simple common sense.

