Product Launches
Launching a new process / application / software / widget is so much more than just the development of the actual widget.
Some companies have made this into an art form.
Google, for example.
I still remember the launch as it were, of Gmail. The excited chatter with friends about rumored acquaintances who had an invite. That thrilling instant message from a friend telling you they had an account and were waiting for their quota of invites. Then actually getting the invite yourself, and becoming part of the Gmail beta. (And the hilarious anti-climax of then having a very minimal, cool, and empty email account.)
Google has since launched so many other products, all in similar fashion and I have signed up for so many of them over the years (Google Reader RIP, Bookmarks RIP, Calendar, Drive, Blogger, Google+ etc although some have bit the dust or transformed since).
And this, I realize, has become something of a guiding philosophy in terms of how I believe a product should be launched.
I recently came to learn of this article, Slow Assimilation Works Best, which again captures so succinctly the philosophy of that first Gmail product launch.
This works out great in practice too.
Whether it’s a new process, a technology, a platform, an app - I’ve seen this process work out well every single time, and with lasting results. And, as noted in the article, approach#2 fails every single time.
Especially within organizations, the Big Bang approach, while exciting and satisfying, also necessarily means that several of the users this process was launched at were previously unfamiliar with it, and likely had no input in it, nor any concrete idea of what it solves and what it doesn’t solve (since no process or tool solves everything). Even with prolific post-launch communication, users will only remember that they got a new process or tool without context, and are now required to use it whether or not they want to.
The Soft Launch approach misses the benefit of a flashy introduction, but in every case, is satisfying to the developers since you get immediate, quality feedback on what could be improved, from an audience interested in providing feedback and qualified to do so, with the final product benefiting from this shorter feedback cycle. The alpha testers get the benefit of being the first to influence the product or process, and feel involved in the ultimate result, which as psychology tells us, can be a powerful motivator for buy-in.
Arti Annaswamy
Data analytics, process improvement, project management, coffee drinking