One of the big news and online discussions in the past weeks centered around Google’s acquisition of Nest, a company building intelligent thermostats – and subsequent sale of Motorola’s hardware business to Lenovo. Many viewed this as another indication that Google wants to be like Apple, joining the rank of hardware manufacturers and vertical integration. Personally I think this is not the case, and Google’s future strategy with Nest – indeed if there is one – is largely an extension of their current way of working together with developers and hardware partners.
The acquisition announcement talks about Google providing scale that Nest couldn’t develop by themselves. But Google doesn’t have the expertise to scale hardware, as we clearly saw from the Motorola acquisition: Google didn’t invest in the hardware divisions and eventually restructured and sold them off to a company better suited to leverage the brand and boost sales. Google probably never had the intention to scale Motorola’s handset business, instead focusing on defending Android with the patent portfolio. What Google does have is a massive scale in software and server infrastructure and I think that’s where they’re heading with Nest as well.
Specifically, Google wants to spread their software on every connected device, to collect as much of the world’s information as possible, discover the underlying patterns of behavior and feed back relevant suggestions to users – and maybe the occasional ad. That was one of the original goals behind Android, to gain a solid foothold in smartphones so that Google remains a top player on the new platform. Now that Android has largely succeeded, it’s time to move on to the next frontier, which will probably be wearable devices and connecting every-day appliances to the ‘Internet of Things’.
In this context, Nest being repurposed as Google’s hardware division doesn’t mean they will start massively building thermostats that require you to sign up for Google+. Rather the products will become developer devices, like the current Nexus line of smartphones. Google will design the new apps and back-end services for these hardware formats and new ways of interaction, will disseminate them to developers and offer the final versions for free to hardware manufacturers – most likely with a strict set of rules about how the software can be used. That’s also why the Motorola acquisition never made much sense from a hardware perspective; Google already had a working model by partnering with software manufacturers, so owning a hardware subsidiary was unnecessary.
You can see this model being used right now with Google’s other hardware initiatives: Google Glass is mostly a developer preview to assess its social acceptance and test out the right interactions and apps. Google also kept Motorola’s research arm; and the recently announced Project Tango fits this pattern well, although it seems focused more on short-term smartphone improvements than on revolutionizing devices. But experimenting with self-driving cars: is Google really going to build its own vehicles, invest in manufacturing capacity, safety tests and so on? Unlikely: once the software is ‘street-ready’, it could be installed on any car made by any current or future company. It would make a great base to connect to your smart wearables and your smart home, populated with many devices running customized versions of Google software, all talking to each other in Google’s universal data language.
Even if Apple does at some point launch its own iGlass/iLens/iSomething and blows the previous products out of the water, Google will ‘be ready’ for this: they can rewrite their apps for Apple’s platform and extend there, just as it has done with Mail, Maps, YouTube and their other services. Google doesn’t need to build its own devices; it just needs to build a symbiotic relationship will any future connected device, offering their apps and services for free and thus ensuring these new devices continue to send a stream of valuable data back to Google’s servers.