During the implementation stages of the product cycle, Program Managers at Microsoft are often described as the glue that holds the product team together.  We are responsible for making sure that the different disciplines within the C# team are working well together towards common goals, and that our team is working well with the other groups we depend on or that depend on us.  At this stage of the product cycle, PMs also work in concert with Dev and QA leads to drive the bug triage process.  This is where we make the tough calls to maximize the product quality, WHILE maintaining a schedule, AND ensuring that we are shipping a compelling developer experience to our customers.  Sound tricky?  Check out one of MS Build’s triage meetings that was recorded a couple of months ago to get a behind the scenes look on how these meetings are run.

So when dealing with something as complex as shipping a new version of Visual Studio, how do PMs stay sane?  We prioritize.  Without a list of priorities that we can all march towards, chaos ensues.  Given that the product cycle is so fluid, we often have to refresh our priorities from one month to the next or even from one week to the next.

So here’s what the C# PM team is focused on for the next several weeks:

1)      Support the Whidbey Security push.  As you may have seen in Soma’s or Natalie’s blog posts, at this phase of the product cycle we are driving hard to ensure that our product is secure through reviews, threat models, automated scanning tools like FxCop and PREfast, and extensive testing.  PMs are keeping the team focused on security and making sure that any/all issues that are discovered are absolutely locked down.

2)      Bugs.  Triaging bugs, investigating bugs, and closing bugs.  Typically when bugs get assigned to PMs, it’s because the desired behavior is unclear or has side-effects that were not originally considered in the specification.  Thus, until PM is able to articulate the correct design for a scenario, devs are blocked from fixing it.  So it’s important that PMs are efficient in resolving their bugs so we are not a bottleneck to the rest of the team.

3)      Developer community engagement – hit monthly objectives.  One of my goals as the GPM of the Visual C# team is to make community engagement part of the culture of the PM team so that it’s a natural extension of our everyday jobs.  In some ways we are making good progress towards this, and others ways we have a long way to go (look forward to entire blog posts on this subject).  Until we are all living and breathing community so that transparency just happens naturally, we are going to “attack” the problem in the classic PM way – set time-sensitive goals, measure ourselves against those goals, and iterate until we get better.  Every PM has areas that they are focused on (examples include MVP interactions, chats, forums, etc.).  We are going to continue to raise the bar in each of these areas so that we can tighten the loop with our community and as a result build products that delight our customers.

4)      App. Building.  One of the most fun parts of the job – we take a week, organize into teams, and build applications using the product.  This is a great opportunity for us to see how well all the pieces we work on actually end up fitting together, and get broader perspective on how real world users experience Visual C# and the debugger from end-to-end.  Additionally, it has the nice side-effect of us discovering some of the more elusive integration bugs by banging on the product.

5)      Whidbey presentations and demos.  We have a lot of presentations and conferences coming up this year (it’s always sooner than you think), and we so many awesome features and scenarios to present.  This is good time for us to start pulling together our slides and demos so that we can do a great job showing off our baby. 

If folks are interested, I’ll periodically update you all on what we’re up to.  Let me know!