In one of the comments on my Community Can Be Cruel entry, Karl said:

One of the problems with custom engagement in the forms of these blogs is that it makes the customer believe he or she might be able provide input which will ultimately have an effect on decisions taken. While this may be true in some cases, it certainly isn’t in others. This isn’t anything wrong on your part, and I certainly don’t want you to stop, it’s just hard sometimes for the community to accept that decisions have been made and that our arguments via feedback are, at best, good theoretical debates.

I think Karl’s right that people end up feeling this way, and it’s something that is partially unavoidable and partially due to the way this product cycle has run. On the unavoidable side of things, there’s no getting around the reality that when a complete consensus cannot be reached someone ultimately has to make the decision. To take the example of the default instances debate, we really did listen to all the comments that people made concerning the feature and discussed them seriously. And, belying our Borg reputation, there was a lively debate internally about the feature, with people on all sides of the issue. This included people who, I should say, voiced many of the same concerns and objections that community members did. In the end, though, a decision had to be made and one choice among the many chosen. I know that when a choice is made that doesn’t agree with your opinions, and especially when those opinions are shared among others in your particular network, it can seem very much like your opinion wasn’t listened to or valued even if was taken into full consideration. We do our best to try and let people know that we listened and be up front about our reasons for taking a different course, but some difficult feelings are probably inevitable.

That aside, though, I think that there has been an extra level of angst about feedback this time around due to factors that aren’t inherent in the development process. The nature of things is that many product design decisions are made well before a beta ever ships. While we always can and do make changes based on beta feedback, the truth is that some decisions are hard to change unless they are caught very early because of the size or the risk the change would entail. Similarly, by the time that a beta is out most of the new feature development time has been used up, so feedback on priorities (i.e. “I want feature x more than I want feature y.”) can be difficult to react to, especially if the features requiring significant development investment.

The problem with the Whidbey cycle is that many of the community engagements that we’re now using to gather feedback (forums, blogs, MSDN Product Feedback Center) didn’t come online until later in the product cycle. I believe the product feedback center came online during Beta1. The forums are coming online in Beta2. Even this blog didn’t really get going until the winter of 2003/spring of 2004. What this means is that a lot of the feedback mechanisms that many of you are participating in now didn’t exist early on in the product cycle when many of the critical decisions were being made. This isn’t to say that there was no feedback – we have lots of traditional feedback channels that were being consulted throughout the cycle – just that many of the communities that are now plugged directly into the feedback loop weren’t there. That’s the bad news. The good news, of course, is that as we approach the dénouement of this release and start gearing up to look beyond, you’re all going to be right there from the beginning.

And, finally, there have been some interesting rumblings from my management chain about moving towards an even more transparent development process in the future. How this will play out is unclear to me, but I think there may be some interesting experiments in community engagement coming…