| Be on top of your shit. I agree with this one wholeheartedly. One of my biggest gripes about PM's are when they produce half-baked things, like half-baked metrics, or half-baked external communications, or half-baked documentation. I'd rather they just didn't send it out in the first place. It's one thing to intentionally scope down the work. It's another to deliver something that is half of what you promised. This holds for engineers too, but in context we're talking about PM's. At best you get confused managers/coworkers/users. At worst it makes your team look incompetent regardless of the work you actually did. That's how as a PM you get cut out of the loop. Also, I think somewhere in should be a meta-principle: Figure out what skills your team needs, and focus on providing those. Specifically, depending on the company, team, culture, problem domain, product, etc. A team with an established, tight UX/engineering iteration cycle needs the PM to define the problems and get out of the way. A team that is starved of UX skills will need a PM to pinch hit on occasion. A team working on highly technical products (such as in security) might need a PM who is almost an engineer themselves in terms of technical expertise. A team working on a CRUD app doesn't need that much technical expertise, in favor of more time spent on UX and interfacing with other functions in the company. As a PM, you have to understand these dynamics and how you can best fit into it. Otherwise you just get in people's way and lose the trust of the people you depend on. (For context, I was a PM for several years, am an engineer now.) |