Having a PM is like having a little kid, while driving somewhere, and he's constantly asking: "Are we there yet??".

Mentally, they’re about as mature as a little kid, too.

@Nanos

A PM is supposed to be the person who:

1. Learns how (a part of) the product works, completely. They should know what every button and knob does, or at least what the expected behavior is.

2. Gathers information from UX researchers, data scientists, designers, engineers, sales, support, etc to understand how to further improve the product.

3. Determines a long term plan (vision) for the part of the product they "own", and make sure it connects well with the plans of other PMs.

4. Creates, manages and prioritizes tasks which fit this vision, and adds clear requirements to these tasks.

5. Refines tasks together with engineers to get estimates. If engineers disagree about the estimate, the requirements must be cleared up. If the estimate is high ("can not be completed in a few days"), the task must be turned into more granular deliverable chunks.

@Nanos

6. Makes sure engineers have plenty of focus time. This is usually done in the form of a 2-week "sprint". The sprint is opened with a planning, where engineers accept a certain amount of work to be finished within that sprint. During the sprint, no tasks or requirements can be changed, and there is only a ~10-15m daily "standup" meeting where progress is discussed.

7. The PM is the "lightning rod" for questions, requests, bug reports, etc -- No one outside of the engineering team talks to engineers, they address the PM.

8. The PM CAN interrupt a sprint, for example to fix a critical bug. In this case, another task of similar size is removed from the sprint.

9. The PM reviews the delivered feature. This is not the same as a code review, but similar: The PM reviews the git branch in terms of changed functionality. For this purpose, the branch is usually deployed separately. At some companies, the PM is helped by QA testers to do a functional review.

@Nanos

10. The PM owns and carries responsibility for the delivered feature. When the task is completed and it's all live on production, the engineer's work is done. If it doesn't work as desired, short of misconduct or gross incompetence, it's not the engineer's fault, the PM is to blame.

Only someone who conforms to these points is a product MANAGER, and only then do you deserve manager-level compensation.

@bittersweet Oh how wonderful that would be.

Standup is 30-45 every day. Planning is 45. Or PM doesn’t know the product, keeps moving tickets around, and has no idea how much work something should be, nor does he listen or care. But he’ll happily chew at you for not finishing your tickets, not listen to why, and merrily continue on his way. He also makes changes to procedures and doesn’t tell anyone, but chews at people for not following the changes.

It’s wonderful!

@Root In that case you have an ethical right, no obligation even, to kick him in the nuts from behind, right before the elevator doors close.

PM stands for "Problem"?

PM: hoes eat goweng?