#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.
> 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.
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.
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.
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...)
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.
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.
I would go so far as to say that outside of technology companies the concept of a product manager is almost completely foreign. Instead, the "small CEO" is usually the business project or portfolio manager, which is often a role completely separate org-wise from the IT folks doing the work. On the one hand, the justification for this is "better business alignment", but that's just a lazy way of justifying the nepotism and political wrangling that marginalize IT organizations as purely a cost center rather than a revenue enabler.
Source: spent 15 years in "big IT", in roles from programmer up to senior director, and this is why I left.
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.
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.
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) 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!
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.
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".
#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.