My Week at Developer Product Support: A Prelude

I’m going to post a few entries on the week I spent with the Developer Support team in Issaquah, WA.  This entry is meant as in introduction to this series.  The next few entries will try and capture what I learned.

Microsoft has a program for employees called “Frontline”.  In this program a member of a product development team will spend one week at a product support office and one week in the field working with customer’s onsite.   I recently went through the first week of this experience. 

The reason I went through this program is because it’s one of my goals in the next year to get PSS more involved in our modern developer support communities.  It might surprise you to learn that PSS is actually not goaled on any sort of involvement with our Product Feedback center or our peer to peer support forums on MSDN.  These community resources have been completely owned (not in the code sense, but in the replies to customer sense) by the members of the Product Development teams here in developer Division. 

In the past Microsoft has had a “fire and forget” model to our communities.  We release a product, throw up a newsgroup, and call it good.  Today we are actually holding teams accountable to the health of their communities.  This is a good thing, but they need help doing so.  

The goal is not to transition ownership 100% to our product support folks, but rather to realize how people request their product support is different today than it used to be.  Modern customers would prefer to file a bug, ask a question online, or blog about their issues as opposed to picking up the phone.  However, what’s missing is the actual “supported” part of those experiences.

If you need a hotfix ASAP… you can’t get it today after you file a bug.  Similarly if no one in the community can answer your question online… you can’t escalate that question to official product support.  In both cases you have to pick up the phone and lose all the context and effort you had already put into solving your problem.  There’s no great connection between our resources. 

Before I started my week at PSS the secondary reason for wanting to engage support in these new online channels was that, for released products, maintaining high quality answer rates to these issues is not a job that the dev/test/pm members of Product Teams are trained for or given the time in the schedule to do... they have day jobs.  Certainly we, in the product groups, have a responsibility to transfer our knowledge about the products to our customers. This is especially true in the CTP through the first 1+ years a product has launched.  

The PG only model starts to break down in the 2-10 year period where the bulk of customers have actually adopted the new product and you hit the extended support wave.  Dev, test, and PM resources start moving onto the next product before the one in development has even shipped. That means that their level of knowledge on a product like VS 2005 is fading fast.  Add attrition over a 5-10 year period and before you know it there is only one poor soul left in the product groups in 2015 that knows anything about how VS 2005 actually works.  This is the period where several of our “community” efforts have floundered that we’d like to avoid moving forward with a shared PG/PSS community support model. 

So, with that rant completed, I’ll start posting about what I learned in my week at PSS and how it’s helped to shape my ideal vision of tomorrows support world.