Two weeks ago, the Wall Street Journal posted a freaking good article on "How Steve Jobs Played Hardball In iPhone Birth" with Cingular (now AT&T). Shall you have only 30 seconds before you, you can get the flavour of this article by reading the Quoted section here in one of my favorite daily newspapers : Good Morning Silicon Valley.
I ain't comment on the iPhone' s multi-touch user-interface enabling a new revolution (it's well done here ), Steve Jobs being a genius (read here and here) , or Apple playing a giant chess game against Microsoft ( here, here, and here - and more).
Actually, the most interesting part to me is this one (at the end of the article) :
Usually, carriers catch more than a glimpse of the products their handset partners are working on. They get to provide input on what applications or features might make the device more marketable.
Not this time. Several small teams within Cingular worked on the project, but each handled its own specific task without knowing what the other teams were up to. Employees had code-names for the project to avoid mentioning Apple by name, says a person familiar with the matter.
Cingular sent a team of technical personnel to Apple's offices to test the device, making it sure it would work on the carrier's network. That rigorous process is normal for the release of any phone. But this time, technicians weren't allowed to handle or see the actual phone. Instead, they were given access to a dummy version that would only allow them to do the necessary network tests.
I was suspecting Steve Jobs and his team to use such secretive technics during the development phase of their strategic new products. Why that ? Simply because it happens that I had a similar idea back in the early 2K's at Agilent Technologies (nope, I'm not saying that I'm another Steve Jobs : there is no other Steve Jobs ;-)
At this time, we were to develop a brand new product, strategic for the future of our business unit. As a member of the Apple Developper Connection program, I was used to the methods the Cupertino firm put in place for Mac OS X (the 10.0 release) : regular beta seeds, beta testing program, feedback collection, etc. Hence the idea to use the same process for our new product : create a beta testers community, send them each new build of the firmware, get them engaged with the product development timeline, etc.
More : to avoid leaks - the Telecoms world is a small world... - I wanted to get the applications (i.e. the core value of this new product) tested by separate individuals, in such ways that no one would know what the others were doing. Also, using a fake hardware was planned, so nobody would learn about the real thing - see here : this product features a stunning design still unmatched by its rivals, five years after its official launch...
Unfortunately, we couldn't implement this program : our product didn't run under MS Windows or any of the commercial OS at this time (not speaking of Linux or Mac OS : the Test & Measurement industry is living in a MS Windows world...). So, we were simply unable to get people outside of the company to test a single line of code. Kind of Mission:Impossible made really impossible !
Today, the landscape is totally different. The emergence of the Web 2.0 has changed the way we can develop new applications, even those to be implemented onto a fiber optics test handheld. Design your app as a Web-based one, and you're done : APIs, widgets, snippets, etc. It's all there, available, and easy to deploy, test, and use. That's what Apple did with the iPhone, by the way : consider each function (e.g. phone, internet, camera, etc.) as an application per se, then consider it as being called as a widget... Assign one guy or one team per widget, and you reach the ultimate secrecy level : nobody will know where this stuff is going to be implemented, and how it will be used !
Actually, I will use this proven method with the developments at Testing 2.0.
