Recently several external people have asked me what Program Manager in Microsoft do and what I do. And I have decided to put one post on my blog with answers to both questions. Let's start with discussing what Program Manager within Microsoft actually is and what it does and then briefly talk about me specifically. First of all, based on my experience of talking to PMs in Microsoft, if you ask 10 PMs what they are suppose to do, you are most likely getting 10 different answers. However there are common patterns which together form a picture of this position. I have started with searching web for any previous discussions. And there are several interesting posts already on the web that talk about PM in Microsoft in details.

Most referenced post is from Steven Sinofsky's Microsoft TechTalk named PM at Microsoft from 2005/12/16. It is long read with a primary focus on "Technical PM" role. Feel free to read it all, but to summary, here are key takeaways:

• "The job title "program manager" is a bit of a misnomer, since program managers do not program nor do they manage." This is very true. We do not program. From my experience, I have developed only one piece of real code that is still checked in Visual Studio source tree. I did write many lines of code that went into demos, samples, etc, but those do not count. And PM does not manage people unless she or he is a manager of Program Managers, of course.
• "PM is one equal part of a whole system." This ties back to "nor they manage" part. PM is just part of the team who has very specific job responsibilities and contribution to the overall success of the product.
• "Program Management [was created] with the explicit goal of partnering with development and working through the entire product cycle as the advocate for end-users and customers" This is still very true and remains very crucial part of a PM job. PM always has to stay focused on the value of the work to the customer. From my experience, once you lost this focus, the final result is not going to make customers happy, which in turn does not make you or your team happy.
• "PM … focus on the big picture of "what are we trying to do" and on the details of the user experience, the feature set, the way the product [gets] used." Or as one of my manager used to say, PM has to see forest behind trees. Understand why we do what we do, and what is next and why.
• "Phases to program management: learn, convince, spec, refine". The key point is not said in clear here is that PMs constantly go through these phases non-stop. Every day and many time several times a day new problem shows up on your screen. You have to learn, understand, think of solutions and propose one in a written document or verbally.
• "Learn --> [Inputs of learning are customer problems, products and technologies out there]. Output of learning is a prototype". This is the most fun part of a PM job. You get a chance to talk to people who actually use the product. You hear problems, you analyze problems, you think of solutions. Usually you talk to all sorts of people outside of your team and in your team. You fly to conferences, read articles, blogs, emails, bug reports, talk to people again, talk to devs, testers, leads and managers. You have to list all problems and all solutions you can find, and attempt to propose a solution based on pros/cons, time, cost, etc. And at the end of the day, there is a proposed solution and/or prototype that preliminary seems like a good thing to do.
• "Convince --> [Input of convince is the proposed solution.] Output of convince phase is a plan and goals" This is a challenging part. Here where a PM has fun to hearing everything bad about the proposed solution and other better solutions not considered originally. You eventually ended up tweaking solution to find middle ground such that everyone is willing to support the plan and the goals going forward.
• "Spec --> [Input of Spec is the plan with the list of areas for specing.] Output of spec phase are a series of written specifications" The specification is really general term in PM job. For features and product, it means official document following official template. Many times it is less official document that describes the solution. Overall this it is basically a document that answers on 4 questions - Why? What? When? And How?
• "Refine --> [Input of Refining is the plan and specs]. Output is the product" This is a constant loop where you go back and force from original plan to deliverables and tweak plan or deliverables until product achieves level of quality that meets expectations of majority of customers. Actually based on my experience, this is where we spend most of our time. PMs are focused on two things: managing change and managing scope. With change, we must understand impact of this change on schedule, cost (resources) and scope of the final product. With scope, we have to check, double check and repeat the check again to ensure that the final results of the team's work are actually what were planned for and it is still what customers are waiting for.

Now Steven Sinofsky's post is not the only one that talks about PM in Microsoft. There are several others, I am listing them below.

• Nice picture of what PM does at Mike Deem's blog, http://radio.weblogs.com/0105395/stories/2002/03/27/whatIsAMicrosoftProgramManager.html Not sure why PM face is not a happy face. We actually have no choice but being very happy when dev, test and customers are happy about the current release and plans for the next release.
• Interesting summary of an interview with Cynthia Solomon, former PM for Excel, http://www.stcwvc.org/galley/0209/b01prog_management.htm. Similarly to Steven's post, she stresses out writing functional specs, usability and managing implementation without managing developers and testers who actually develop the feature. This is true to say that "the lead without authority" is a synonym for the PM in a team. Very hard position to be in actually.
• Series of PM Tips on ASP.NET Team blog, http://weblogs.asp.net/aspnet-team/archive/tags/Program+Manager/default.aspx.
• Post on Program Managers @ Microsoft on Microsoft JobsBlog. Nice overview of what HR looking in candidates for PM position. What I have found amazing is that the author of the blog says that "Project Management is just one small skill that [she looks] for when talking with potential PM candidates" and that "We are usually not looking for straight up project managers". And this is after she lists 5 core skills of a project manager – gathering and analyzing information, decision making, building relationship with customers, communication skills, work across groups. Perhaps what she thinks of "Project Management" being a schedule management. I believe, this is what she is trying to clarify with the sentence where she mentions Microsoft Project. I hope they do hire great project managers, because being a PM in Microsoft is just about being project manager on many projects with one area of the product.

Speaking of my job specifically, description of a PM job in Steven's post is very close to what I do. Both in Visual C++ and here in Windows Core Networking, I am a technical PM working with a group of developers and testers on a part of the bigger product. It used to be Visual Studio now Windows. My time is spent between the 4 phases outlined by Steven. Sometimes I am more focused on a particular phase such as learning or planning. I talk to customers and partners on regular bases. Learn about their problems and work with my team on finding solutions. In VC Libraries, I used to own all functional specifications and design documents for features in the product. In my new team, I own the functional spec and only reviewer of design document and other documents. This is expected considering that I am relatively new person to the team and climbing learning curve on details surrounding technology in this product. I do manage the schedule, any changes to the schedule and scope, and track progress on schedule and scope completion. Hopefully sometime soon my team can start talking about features we are building to external customers. At that time I will shift focus to building presentation and demos for conference and meetings with external customers. Until then, we are in "refine" stage of the product cycle and this is what I do on daily basis.

At this point I feel I have answered both questions. Hopefully the answers are complete. Let me know otherwise. As I find anything else to add, I will just add it to here.