
Good Product Manager, Bad Product Manager (1996) [pdf] - naftaliharris
http://www.khoslaventures.com/wp-content/uploads/Good_Product_Manager_Bad_Product_Manager_KV.pdf
======
crdoconnor
The four most common problems I've had with PMs:

#1 Won't nail down the customer's actual problem, describe it clearly to you
and let you come up with a solution. They will just pass on the customer's
proposed solution and insist that you build it.

#2 Vague, Incomplete and unversioned specifications rife with duplication and
redundant information.

#3 Inability to prioritize or break down stories coherently.

#4 Won't get their hands dirty actually testing the product. That's QA's job.

~~~
mtabini
> Won't nail down the customer's actual problem, describe it clearly to you
> and let you come up with a solution. They will just pass on the customer's
> proposed solution and insist that you build it.

It's actually a bit worse than that. Customers almost never _know_ their
problems; instead, they _understand_ their problems through the accumulated
knowledge of their profession, and have a very hard time stepping out of “the
way things are done” to nail down their ultimate goals.

One of our biggest challenges as developers is that software engineering is
very much a meta-profession: Being fully competent in computer science is only
useful if you can apply that competence to real-world problems, and that
inevitably means having to become expert enough in a field to which you may
never have had any exposure.

A good PM understands this and turns development into an iterative process in
a tight loop with customer feedback: You push the project forward a little,
check with customers, apply their feedback, and lather-rinse-repeat until
you've come up with a good solution—one that typically _innovates_ on the
status quo.

A bad PM tries to spec everything ahead of schedule and never really gets off
the ground, her best possible outcome being automating existing processes at
the tail end of a waterfall-induced nightmare.

A worse PM is overwhelmed and avoids nailing down details, seeks no customer
involvement, and leaves things to fester for weeks without any feedback. I
don't know anyone who enjoys being on the poor team tasked with dealing with
that kind of work.

Incidentally, this is what I've always taken agile development to mean: It's
not about stand-ups and kanban boards, but rather about acknowledging and
embracing the fact that programming is an inherently inexact science.

~~~
crdoconnor
All true enough.

I'm actually starting to think that the PM job should actually be a kind of
'next step up from QA' position, since so many of the skills PMs typically
don't have are exactly the kinds of skills that really good QA people do.

Plus, QA really, really, really, really needs to be a profession with good
career progression because without career progression you don't have good QA
people and without good QA people your product will turn to shit.

Abilities like empathy with users (you get this by being in communication with
them, hearing about their problems), ability to tightly specify desired system
behavior (you learn this writing bug reports), ability reproduce scenarios,
ability to use version control and some basic programming skills.

I think if you had a PM that could write high level failing automated test
cases for developers to turn green and submitted them to developers via pull
request instead of dumping dead trees on a developer's desk, developers would
be in heaven.

------
captnswing
There's also the corresponding "Good Engineer, Bad Engineer" which I like

[http://www.chrispliakas.com/2015/01/22/good-engineer-bad-
eng...](http://www.chrispliakas.com/2015/01/22/good-engineer-bad-engineer/)

------
tatx
I have worked with several project managers who cite this article and claim to
live by this ideal. However in practice they do everything but what is
mentioned of a good product manager in the article. I don't know if I am
biased or if the product managers, like most humans it would seem, fail to see
themselves in a bad light (and thus correct themselves and set anew on a
better path).

I also think that this is a subjective article, which, while it tries to list
down the differences between good and bad traits of a product manager, fails
to strongly separate the bad traits from the good ones by using vague
management speak, and in general ends up making product managers feel goody
goody about just being product managers.

------
sfrechtling
One of the last times this popped up, I printed it out and annotated it. I
wanted to see if it was possible to take something so different to my working
world (risk management) and apply it. Annotating it for my situation made it
clear that this document should be seen as more far-reaching than just
differentiating product managers. It really is pointing out the difference
between good workers and bad workers in _any_ organisation.

Every single point made has an element that can be applied to any organisation
and career; Productive workers understand the context of business ("Good PMs
take all important factors..."); successful workers solve the issue, not the
symptom ("Good [PMs]...proper deeper into the [problem]"). Sometimes I look
back at my annotated pages and score myself about whether I fall to "Bad" or
to "Good". I'm still working at it.

I urge everybody to read, and apply this to their own careers. Don't
pigeonhole this document just because it is defined as important to product
managers. I see this as just as influential as Ray Dalio's Principles
([http://www.bwater.com/Uploads/FileManager/Principles/Bridgew...](http://www.bwater.com/Uploads/FileManager/Principles/Bridgewater-
Associates-Ray-Dalio-Principles.pdf))

~~~
kiyoto
I agree. One of my mentors recommended that I write down my own version and
share it with my team. Here is my attempt:
[http://kiyototamura.tumblr.com/post/130937953602/good-
market...](http://kiyototamura.tumblr.com/post/130937953602/good-marketer-bad-
marketer)

------
theo
Interestingly, author thinks these points may not be relevant today. What has
changed?

 _Warning: This document was written 15 years ago and is probably not relevant
for today’s product managers. I present it here merely as an example of a
useful training document._

[http://a16z.com/2012/06/15/good-product-managerbad-
product-m...](http://a16z.com/2012/06/15/good-product-managerbad-product-
manager/)

~~~
crocal
As an active PM, I can't really spot anything that would make any of these
points irrelevant today. One thing I did note, though, is that PM concept is
not so widespread as one may think. Dilution of power in large functional
organizations often means that such a "small CEO" is not necessarily welcomed.

~~~
rch
Last night I mentioned the idea of a dedicated product manager to our CEO, who
responded that the CTO will ultimately be responsible for that area. It's
interesting, but I'm not convinced the roles and skillsets are adequately
aligned.

~~~
crocal
CTO cannot be the product manager. A product manager must align technology
with market, and does so by providing the correct input to the technology
group. CTO must focus on execution and innovation, while a product manager
focus on what needs to be executed and how to align innovation with the
market. It's different skillsets, indeed, and they are rarely aligned.

------
ajmurmann
I read this the other day in Ben Horrowitz's book "The Hard Things About Hard
Things" and loved the idea by other commenters here to apply it to other
fields. Just [my own version]([https://github.com/ajmurmann/good-developer-
bad-developer](https://github.com/ajmurmann/good-developer-bad-developer))
that represents my views on engineering. I tried to stay away from concrete,
good practices like TDD or pairing that are en vogue right now. Although I
have very strong opinions on some of those, they are controversial and I think
they would take value away from the larger points.

I would be excited to hear people's thoughts on it!

------
happywolf
I am a product manager in the financial sector and generally I agree with this
list. What I want to add is "A good PM knows how to balance competing requests
from stakeholders and know when to say no". You can't please everybody.

~~~
13hours
My view is a project is only a success if all stakeholders are happy at the
end. To succeed, you therefore need to: 1\. Know who all the stakeholders are
2\. Know what they expect 3\. Come up with a plan to satisfy 2 4\. As you go
along, and you see reality differs from 3, you must either change 2 or change
3, or a bit of both.

A PM's job is expectation management. Delivering on expectation will most of
the time include having to change the expectation to match the reality at the
end of the project. It's usually easier to change expectations earlier rather
than later, and also by not saying "no", but rather by saying "let's rather do
this".

------
meshko
This is a surprisingly good writeup. Now if someone can come up with a way I
can make my pm read it w/o offending him...

~~~
nommm-nommm
If you have a larger office just post it in the break room.

------
arielweisberg
How is a bad product manager supposed to know they are one of the bad ones?
How do you explain it to them?

------
dang
Posted many times yet apparently never discussed:
[https://hn.algolia.com/?query=%22Good%20Product%20Manager,%2...](https://hn.algolia.com/?query=%22Good%20Product%20Manager,%20Bad%20Product%20Manager%22&sort=byDate&dateRange=all&type=story&prefix=false&page=0).

