MVP Learnings: User Groups, Web Sites, and Feedback
User Groups
We do great at participating in our conferences, but we don’t focus on the breadth of developer user groups like we should. One of the better ideas was that we provide “presentation kits” to user groups. We create a topic and a talk with additional materials that could be distributed to a network of user group leads and then they could find people locally to give the talk after learning it. The biggest suggestion, however was how we get more MSFT people to talk at user groups. This led to me saying “you get 200 people in a room and I’ll send you Sara”. J
Web Site Envy
Having a separate site for Asp.net that’s really cool makes it look like we don’t care about other platforms or technologies because they have to use the uncool stuff. There are two components to this. 1st is that the Asp.Net team has done a great job investing in content that draws people to the site. Other teams could do almost as well just be taking real ownership of their developer center on MSDN.
The second component is the site features. This is a gap that everyone is well aware of and we’re working on closing that gap and going beyond what’s on Asp.Net site. MSDN will become a 2-way street for content where real online community occurs.
The bonus would be that that ideally we can offer centralized services that allow anyone to easily create a focused short or long term site on a specific technology.
I’ll add that MSDN took a LOT of abuse at these sessions that ranged from broken links, to page load times, to the lack of updates, to the lack of functionality for a modern developer community.
What about that feedback?
There were two complaints here:
1. Customers may get an initial reply soon, but then they wait 9 months to see a resolution or a status of the bug changing. What’s happening for that 9 months? Is connect a black hole?
2. One MVP had submitted lots of bugs and had 80% of them fixed. Another had submitted a lot of bugs and didn’t have any of them replied to. ‘
Is the problem with the team that they filed the bugs against or with our communication? I think it’s both. Some teams do MUCH better than others at replying to customer bugs. We’ve tried to goal teams on this and create a consistent experience, but some team’s just haven’t drank the customer kool-aid just yet. I won’t tell you who just yet, but I may start posting our stats more frequently so you can see how we’re measuring teams.
Finally, and I’ve said it before, we need to do a better job of telling you what bugs we are fixing. We do fix a LOT of customer bugs, but it’s not even easy to do a query on those bugs. We should be telling you what gets fixed, when it was fixed, and in what release it’s been fixed.