Why corporate blogging works...a riff

I have to hand it to my man Hugh at Gapingvoid.com - he can sum up the spicy essence in clear cartoonery.

I do actually disagree with him in one way, which is that he feels A - the company's internal dialogues, rants and mumblings and B - the public's dialogues, rants, and mumblings - have to be identical. I'm all for the porosity of the membrane between the company chatter and the customer chatter, and the need for conversational alignment such that the companyspeak  is not drowning out the outside wisdom gab, nor discounting the talk outside.

But I think there are times when either a variance is healthy or inevitable given the circumstances, and that's ok. I mean heck, you can't get bloggers inside Microsoft to agree all the time - why the heck would we innately agree with anyone outside? Some problems have no clear answer, or, the answer is an evolving one that requires everyone to listen, but not to agree at first blush. Sometimes it's not my way, nor your way, but the 3rd way we are figuring out together. If the chatter inside Microsoft helps you figure out something in a new way, that's great. If your focus on something helps us get our act together, that likewise rocks. But we may not always be in sync all the time.

For example, take the other thing that keeps me at Microsoft late: Gotdotnet. Believe me, I listen to each and every one of you who emails the GDN feedback email. But if I aligned our  internal self-talk with the worst customer griping, we'd all be in therapy over here. And who can afford that?  Sometimes you have to imagine before you can build, and sometimes you have to kickbox through molasses to a better Web site: Workspace errors more than halved over the last month.

I'm sure a number of people, inside people and outside people, wanted to smack me the last three months (especially when I went off the deep end and started singing).  I've had very "thoughtful" people around the company send me emails where yet another appalled customer laid their head down, and yea verily, wept upon their keyboard that Workspaces were not working for them again. Lo, the valley of despair. And when it doesn't work, it sucks, and I'm with you. But really, the customers can afford to be faint of heart over there - we bugfixers can't. There's a point to the KoolAid - only in generating the optimism to make stuff better, not in the hands-over-ears sense of not listening.

There was an interesting comment appended to the GapingVoid post, which was this description of using wikis as an intermediary to parse blog information.   I'm finding myself agreeing with the fellow from Macromedia in terms of noting that gettting the customer feedback to the internal people who can use it is a different problem space than demonstrating to the public that the feedback was heard. You could have a lame wiki response and a killer product response ("complete with every feature you asked for!") and the wiki dullness would belie the listening. Likewise, the product team could ignore the customers but the wiki make it seem, sleight of hand, that the company was doing everything. Speaking as someone who was around when the MSDN Product Feedback Center was built, those Visual Studio folks really hustled on the inside. The MPFC apparatus is better perhaps for signaling when a bug got handled or listened to, but it was also tons of work to both DO and SHOW.

The other thing is that both the wiki and the blogs are hampered by the same bottleneck: search. If your search methodology isn't killer, your wiki audience is going to be struggling to find wiki pages just like they hunt for the relevant blog entry. With a nod to MSDN's Justin Grant, who has long bent my ear on the search problem, bad search can really hamper community flow.

So I'm not quite on the "filter blogs through a wiki" bandwagon. But it's been a good riff nonetheless.