Developers, community and Microsoft

A week ago I took a new job running the team that is driving the Developer Division's community efforts for Visual Studio and the .NET Framework.  (I planned to write this in my first day in the job, but promptly got pretty sick and just returned to the land of the living). 

Jeremy Bostrom (in our team) recently asked some questions about what people are looking for (here: https://weblogs.asp.net/jerbos).  I thought I'd explain a bit about how we're viewing our community work.  I'd love feedback, as I'm just getting up to speed and would love to be informed by the opinions of people outside the company.  Also, if you have suggestions on what to study, read, view, etc., fire away.

The MS community efforts fall in 4 main areas:

1) MS Participation: MS has grown big enough (or just big) that it's been easy for many people to do their work without ever having a personal interaction with a customer.  There has been a very strong focus in our division in recent months on ensuring that every person has some contact with customers every month - newsgroups, going to conferences, helping respond to customer bugs/qfe's, etc..  Hopefully you've noticed an increased presence in newsgroups, etc..  We still have a lot of work to do here.  The bet is that people who have had first-hand experience with customer questions/confusion/pain will do a better job prioritizing what matters and building products that really work for people. 

2) Engaging key people outside of MS:  We recognize that we can't do this alone, and view the many key people outside (e.g. Microsoft MVPs) as an essential part of building a strong community.  We are more conscious about involving this group early on in the development process.  Again, we can do a lot better still.  I'm actually curious on one thing here - does our work with key people (e.g. inviting them to a design preview) support the general sense of community, or does it give “non-key“ people the sense that we somehow care less about them?  That's absolutely not the intent. 

3) Responding to feedback:  We want to make sure that when people have ideas or report bugs, we close the loop and make sure there are clear responses.  I interpret this one fairly broadly - there are a lot of things we can do be more transparent and have our relationship with customers be more two-way, including better tracking/closure on bugs, more frequent access to builds, doing a better job of ensuring that customer-reported bugs get fixed not postponed, etc..  While we've made some progress here, look for us to do much better in coming months.  There are a lot of people outside the company who invest in helping us ship products and we want to ensure a) we (including our customers) are getting the full benefit and b) that these folks feel like their investment is valued here. 

4) Product integration:  We want to make sure the community resources are readily available to people using our products and that the line between what we ship and what is available in the community blurs some.  For example, if someone needs a sample on how to do something, they'd probably like to see both the samples we shipped in the box and whatever the community has developed.  We're just at the beginning on this one. 

As I say, we have a lot of work to do.  I'm excited about being part of it.  If you have thoughts, ideas, gripes, please let us know.  In future posts I'll tell you a little more about me and more about the kinds of things we are considering.