Developing and releasing a Version 1.0 product at Microsoft is a near herculean task. Many great minds representing different disciplines with differing perspectives and agendas need to come together and agree that the software code is production-worthy. Comparatively speaking, subsequent versions are much easier to get out the door. After releasing Version 1.0 on June 1, 2001, we hoped our "showcase" customers would welcome the product with open arms......
Alas and alack, the downward spiral in the economy was taking its toll on our "showcase" customers. Slowly but surely, as the fiscal angel of death descended on their houses, one by one they started backing out of their commitments to us. We used this time of uncertainty to refine our product, even enhance it with some new features, and tweak it into the best possible state. We released Version 1.5 at the end of October 2001, thinking surely that would entice our customers to sign on the dotted line. We were all proud of the little plaque to attach to our Ship-it Awards, but the victory still seemed a tad hollow without real paying customers using our product. We continued to refine, enhance, and tweak, adding what we thought were surefire customer pleasers like PVR (personal video recorder, also referred to as DVR, or digital video recorder) features, and VOD (video on demand) features. We all worked smarter and harder and long into the night, hoping against hope that the business development and sales staff would garner design wins and customer satisfaction. Sadly, by the time we released Version 2.0 on April 19, 2002, the writing was on the wall. Not a single shipping, paying, customer had been won. The few customers remaining wanted yet more tweaks before they would consider the product ready, and frankly speaking we were all quite worn down.
To turn things around, a new executive was brought in to lead the future vision. We focused Version 2.0 on the last remaining hopeful customers in Europe and Latin America. We ramped up the staff for a new thin-client product for North America, and soon we were fastly and furiously specifying new features and roadmaps.
Finally, after much customization work, we signed paying customers in Europe for Version 2.0. Soon after that, after a complete overhaul and even more customized engineering development, we signed paying customers in Latin America. At long last, we felt good about what we had accomplished - a real product into paying customers hands. Life was good...... And still fresh development continued on, for the new thin-client product. We had high hopes that would really capture the hearts and minds of a much larger customer base. Customers are, after all, the main reason why products are developed, are they not? At least that's what I'd like to think.....
I learned many lessons during these years. As engineers we often overlook the changing customer landscape, but we do so at our own peril. A great product without a customer base can not really be that great. Even if we create the most intricate, elegant, software solutions and provide compelling products and services, if we don't have the ability to market and sell them to real paying customers, our efforts are for naught. Ultimately, customer satisfaction is at the heart of a success - develop the right product for the right customer at the right cost and at the right time, and you'll have a winner, with many customers coming back for more. Develop a whizbang technology just to show you can, and it may be a minor footnote in the dusty annals of some arcane museum somewhere. "Build it and they will come" only works in the movies. At least that's my story, and I'm sticking to it.....
Friday, November 26, 2004
Ship-it Awards
When I was there, Microsoft had this really cool way of recognizing organizations that released **real** products to **real** customers. It was called a Ship-it Award. Maybe they still continue this practice, I hope so because it was a good one. Everyone who participated in the product development and market launch of a Microsoft product got one of these things. Mine has a nice grey marble base, with two black obelisks rising out from either side, with a glass etching in the center. The inscription on the glass reads like this:
"Every time a product ships, it takes us one step closer to the vision: empower people through great software - any time, any place, and on any device. Thanks for the lasting contribution you have made to Microsoft history."
Bill Gates' signature is below the inscription, and a small bronze plate with the employee name is under that. On each of the black obelisks, the employee is encouraged to put the 25mm-by-40mm aluminum plaque containing the name of the product, the version number, and the release date. I'm sure the Ship-it Award's verbiage and appearance evolve over time, but it is still an inspirational tool for employees. In fact, when people interview, they are often asked how many Ship-it Awards they have, an indication of how many development cycles they have worked through. I still keep my Ship-it Award on my desk, right next to the Sony plaques I alluded to in a prior blog posting. My Ship-it Award reminds me of the four years I spent working at Microsoft......
After Release B, we were on a good roll. The technical teams started gelling very well together, and everyone knew we were on to something good. The program managers spec'ed out all the features and APIs for the next release, getting buy-in from the software developers, test engineers, and marketing folks. The software developers coded the modules and subroutines necessary to support the marketing requirements. The test engineers performed quality assurance on the deliverables from the software developers, and when bugs were found everyone collaboratively resolved them one way or another. Some bugs need code modifications, others needed documentation changes, while still others were deemed not likely to occur in the real world, and yet others were left for future discussions.....
Finally, on June 1, 2001, we completed everything necessary and signed off on Version 1.0 of our product. True to form, just as we had hoped, the next release after Release B was production-worthy, so instead of calling it Release C we called it Version 1.0. We were so happy, ecstatic in fact! It had been a long haul - some of the engineers had been working on this product for a few years. It was very satisfying and gratifying for all of us in development. We only hoped our customers would be as ecstatic as we were. The customer landscape was changing, as the economy was diving deeper and deeper into recession, but we fervently hoped that our "showcase" customers would welcome our Version 1.0 product with open arms......
"Every time a product ships, it takes us one step closer to the vision: empower people through great software - any time, any place, and on any device. Thanks for the lasting contribution you have made to Microsoft history."
Bill Gates' signature is below the inscription, and a small bronze plate with the employee name is under that. On each of the black obelisks, the employee is encouraged to put the 25mm-by-40mm aluminum plaque containing the name of the product, the version number, and the release date. I'm sure the Ship-it Award's verbiage and appearance evolve over time, but it is still an inspirational tool for employees. In fact, when people interview, they are often asked how many Ship-it Awards they have, an indication of how many development cycles they have worked through. I still keep my Ship-it Award on my desk, right next to the Sony plaques I alluded to in a prior blog posting. My Ship-it Award reminds me of the four years I spent working at Microsoft......
After Release B, we were on a good roll. The technical teams started gelling very well together, and everyone knew we were on to something good. The program managers spec'ed out all the features and APIs for the next release, getting buy-in from the software developers, test engineers, and marketing folks. The software developers coded the modules and subroutines necessary to support the marketing requirements. The test engineers performed quality assurance on the deliverables from the software developers, and when bugs were found everyone collaboratively resolved them one way or another. Some bugs need code modifications, others needed documentation changes, while still others were deemed not likely to occur in the real world, and yet others were left for future discussions.....
Finally, on June 1, 2001, we completed everything necessary and signed off on Version 1.0 of our product. True to form, just as we had hoped, the next release after Release B was production-worthy, so instead of calling it Release C we called it Version 1.0. We were so happy, ecstatic in fact! It had been a long haul - some of the engineers had been working on this product for a few years. It was very satisfying and gratifying for all of us in development. We only hoped our customers would be as ecstatic as we were. The customer landscape was changing, as the economy was diving deeper and deeper into recession, but we fervently hoped that our "showcase" customers would welcome our Version 1.0 product with open arms......
Release B
During the summer of 2000 in Microsoft's interactive television group, things were abuzz with anticipation. Our main customers were impatiently waiting for the production version of our software for high end set top boxes. Some months before I arrived, the head of the organization had promised everyone a trip to Hawaii if they released the product on time. They didn't, and now the engineers and business development people were anxious to put the finishing touches on the product and proudly roll it out the door. Release B was a step in the right direction.
At first I was aghast at all the different versioning schemes the group had invented as the delays rolled way past the customers expectations. It seemed so patently transparent, who did they think they were fooling? They tried several flavors of Alpha and Beta to whet their customers appetites, but none were really ready for prime time. Then they tried Beta 1, Beta 2, Beta 3 to indicate they were getting very, very close to production-worthy code. When I arrived on the scene, they had just transitioned over to yet another new nomenclature - the alphabet - and had just released Release A and started working on Release B. I worked with the leadership to instill more engineering discipline into our processes, and create actual meaningful definitions for milestones. Up until now, there really wasn't great concurrence between the various technical disciplines (development, test, and program management) about crisp definitions on things like entrance requirements and exit criteria for milestones. The creative geniuses who held great sway over the organization felt that software code would just dribble out whenever it was ready to dribble out, and I felt that was a hell of a way to run a ship. So for Release B, I was determined to make milestones meaningful.
And so it was. Eventually, we were able to broker agreements between the disparate groups, and everyone worked long hours until finally, in November 2000, we happily signed off on Release B. We held release parties, and patted ourselves on the back- visible progress! We felt we finally were closing in on the last mile. We felt if we followed the same disciplined approach, the next release would be production-worthy. Finally, after so long, a product our customers could put into production use was just one more release away..... if only we could continue to agree with each other, stop internecine bickering, and all row the boat in the same direction...... we could see light at the end of the tunnel, and we hoped it wasn't an onrushing train.
At first I was aghast at all the different versioning schemes the group had invented as the delays rolled way past the customers expectations. It seemed so patently transparent, who did they think they were fooling? They tried several flavors of Alpha and Beta to whet their customers appetites, but none were really ready for prime time. Then they tried Beta 1, Beta 2, Beta 3 to indicate they were getting very, very close to production-worthy code. When I arrived on the scene, they had just transitioned over to yet another new nomenclature - the alphabet - and had just released Release A and started working on Release B. I worked with the leadership to instill more engineering discipline into our processes, and create actual meaningful definitions for milestones. Up until now, there really wasn't great concurrence between the various technical disciplines (development, test, and program management) about crisp definitions on things like entrance requirements and exit criteria for milestones. The creative geniuses who held great sway over the organization felt that software code would just dribble out whenever it was ready to dribble out, and I felt that was a hell of a way to run a ship. So for Release B, I was determined to make milestones meaningful.
And so it was. Eventually, we were able to broker agreements between the disparate groups, and everyone worked long hours until finally, in November 2000, we happily signed off on Release B. We held release parties, and patted ourselves on the back- visible progress! We felt we finally were closing in on the last mile. We felt if we followed the same disciplined approach, the next release would be production-worthy. Finally, after so long, a product our customers could put into production use was just one more release away..... if only we could continue to agree with each other, stop internecine bickering, and all row the boat in the same direction...... we could see light at the end of the tunnel, and we hoped it wasn't an onrushing train.
Subscribe to:
Posts (Atom)
