I just happened across this blog post from Randy Holloway (http://weblogs.asp.net/rholloway/archive/2003/11/04/35707.aspx)
I’ve been thinking about this from a slightly different perspective. As we do a better job in being open with information about upcoming products, responding to feedback, getting bits out earlier, I wonder how it impacts our “special” customers – MVPs, RDs, writers, trainers.
The perspective I’ve been thinking from has to do with “privileges”. Think of a spectrum with MS-internal at one end and the public at the other. As you move from internal to public, you have fewer privileges. Internal people can read/write product functionality from day 1, the public gets to read it historically very late in the dev cycle. Same with things like specs, bug reporting, etc.. “Special” customers (sorry, I can’t think of a better word – best isn’t right, top – vs. bottom?, influential – sometimes) fall somewhere in the middle of the spectrum, with more privileges than the public but less than most internal people.
In many ways what we’ve done in recent months is taken the privileges that “special” customers had, and make them public. We’re being much more open about product features, we’re moving towards making pre-release builds publicly available, etc.. And I don’t think we’ve replaced what we’ve “taken away” from this group with new privileges that only internal people had before. (Although there are a few examples, for example there are C# MVPs contributing to the C# FAQ on the
I’m currently assessing our community priorities for the next year, and I think addressing this “special” class of customer is one of them. Some of the ideas we’ve talked about include:
- moving more internal privileges over, e.g. maybe MVPs can see test cases (or if everyone can see them, MVPs get read/write access)
- being more responsive. Presumably, as we give people better mechanisms for contacting us, submitting bugs/suggestions, etc., we’ll get to a point where we have to prioritize/triage who we respond to first. We could consciously be more responsive for this group.
- Giving people roles in implementing some of the more challenging ideas. For example, I posted earlier about possibly having MVPs vote on daily builds, to give customers more information when trying to decide whether builds are worth installing.
These ideas are mostly MS-centered though – how these people can be involved in what we’re doing. I'm excited about them, and we’ll do at least some of them. But Randy’s post helped me recognize how MS-centered I was being. What are the ways that we can help these customers be more successful? These are incredibly capable people and I want to make sure they continue to have opportunities around MS products and technology (so they don’t go Elsewhere). Here’s one random idea along those lines – they get to have MS personnel accompany them on a sales call (or at a training), no-questions-asked, once a year. I’m sure people outside can come up with much better ideas than I can though, hence the post.
So, at a broad level, here are the two questions:
- has the openness (what Randy called The New Microsoft) been uniformly positive, or have there been unintended/unforeseen negative consequences?
- When bits/info/contact info are generally available, what other things can we do to make MVPs/RD/trainers/authors successful?
P.S. I apologize if you’ve tried to contact me in the past few weeks and I’ve been unresponsive. We went on a two week driving trip down to Joshua Tree National Park, and I’m just digging out. That’s a very cool place, and really fun after my sons realized that stepping out of the car didn’t mean instant rattlesnake bite/scorpion sting. I’d love to spend a couple months climbing there sometime. This time I got to do just enough to get scraped knees and remember how important getting my forearms in shape can be. I also stumbled upon the Gram Parsons “memorial”. I knew it was there somewhere but I literally happened upon it wandering around one of the rock formations. I wonder how many grievious angel fans are reading this - can't be many 🙂 ...