Google has a long history of releasing services early in their life cycles. From the famous Gmail beta that lasted over five years to the services and extra features in Google Labs, almost everything they make is released to the public in an early state and then polished over time.
Product Betas Are Great
Why release a product before it’s fully finished? First, you get your foot in the door with an early chance to snag customers and buzz. Future competitors will have to be superior in every way to convince your existing users to migrate to the new system and familiarize themselves with a different product.
Also, beta users will help you test features and find bugs. Early adopters tend to be more forgiving with rough edges in a new product, and are often willing to help out with bug reports and other constructive feedback in return for receiving early access.
Lastly, it helps encourage a rapid development cycle, with frequent releases and quickly patched problems. Users love seeing active development; slower-moving projects are more likely to have sluggish bug fixes and long-standing compatibility issues.
Betas as Final Releases are Not Great
When it came to creating a mobile operating system, Google followed the same formula that had brought them so many successes. Fast-forward several years and their Android platform provides stiff competition, but its unpolished initial releases are still being used today. What’s the difference between Gmail and Android?
The user testing benefit actually worked in Android’s favor. Android was hailed as the mobile OS for geeks, and the party line of “openness” appealed to hackers, modders, and other power users that poke through systems, find issues, and interact with developers. Unfortunately, there was a huge roadblock in the way.
Finding problems and pushing out fixes are entirely different tasks, and this was where Google’s “fix it in post” mentality broke down. Since Android is in fact open, it allows manufacturers and carriers to determine what goes on the phones, from UI templates all the way to OS upgrades. It allows phone manufacturers and carriers to take the open platform and lock it down as they please.
Of course, most companies aren’t interested in patching phones to the latest OS version. Instead, they keep the old version to create an incentive to buy new devices along with their attendant 2-year contracts. Even if they valued the benefits of Apple’s long term support, they would find it time-consuming to validate and deploy patches for the many Android models in active use.
Slow Solutions to Slow Interfaces
An area where Android has trailed competitors is user interface lag, or the delay between user actions and their immediate effects on screen. At this year’s Google I/O Conference, Google formally acknowledged and declared war on lag. Indeed, their latest builds seem more responsive than previous revisions.
Google’s recent efforts don’t change the reality of the glacial deployment rates of Android releases. It’s been almost four years since Android phones first shipped, and it will likely take at least as long for these advancements to reach the majority of active devices. That’s years of poor responsiveness, because Google misjudged how easily they could fix problems after the fact.
Apple’s first version of iOS didn’t have key features like cut-and-paste, and it had poorly-designed features such as the notification mechanism. However, their control over the critical update process allowed customers to actually apply the fixes and updates that were later developed. Ultimately, you must either get it right the first time or retain the ability to fix it later. Google did neither with Android, and as a result many of its early problems are still being seen today.