Hacker News new | ask | show | jobs
by designium 2159 days ago
I think there are many different types of PM and the "Great Product Manager" you are referring to is the PM who owns an ongoing Product and who is responsible for some of the business goals.

I think most cases, including my own, the PM owns a sub feature of a major product, or they are somewhat like a mix of Project Manager. That is also different when you consider if you are dealing with B2C or B2B.

In B2B, the problem may be "automate this process" and there is not a lot to discuss or vision to communicate in that case.

Finally, your recommendations will change what is the best if you are dealing with organizations that are more engineering focus or marketing focus.

For example, leading your team suggestions may not apply if you don't have the control of the devs. They are just outsource team and your company's budget is limited. So keep pushing for vision and values may not work.

Another example, if a PM works in a Dev/Product shop, the decisions are usually decided by the client, not the PM; so in that case, what is the best may not apply. The PM can recommend and back it up, but then the final decisions are under the scope of the client.

Finally, I think the other sections such as Communicating Effectively, Being good operator and Running Effective Meetings are definitely good for every type of work, not only for PMs but I'd say any job.

2 comments

I've been a PM for 25 years. All the principles in the article can be applied to all of the items you mention, when I'm the PM. I don't consider myself great, just experienced and willing to learn more all the time. In the past when I've seen things like this, if I don't agree with them I have gone to someone more experienced to see what they have to say about it.
> and there is not a lot to discuss or vision to communicate in that case.

Agreed. In those cases, I explicitly say as much when writing up the card. I say "We have no specs or mockups, but here is the need - make it happen." We typically start from there and have a few discussions to work through details, but I have zero problem letting my engineers be free to do their own jobs.

I do exactly what you do. I write up the cards in Jira and then the devs will have further discussions from that point and beyond. They also feel validated and they do bring good ideas.