Committing to your Experience (tasty dogfood!)
I came to a decision this weekend when I realized how, although I interact with Microsoft customers every day, and I try to bring features to Connect that are useful to customers and in line with customer perceptions...
Well, come down to it- I'm not a customer of Microsoft. I'm a customer advocate (among other things, developer among them), but I haven't really embraced the customer experience. For example, I've been running Windows Vista for some time now, although it's an older build- but I just installed it using MS' internal tools for doing so. I didn't have to copy a DVD or burn it, configure all my settings and go through much of the setup headache that customers have to- although I must say, Vista's a vast improvement over previous OS offerings in that respect.
I was going through some bug reports and I thought about the fact that customers have a different experience- not worse, necessarily; after all, my needs as a developer (and those of the Vista team) are different than a beta tester. But definitely different. For example, I can get the more frequent internal builds of Vista and see what bugs are still around or not. I can email a product team member- many of the team know me by name because we're working closely together on various Connect programs.
But that's not the same experience our customers have. And although I understand the experience we want our customers to have, if we want our customers should have a particular experience, I should be willing to share that. So I decided that if I'm going to call myself a customer advocate, I should pay more than lip service to it. Microsoft has a long tradition of dogfooding, so with all that in mind, I decided to take on the customer experience with both Connect and the beta programs on it.
Here's what I'm going to do, or do my best to accomplish:
- Use Microsoft Connect as my primary portal for filing and dealing with bugs. This is one I can't totally commit to, as I not only have to file bugs, I have to fix them. However, for filing bugs and tracking their status, if it's possible to do so through Connect, meaning that the product team or group has a Connect site and feedback is enabled, I'll do it.
- If a given product team or service has a site on Connect and has published bits, I'll use those bits, and refrain (except where necessary for my job, obviously) from using bits I have access to here. That means I won't be playing with internal builds, but only what's published on Connect.
- If Connect does something, or claims to do something, I'll use that. That means that if a download is published, I won't use it until I can actually download it from Connect, and not just the same version from the MS corporate network.
- Where applicable (and reasonable), I'll stick to whatever content/documentation is available to Connect customers and testers. I'll also communicate back to internal managers about issues like content and such.
I won't be able to do things with every beta site or program on Connect, obviously. And I'm not going to stick to these rules to the detriment of my job- if I run into a blocking problem and need a more recent build or update that's not released for beta, I'd use it if I needed it to do something related to my job (like say, fix bugs on the Connect site!)
But for stuff that I use- Expression, Visual Studio, Vista, SQL Server, BizTalk, OneNote, and more, or that I think I'd be interested in playing with (Robotics Studio!), you can bet I'll be participating.
So now I get to find out exactly how the other half lives... the latest Vista build on Connect just finished installing. Now I have to find the MBC and file a couple of bugs... ;)
