> -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 t

> -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."