4 ms·

The answer depends a lot on the industry/ product. But in general: - Communicate, communicate, communicate. Give status updates. Ask for status updates. Get in

The answer depends a lot on the industry/ product. But in general: - Communicate, communicate, communicate. Give status updates. Ask for status updates. Get information from customers to your development team. Give updates from your dev. team to your customer. -Be the voice of the customer. Know if it's more important to be really good or just get the dang thing finished. Let the development team know "we need to cut corners on this one because that's what the customer wants" if that's what needs to happen (of course, don't compromise safety). -Take care of external roadblocks. Get API info, product specs, pricing, timelines, deadlines, etc... and find a way to effectively give it to the development team. -Assume your dev team knows best how to build, test, and ship the product, but ask them questions to find out why. Don't be authoritative, but rather put on the attitude of a student. E.g. "I hear you saying we won't be able to ship next week. Why is that? What caused that? Is there anything I could for our next project that would help prevent this from happening?" -Do project retrospectives. -Learn the art of minimizing meeting length but maximizing their effectiveness. Communicate, communicate, communicate.

orblivion 10y ago
> -Assume your dev team knows best how to build, test, and ship the product, but ask them questions to find out why. Don't be authoritative, but rather put on the attitude of a student. E.g. "I hear you saying we won't be able to ship next week. Why is that? What caused that? Is there anything I could for our next project that would help prevent this from happening?" As a dev (never been a PM), the PMs who impress me are ones who ask enough questions to figure out exactly why something will take a long time to implement, and then negotiate the right surgical change in spec to significantly reduce complexity with a minimal cost in hitting requirements. The customers know their requirements, the devs know how complex they are to implement. The PM can learn both, which puts them in the position to say "What if you just did it this way? It won't hit requirement X, but it will hit requirement Y, which is much more important for this iteration."
- tkxxx7 10y ago
  Agreed. PMs at my last job excelled at this. As a result, our "sprints" felt smooth and natural, and we always had time to eliminate technical debt.
- nicoburns 10y ago
  The PM's who have impressed me (as a dev) are the ones who have allowed me to talk to customers directly, so that I can have that exact same conversation.
mturmon 10y ago
"Learn the art of minimizing meeting length but maximizing their effectiveness." One basic tool here is to have an explicitly listed agenda for the meeting, with a first cut arrived at before the meeting. New topics ("walk-ons") can be added to the agenda in a discussion at the start of the meeting, or at the end if time permits. It's surprising how many 60 or 90 minute meetings are run without an agenda. If you run out of time (which is undesirable and should be corrected if it happens often) you can push items at the tail of the agenda to the next meeting. One job of the manager is to be sure all topics (not just pet topics) get their fair share of attention, and to move the meeting onward when needed.

orblivion 10y ago

> -Assume your dev team knows best how to build, test, and ship the product, but ask them questions to find out why. Don't be authoritative, but rather put on the attitude of a student. E.g. "I hear you saying we won't be able to ship next week. Why is that? What caused that? Is there anything I could for our next project that would help prevent this from happening?" As a dev (never been a PM), the PMs who impress me are ones who ask enough questions to figure out exactly why something will take a long time to implement, and then negotiate the right surgical change in spec to significantly reduce complexity with a minimal cost in hitting requirements. The customers know their requirements, the devs know how complex they are to implement. The PM can learn both, which puts them in the position to say "What if you just did it this way? It won't hit requirement X, but it will hit requirement Y, which is much more important for this iteration."

tkxxx7 10y ago
Agreed. PMs at my last job excelled at this. As a result, our "sprints" felt smooth and natural, and we always had time to eliminate technical debt.
nicoburns 10y ago
The PM's who have impressed me (as a dev) are the ones who have allowed me to talk to customers directly, so that I can have that exact same conversation.

mturmon 10y ago

"Learn the art of minimizing meeting length but maximizing their effectiveness." One basic tool here is to have an explicitly listed agenda for the meeting, with a first cut arrived at before the meeting. New topics ("walk-ons") can be added to the agenda in a discussion at the start of the meeting, or at the end if time permits. It's surprising how many 60 or 90 minute meetings are run without an agenda. If you run out of time (which is undesirable and should be corrected if it happens often) you can push items at the tail of the agenda to the next meeting. One job of the manager is to be sure all topics (not just pet topics) get their fair share of attention, and to move the meeting onward when needed.