What went wrong at Sonos?

Estimated reading time: 18 minutes

A botched app rollout made Sonos the punching bag of the industry. What lessons can we learn from their errors? 

It’s only by recognizing past mistakes that people can avoid repeating them. And when the textbooks are written on how to develop and roll out big software releases, you’ll likely hear the name Sonos.

In April 2024, the connected speaker company rolled out its highly-hyped mobile app, which had been extensively trailed in the press as solving a whole host of issues users had with the Sonos sound systems. The app was a major deal, the company said – because it threw out the old ways of working and started development from scratch on something new. 

“After thorough development and testing, we are confident this redesigned app is easier, faster and better,” then-company CEO Patrick Spence said in April last year. “It once again raises the bar for the home music listening experience, and sets up our ability to expand into new categories and experiences.”

There was just one problem. When the app was put into the hands of users, it didn’t work. At all.

What actually went wrong – and what can we learn from Sonos’s mistakes?

A catalogue of errors

“The May 2024 app release was intended to address performance and reliability issues while building a more modern platform for future innovation,” Nick Millington, Sonos’s chief innovation officer, said in a written statement. “After rolling it out, some customers experienced bugs we had not found in our testing, and a few features were missing.”

Mav Turner, chief product and strategy officer at Tricentis, has seen plenty of misjudged attempts at totally rebuilding digital products over the years. As a Sonos customer, he had a front row seat to the issues that team faced as the app was released. 

The goal was a good one, Turner admits. “It’s a very common conversation to have: How can we simplify this?” he says. Businesses don’t want to have a dozen specialist teams for a dozen different environments.

Sonos had previously taken the approach of using platform-specific frameworks, developing optimized versions of its app for every mobile and desktop operating system a user was likely to have. While this worked well, it was labor-intensive, and would likely result in large teams and massive overheads for Sonos. 

While the decision to move to a JavaScript-based framework for mobile was likely driven by honorable desires to simplify operations and reduce redundancy, it actually led to the service becoming slower and less responsive to users.

Plug-and-play to nothing-and-nothing

Another problem was that Sonos had built a reputation for simple products. Instead of relying on the Simple Service Discovery Protocol (SSDP) to enable that plug-and-play functionality anymore, Sonos decided to replace it with multicast DNS (mDNS). While this seemed like a more efficient solution, it turned out to be a problem for those on home networks, resulting in speakers and other connections on the network Sonos relied on dropping out regularly.

Speakers ended up disappearing from home networks under the mDNS rewrite of the app’s operation, according to one technical analysis by Andy Pennell, a principal software engineer at Xbox for Microsoft. Pennell called the whole initiative “a disaster”.

But the actual development of the app was only the beginning of the problem. “Sonos issued a statement that the updated app had been through ‘thorough development and testing’,” says Mark Mishaev, chief architect at Checkmarx, a software engineer and cloud architecture firm. “However, when things go wrong to the extent that they did, it’s likely that there were issues in the beta testing phase, with rushed or inadequate beta testing.”

What can we learn from the mistakes?

For Sonos, the immediate aftermath of the new system was a catastrophe. The company tanked its reputation for reliability with its customers, and became a byword for a problematic feature overhaul. 

In many ways, it’s too late for them to fix the issue the botched upgrade caused, but their mistakes can act as lessons for others who are considering going down a similar path.

“They were looking at, ‘How do I replatform, how do I make something new, make it more streamlined, efficient, and then how do we do that?’ In that path, I think there were a lot of things that were underestimated,” says Turner.

Reliable, wide-scale testing is vital. “A well-structured beta program should include diversified testing environments, real user feedback loops, and structured rollback mechanisms. If these aspects were insufficient, issues may have slipped through,” says Mishaev. 

Turner himself is certain that Sonos would have gone through persistent testing – but it highlights the core issue with any testing experience and environment. “This hits the classic ‘It works in my environment’ issue,” says Turner. “There is this super long tail of different configurations and environments to consider,” he says.

It starts with culture

Beyond the details, there was also likely a failure of leadership to allow the issue to fester. “It’s definitely a compounding issue,” says Turner. Any company that pursues a ‘burn the boats’ strategy of scrapping everything old and replacing it entirely with something new is running the risk of things going wrong, the experts reckon. It’s all-or-nothing.

“Having an automated rollback process is crucial when dealing with critical user-facing applications,” explains Mishaev. “A rapid rollback mechanism, combined with canary releases and feature flagging, could have helped Sonos minimize user impact by reverting to a stable version immediately.” 

Turner admits that it’s always challenging when developing such a system to balance innovation at speed with low costs. “I would say that in general, a lot of businesses don’t really have a good balance,” he explains.

But it’s important to signal that engineers need to be comfortable speaking up when issues occur, and not feeling that they have to compromise quality for speed.

“You don’t have to spend weeks doing crazy planning exercises, but I think you get a lot of value from some intentional discussion on risk analysis and the ability to revert or recover,” says Turner. It’s a lesson that Sonos could well have learned – a little earlier than they did, for the sake of their customers.

What did Sonos learn?

Sonos has since drawn up seven new commitments to quality and customer experience. Tellingly, these include bolstering pre-launch testing, and appointing a quality ombudsman so employees can raise concerns about what they’re being asked to do without fear of reprisals. The firm has also instigated a customer advisory board.

“Through these improvements, we have significantly enhanced our ability to monitor the quality of the experience we are providing, to better address issues, introducing new quality benchmarks and extended testing phases to prevent similar issues from occurring in future releases,” says Millington. The company has also expanded its beta testing team, and will “bolster our use of tech alphas to help identify issues as early as possible.”

The situation was chastening, it seems, for Sonos. “We’ve learned from our experience and are committed to delivering a better experience that our customers expect,” says Millington. “As we laid out in our commitments, we will continue to improve the software regularly, and are determined to make the Sonos experience better than it’s ever been.” 

Get articles like this in your inbox

Choose your LeadDev newsletters to subscribe to.