Good Product Manager, Bad Product Manager (1996) [pdf]
khoslaventures.com
khoslaventures.com
#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.
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.
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.
http://www.chrispliakas.com/2015/01/22/good-engineer-bad-eng...
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.
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...)
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...
Source: spent 15 years in "big IT", in roles from programmer up to senior director, and this is why I left.
I would be excited to hear people's thoughts on it!
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".