Wow, what a dry title!

Mary Jo Foley has continued the trend of Bloggers expressing indignation over how little Microsoft has said about Windows 7 (Windows 7: The information lockdown continues by ZDNet‘s Mary Jo Foley — When is Microsoft finally going to start sharing information on Windows 7? ).  I won’t comment directly on that topic, but I will comment on the overall topic of information release about future products.

When you are building a new product (and a new version is a new product) you have a plan for the release of information.  This isn’t specific to Microsoft.  Few companies comes out on day one and say "we are starting to work on a product, here is the delivery date, here are the features, and by the way on our web site you can view images of the napkins the chief designer wrote the initial ideas on last night when our team brainstormed this idea at the bar down the street".  Indeed, many startups operate in stealth mode and wait until they enter late beta before saying anything about what they are doing. 

In releasing information you try to balance several things:

1. Support planning by large enterprises who have multi-year rollout cycles
2. Give developers a large enough window to adapt their software for the new release
3. Minimize the disruption you cause by the inevitable changes that occur between releasing information and actually releasing the software
4. Figure out how to get the best marketing "bang for your buck" out of press coverage of your information releases
5. Drive customer and ecosystem excitement and readiness
6. Receive validation of your product plans and designs
7. Avoid giving your competitors an unnecessarily long time to react
8. Avoid the "Osborne Effect"

It can be a very delicate balance.  I won’t address all of the above, but how about a few.  Take #6.  Good input rarely comes from releasing broad swaths of information to large numbers of people.  It mostly comes from narrow discussions with very targeted audiences.  It comes from asking those audiences what their problems are, usually on a 1-on-1 basis, and perhaps bouncing ideas for addressing them off those audiences.   It comes from good listening to the broad set of voices out there who, with no prodding, give input on a daily basis.  You test your thinking in numerous ways that don’t necessarily reveal what is going to be in a release.  Or specific items are tested with small targeted audiences that both are uniquely qualified to give feedback and really understand the intent of the NDA.  Yes, once you start releasing information broadly you get additional feedback and validation.  But at best that allows for some fine tuning (or if you are way off, then it causes a major reset, there is little in-between). 

Hey, #7 is a real concern.  For example, in SQL Server 7.0 we started making a big deal of its self-tuning capabilities way in advance of release.  This resulted in both our major competitors initiating projects to respond a year earlier than they would have had we been quieter about this area until  launch.  One of them put a legendary developer in charge of the project.  We got a lot of mileage out of the early disclosure, but we also paid a not insignificant price for doing so. 

Take #2 and #3 combined.  If early information disclosure was of much value, Vista would have had the best driver and ISV software story of any OS ever at RTM.  I know developers who reacted to the early Longhorn information and bits, then found it too painful trying to keep up with changes over such a long period of time.  They stepped back and, unfortunately, many waited until after RTM to return to their Vista work.

The other one I’ll mention is #4.  In the good old days, meaning the 70s and 80s, saying anything about an upcoming product except under NDA was generally avoided until the formal announcement.  So there would be nothing public, and then (generally within 30-60 days of general availability) there would be a press event and everything about that product, features, pricing, licensing, etc. would be revealed.  There would be a huge amount of noise for a couple of weeks.  And then you’d focus on selling the product.  Announcing anything about a product much more in advance of its availability resulted in it being declared vaporware.  And dribbling out information meant you got buried in the back of Computerworld et. al. rather than making the front page.  Life was easy.  Starting in the mid-90s the dribbling mode became popular.  Now by the time the product ships and a "launch" event occurs, there is no news.  And if you stretch out the information flow over too long a period of time, all the excitement is gone by actual product availability and you have to struggle to re-ignite it.  I believe the pendulum needs to swing the other way and leave some actual news about the product for the launch event.  But then again, I’m not in marketing 🙂

What this all summarizes down to is two principles:

1. Need to Know – Information should only be communicated to those who need to know it, when they need to know it, and only about the specific areas they need to know about.
2. Any information disclosure not clearly covered by #1 is about driving demand and needs to be done thoughtfully as part of an overall launch plan.

Easy enough, right?  Only if you’re not the one making the decisions.