As to the complexity level of problems, developers in Microsoft, who deal with coding, are probably taking one of the most challenging jobs in the world. But another engineering role, program manager, is not easier in any sense. Before I explain why, let me illustrate what typical product teams look like.
In the diagram, group manager often runs a team owning individual components or feature areas, say, one spell checker DLL in office; a product unit manager owns a product, say Outlook; while a general manager runs a product family, say Office. One compelling advantage Microsoft possesses is that its products are designed to work together seamlessly. For example, in a recent CIO.com article, 10 Reasons to Use Microsoft Outlook for Your Company's E-Mail, 8 of 10 points is actually about interoperability with other software.
Managers define strategy, Developers write code, testers test code, what do PMs do? Well, it is really hard to define - there is even no consensus within Microsoft. However, one thing is clear – PMs do anything except coding(unless they have to :-) to drive projects meeting strategic goals. Enable right things get done right. Figure out gaps and fill them. The role is something like concrete among brick walls. (cartoons on the right)
If you take a look at PM's position, blocks with black bold border, in the organization hierarchy, you will get the challenges here. PMs are supposed to lead their peers to work towards the right direction.
"You are not my boss. Why do I have to listen to you?"
This question gets down the topic of "Lead without Authority". Before you read along, I have to clarify that I am not a PM expert, but I (0) I've been a PM for quite a while, (1) work with great PMs, (2) learn and try most fundamental things which work well, (3) I faced similar situations for many many times, either in schools, or various organizations. Here is my sharing.