Windows Confidential: Living and Dying by the Demo
Sometimes it’s not user feedback or product requirements that drive which features make it into a new release.
Raymond Chen
“Sorry to cut your feature, but we ran out of time. If it wasn’t in the demo, it’s not in.”
It was one of the earlier versions of Internet Explorer. I believe it was Internet Explorer 4, but don’t quote me. There was a big event with thousands of attendees that showed off a preview of the new Internet Explorer, marking its first public appearance.
The product manager was there up on stage doing a big presentation, talking a bunch of “blah blah blah,” and using words like “super” and “awesome” and all those other superlatives Microsoft people overuse during presentations.
Naturally, a major part of the presentation was centered on demonstrating the new features. The product manager was up on stage running a preliminary internal build of Internet Explorer. Eventually, the presentation wrapped up. Everyone back at the mother ship breathed a sigh of relief when they heard everything had gone well. This, of course, was back in the old days before everything was streamed live on the Internet in high-definition surround-sound. The only way to see a presentation was to actually be there.
After the excitement of running a successful presentation wore off, everybody went back to the real work of finishing features, fixing bugs, running tests—all the usual stuff you do when building a product. One of the things you have to do when building a product is decide what features to cut, because, as we saw in April, cutting is shipping. Shortly thereafter, I was told the feature I had contributed had been cut.
Cut to the Chase
The reason my feature was cut wasn’t because it wasn’t a good feature, or because it was too buggy, or because it would take too much time to complete. The reason was much more mundane.
“Sorry, Raymond,” I was told. “We cut your feature because I ran out of time during the presentation and didn’t get a chance to demo it.” Because the feature was never demonstrated to the public, nobody knew it existed.
Therefore, the team could safely cut the feature without creating any waves on the public relations front. Cutting the feature from the final version would free up engineering resources that had already been assigned to designing, implementing and testing. Now they could be used to help design, implement and test the features that were actually shipping.
I wasn’t upset by this. It’s just one of the facts of life. If a feature is shown to the public, it’s very hard to change it in a significant way and even harder to cut it entirely. However ill-advised it may be, companies have already started making business decisions based on a 30-second excerpt from a 15-minute technology demonstration. In the public’s mind, the feature is already complete. I mean, you saw it with your own eyes there on stage, didn’t you? The guy said, “Internet Explorer 4 will do X.” Then he did X with Internet Explorer 4. That’s as good as a signed contract.
I was reminded of this story when Steven Sinofsky and Julie Larson-Green presented a brief technology demonstration at the D9 conference back in June 2011. People were making all sorts of predictions (and who knows how many business decisions) based solely on brief video clips taken by a hand-held camera.
“I know it’s a bit blurry, but if you freeze-frame the video, you can make out an album cover from Popular Band X on the Start screen. This is incontrovertible proof that Microsoft has entered into a partnership with Popular Band X to stream their music over the Internet.” Or it could just be a picture that was added to the screen to make it look pretty for the demonstration.
Anyway, back to the original story. What became of the feature that was cut because there was no time to include it in the demonstration? It did eventually ship in a later version of Internet Explorer. So the work wasn’t lost. It just had to wait a little while longer for its moment in the sun.
.jpg "Lafe Low")
Raymond Chen's Web site, The Old New Thing, and identically titled book (Addison-Wesley, 2007) deal with Windows history, Win32 programming and occasionally the city of Cleveland.