How to build Android consumer electronics, part one

The consumer electronics industry is rapidly evolving, and injecting computing and cloud technologies into the customer experience is now table stakes.

Historically, these devices have been enabled by various embedded systems, and are certainly fleet-like in nature. I have a natural affinity for them, starting with my time on the Microsoft Windows squad competing against OS/2 in the ancient (yet epic) battle for the Windows desktop (alum of the 1993 CES SWAT team!). This would eventually lead to driving ecosystem engagement for Microsoft around the Windows CE-based Handheld PC and Pocket PC, and then Windows Mobile (sorry for that, everyone; at least it provided some good base hardware for the first bringup of Android!)

This post is part of a series:

• How to build Android consumer electronics, part one
• How to build Android consumer electronics, part two
• How to build Android consumer electronics, part three

Why build Android consumer things? (not to be confused with Android Things)

The consumer device world really came together for me in my work with Jawbone in the late 2000s. As acting outsourced product manager for the Jambox, I was in the middle of PRDs (Product Requirements Documents) and MRDs (Market Requirements Documents) for what were essentially consumer electronics embedded systems. And while I was not the “decider” around key features, I was definitely the cat herder!

In consumer electronics, design decisions are very carefully considered, as a scaled user experience is key — screw that up, and you suppress sales of your product. Get it right, and uptake is nice and quick. One such decision for the Jambox centered around Bluetooth pairing UX (mind you, this was a decade ago — the whole Bluetooth experience was much more fragile). Without a screen or sophisticated OS, any user interface element was physical — which brought in a whole host of considerations related to BOM (Bill o Materials) cost, reliability, and supportability. When we’re talking fleets on the scale of millions (and we were), these decisions ripple with a vengeance.

At Jawbone, the Jambox had the luxury of built-in voice output to provide guidance and instructions to users. But the resources to develop such a system were delivered on an embedded OS, which was technically intensive.  In the end, the big argument at Jawbone was whether or not to include a dedicated Bluetooth pairing button on the speaker. Doing so would increase BOM cost and introduce a less familiar user experience. The flipside was inconvenience: Who wants to hold the power and volume up buttons to enter pairing mode? We went with a button, and it was the right choice — when paired with system voice. Had it existed, it would have been far simpler to build on something like Android, where such things are off-the-shelf.

Fast forward to today, and you see Android at the scale of billions, spanning smartphones, tablets, watches, TVs, and even automobiles. And based on Android’s success, it’s clearly delivering the right customer experiences and business models. The rub is that these are gated Android variants from Google — GMS (Google Mobile Services), Android TV (Google TV), Wear OS, Android Automotive (which uses the GMS equivalent GAS, Google Automotive Services). You get curated infrastructure that nails these massive use cases, carried forward by Google. And while fantastic, the infrastructure and innovation are largely unavailable to other CE use cases that are just begging for Android.

These types of companies and products are competing in fast paced markets. Think of how quickly social graph and content graph software companies, like Facebook and TikTok, move. They are true DevOps companies: constantly innovating and delivering via state-of-the-art CI/CD (Continuous Improvement, Continuous Development). Can you do that in the consumer electronics space with dedicated devices? Certainly. I’ve had the pleasure of diving into AOSP with a set of our great CE customers like CLMBR, Inspire Fitness, and others who shall not be named. I’ve also been involved in lost deals where the customer has either fallen back to embedded or “dumb” AOSP. 

Come explore this with me a bit — because strangely enough, it all starts with the business model.

Continuous improvement builds continuous revenue

How a company profits from a consumer product drives many decisions around the software stack. The old school model — selling the hardware only — minimizes the cost of the software infrastructure. Google struggles with this in the smartphone space, attempting to provide an ongoing, secure, and (crucially) upgradeable experience for billions of users. But most device makers view firmware updates as an expense for which there is no incremental revenue. That’s why you see Projects Treble, Mainline, and the Generic Kernel Image.

Essentially, Google is lifting a cost from device makers — one they are loath to absorb — and placing it back on the Android team itself. Some of these technologies utilize the existing Google Play infrastructure to deliver updates unilaterally, and therefore create a more reliable and secure Android environment for the billions. (A tough, tough problem to solve! And one that Google is doing some amazing stuff around.)

If you’re one of those companies “just” selling hardware, one and done, there’s not a lot here for you. Get your BOM down, your price up, and maximize your margins. Design your system well, and keep manufacturing and validation tight so field issues don’t blow you up. (Over beers, I might let a few things slip about riding shotgun with Jawbone during the Up debacle — that was a tough one.) Infrastructure isn’t really needed, and recurring costs are avoided — it’s just NRE (Non-Recurring Engineering costs). That’s why FOTA (Firmware Over the Air) services for traditional smart TVs are generally priced as a one-time cost, upfront per device: It’s little more than insurance if something goes wrong, not a viable path to incremental revenue.

But what if part of your business model is securing monthly or yearly revenue from your customer base? This implicitly means your customers are expecting a dynamic, changing, and advancing experience over time. And to have your best shot, you need the right approach akin to a Facebook or Tiktok deploying DevOps with CI/CD. Which means the world of generating ARR (Annual Recurring Revenue) also means spending that ARR on infrastructure — so you can focus innovation and speed with your limited development resources.

This is where Android and the Esper Cloud come in. Combined with our pipeline infrastructure, the Esper Cloud API is perfect for managing these types of fleets at scale. We are currently the market leader here, and plan to drive the innovation cycle to remain in the lead. (Which is to say: When companies tend to bet on us here, we do very well.)

The key, though, is the composition of ARR. Some companies have one business foot in the "old" world and one in the "new." They sell a base product without recurring revenue, and then upsell customers to products that do create ARR. This creates an aversion to recurring investment for that base product, while products that generate ARR demand it — customers expect CI/CD (read: agility) from something they continue to pay for. How does infrastructure which also demands ARR deal with this? Not very well. Yet, these companies still want to standardize on one set of infrastructure for both the operational benefits and the elusive “one pane of glass.” 

You might think Esper is out at this point — aren’t we one of those ARR cloud infra companies? Yes, but we’re also scrappy and intensely customer focused! What we’ve done for customers is come up with a hybrid model: We can adjust our COGS (Cost of Goods Sold) burn to take care of the static fleet, providing the typical safety hatch (helping the customer get the initial configuration right for provisioning). Once those products are set, we can establish a relationship around the ARR-generating subset of the fleet that properly fits into the overall business model and infrastructure requirements. Three cheers for our DevOps team!

Android is a path to ARR

So, what’s a great consumer "Android" form factor leveraging ARR? There are still categories of ARR devices that run embedded systems of some form, like the Google Nest Cam. I really love mine, and what really stood out was the out of box experience. With the user's smartphone handling all of the setup, interface, and control functions, Nest was able to “sideload” the dynamic customer experience on the app side, enabling DevOps and CI/CD with Google’s Play infrastructure. It works pretty well! But this only applies to relatively dumb sensors and certain categories of IoT products. On the device side, you’re still playing the NRE-only game. That’s out of Esper’s wheelhouse.

But what if the experience is sideloaded onto a device that isn’t a smartphone, and that device runs Android? We are ready to rock. That’s essentially what Spire Fitness does with its on body health sensor, working with dedicated device smartphones as the primary interface. Esper is the infrastructure Spire uses to evolve and deliver the app experience to its customers that then brings to life the sensor data and creates the ARR opportunity. 

There is yet another variant of ARR, where the customer is actually the product. Example Vizio’s silent data scoop-and-sell model with its TVs. But this still tends to be an NRE infrastructure driven domain since the typical trick used is to win on initial sales price to get the socket (thus super tight on all BOM costs), and then monetize the customer. We shall see how that model does over time, but it appears to be working quite well now.

Then we get to the pure ARR driven companies where the actual customer needs to be won every month — when you buy the device you also have to pay for the associated recurring service. If your devices are AOSP, then Esper is meant for you. Why, you ask? We are the business sauce of consumer AOSP and can help you further with Esper Foundation for Android and the functions we’ve built with consumer electronics in mind. If you're curious how that could work, the next post in this series gets to the nitty gritty of how Esper can be the foundation of an ever-evolving experience.

In the meantime, if you like what you're hearing, book a demo. We'd love to see what you're building, because we're just as curious as you are about how we can supercharge that experience  — be it with our own custom OS based on Android, advanced device management, or (our favorite) a blend of the two.