I’ve followed the Sonos planned obsolescence drama with interest. I’ll admit some sympathy for the company: they have a spreadsheet somewhere that lays out the ongoing maintenance costs and, as they regularly receive telemetry from all of their devices, know very well how many devices are affected by the policy. They undoubtedly feel a bit betrayed by their customers: their policy is significantly more generous than other connected device manufacturers, many of whom don’t deliver a single update.
But at the heart of this problem is a design decision: what is the correct interface for a speaker or other piece of audio hardware? The outraged customers have a point: making sound doesn’t get old and if the hardware shows no signs of degradation, why should it stop working?
I thought this would be harder to show, but Sonos has a great document, ‘Sonos System Overview‘ [pdf], that describes their hardware architecture. In the name of user experience, Sonos has implemented a two-tiered approach: each device can communicate with your other devices through your homes wifi, or the Sonos devices will establish their own mesh wifi network to fill your home with music:
…each Sonos product is both a network client and access point. Instead of merely accessing the network, each component also expands it. Sonos components communicate with every other Sonos component in wireless range, ensuring multiple, redundant paths for data to travel. While each component must be within range of at least one other component, they don’t need to be within range of the central point.Section 3.2 – SonosNet Stup
Why do customers need this particular network design? Why can’t they just run speaker cable all over their dwellings like all of us regular folks? Wireless music delivery is an important component of Sonos’ value and their customer conception is very similar to Apple’s: premium devices that provide a great end-to-end experience. The difference between Apple and Sonos is that cellphones are (were) constantly improving whereas sound quality is not. Sound quality is the most noticeable and enduring component of Sonos’ value proposition; the unboxing experience and whole-home music delivery are very quickly forgotten or taken for granted. I’d trace much of the customer ire to this change in a Sonos speaker’s value, that today the assumed or forgotten features are threatening the primary, enduring feature.
So, the customers ask, can these things be separated? Can the sound quality be somehow separated from the wireless delivery and the other platform capabilities? Indeed, Sonos appears to be developing this option:
…beginning in May, it will introduce a way for customers who want to keep using their legacy hardware to separate those old products from their main Sonos system. You’ll want to do this splitting off step because once a device stops receiving updates, so does your entire Sonos system.
But where the company foresees trouble is with streaming services. If a partner like Spotify makes an SDK change that calls for more powerful hardware, these older products might get left behind.https://www.theverge.com/2020/1/21/21075043/sonos-software-updates-ending-play-5-connect-zone-players
And this is where Sonos’ network architecture bites. I’ll try to be brief, but I read the second part of the above to implicate the intentional technical limitations of streaming services. Stepping back, streaming music services work by sending your requested content through the internet to your device, which decrypts the digital music data, and converts it into analog signals that are played on the speaker. There are many, many ways this could be done, but only a few are trusted by the content distributors. Sonos appears to have chosen to push the decryption all the way to the smart speaker itself, with the result that the ability to decrypt Spotify, etc. is entirely dependent on the end device itself, requiring frequent upgrades of every device so as to remain compatible with the streaming sources. So it is not that the speakers are unable to play music, per se, but that they’re unable to maintain the end-to-end chain of trust required of the digital streaming ecosystem.
Were the computer and radio bits separable from the audio frontend and speaker, Sonos’ would be able to just sell an upgraded ‘Sonos brain’ to the affected customers. This modularity constrains design; Sonos pays a pretty penny to make their devices look great.
Without replaceable modules and given the hardware they have, I’d recommend making the speakers simpler: instead of having each speaker be independently able to decode music from the original source, rely on newer devices to do the heavy lift interfacing with outside music sources, and send the music to the speakers over a simplified always-compatible protocol. This would likely mean sacrificing the mesh networking, but better that brittle feature than to throw the entire unit away.
In fact, the home theater industry has developed a wireless protocol, WiSA, that sounds very similar to what Sonos should adopt. Of course, Sonos could develop its own, proprietary protocol and keep its customers restricted to its ecosystem, but doing so will only keep their company from creating new devices that add value to previous and prospective customers.
How should hardware manufacturers avoid this kind of customer ire? There are two ways: plan to go out of business within the life of your product, or plan for retirement! Just as in real life, planning for retirement means a few things: understanding and communicating signs of decreased ability (capacitors fail, plastic breaks, etc…this is normal for physical hardware devices), adaptation to changing conditions (reductions in feature set so as to disable insecure protocols, etc.), and the arrangement of end-of-life plans (repair symbols within the device). Sonos failed to plan for the graceful retirement of its devices; instead of communicating their senescence it attempted to mandate their obsolescence.
Update 01/25: I see the CEO just responded and committed to do nothing. This won’t restore customer love, to do that he needs to describe the original problem, why they thought obsolescence would work, what they’ve learned, and, since the original problem still exists, how they’re going to solve it in a better way.