[dguido]

Please stop putting salespeople in charge of highly technical product companies like Sonos. I'm so glad that Tom Conrad is an engineer by training. I hope he can turn this mess around.

The key technical change that broke Sonos was abandoning their reliable UPnP (Universal Plug and Play) system for device discovery in favor of mDNS, while also shifting from direct device communication to a cloud-based API approach. This new architecture made all network traffic encrypted and routed through Sonos cloud servers (even for local operations), adding significant overhead and latency, especially for older Sonos devices with limited processing power. They also switched from native platform-specific UX frameworks to a JavaScript-based interface while moving music service interactions through their cloud instead of direct SMAPI calls, resulting in slower performance and reduced functionality.

For a more extended discussion, see this excellent LinkedIn post from Andy Pennell, a principal engineer at Microsoft with a deep technical understanding of Sonos systems. He created one of the most successful third-party Sonos apps for Windows Phone and worked directly with Sonos on their official Windows Phone 8 app.

https://www.linkedin.com/pulse/what-happened-sonos-app-techn...

[jedberg]

I don't think having a sales person in charge was the problem.

The problem is the fundamental disconnect between what's good for users and what's good for the company. The company wants you to have to pay them money every month and control how you interact with the product, so that they can be a services company with recurring revenue.

The consumer wants a device that they buy once and it just works.

[griomnib]

I have experienced this most acutely with the most recent round of macOS and iOS updates.

Nothing Apple is shipping seems to be for me, the user. Rather it’s a grab bag of crap “AI” for Wall Street, ways to make it harder to run software of my choosing, and wholesale trashing of perfectly fine UX to cram in whatever useless feature some PM landed for their promotion.

I could say a few hundred things much worse about the direction of windows 11, which is even more obnoxious than Apple, but then I’d have to relieve the horror of being forced to submit my email address to Microsoft to install the damn OS.

Day by day I feel the devices I’ve spent a huge sum of money on no longer belong to me. I’m getting really fucking tired of it, and something has to give.

[mrandish]

> The company wants you to have to pay them money every month and control how you interact with the product, so that they can be a services company with recurring revenue.

Yes! This pervasive trend has nerfed so much consumer tech. I simply won't buy any more hardware that relies on proprietary clouds

[danielmarkbruce]

> The problem is the fundamental disconnect between what's good for users and what's good for the company

The fundamental problem with 95% of companies, and 99% of publicly listed companies.

[benreesman]

I haven’t owned Sonos gear in a long time, but certainly back in the day they had just amazing products. That SUB where it was so perfectly balanced? They did a demo (that you could easily reproduce at home) where you could have it driving “call the cops” noise disturbance bass without upsetting a nickel set lengthwise on top, just a great unit and not the only one. Awesome stuff.

But while superior products at a price point can capture a bunch of share, after that they grow at the rate of the market. Those markets have “matured”.

For whatever reason we don’t as a society let “tech” markets mature. We demand growth long after everyone is satisfied.

This is where ideas like “growth” and ideas like “useful” diverge: raise your hand if you like Facebook or Google in 2025 more than 10-15 years ago.

Sonos (and I’m aware of the structure) “grew” right out of a sustainably profitable business with happy customers.

[atoav]

As a music fan one would think I'd be their target group. But I haven't even considered their product and classified it as "some smart crap that is an excuse to syphon data out and lock me in". So all stick, no carrot.

[alkonaut]

But Sonos doesn't sell any services/subscriptions, just products, correct? So even if they wanted to have recurring revenue how would they do it? They sell gadgets?

[givemeethekeys]

Bait and switch is the fundamental problem. Abuse of power.

[observationist]

Engineers are in a better position to understand what the customer wants and needs. Salespeople are there to sell their product, and fundamentally don't need to understand what the customer wants, or needs.

Give a good salesperson a handwavy outline of something to sell, and they will sell it. They don't need technical accuracy for success. Yes, this is bad for customers, and makes life harder, and results in ridiculous, counterproductive, infuriating situations for IT staff, engineers, and other people who have to deal with the technical realities of every day business.

A salesperson can just mash psychological buttons in manager's brains, and they'll make the sale. The consumer, in enterprise level markets, is hardly ever the team or individual in charge of operating the technology. The consumer is the manager, or managerial team, looking to check boxes and shuffle numbers and spend $X on Y department, for which they get rewarded for a wide array of arbitrary outcomes, almost none of which have anything to do with the practical impact of the product in question on the people who end up most affected by the purchase.

If an engineer with a solid understanding of the product being sold is in charge, he's in the best place to rein in the sales and marketing teams, and to direct development based on customer reality. This probably results in lower profits, overall, but a better product, and a better reputation in the long run.

[nelox]

Agree. Just ask Steve Jobs.

[mananaysiempre]

> abandoning their reliable UPnP (Universal Plug and Play) system for device discovery in favor of mDNS

I don’t know about that part. UPnP is exactly the HTTP-abusing XML-laden layer-spanning horrorshow you expect from 2000s Microsoft where it was mainly supported, mDNS is a fairly compact and neat set of independent extensions to preexisting Internet protocols born during Apple’s short period of flirting with open standards. In a greenfield project, you’d need to show me some really impressive tooling to make me choose UPnP, because five minutes with the specs are enough to tell implementing or debugging the thing is going to be a nightmare.

(No experience with Sonos or their implementation of either.)

[stephen_g]

I had the same reaction, all the other parts of the parent comment sound bad but switching to mDNS seems like the one that should have been an improvement or at least neutral...

[eddythompson80]

I'm guessing people commenting on UPnP vs mDNS implementation are mostly referencing this post https://www.linkedin.com/pulse/what-happened-sonos-app-techn...

But it wasn't just a move from UPnP to mDNS with everything else remaining the same. They also moved to HTTP/WebSocket instead of UPnP eventing, added encryption.

While most complaints in this thread about the app all say "it's sluggish", with the initial release of S2 many had their systems that worked perfectly fine with S1 undiscoverable with S2. At the time all the advice on Sonos forums, Reddit, etc was "First check your router and make sure mDNS isn't disabled". Which caused a lot of people to have a kneejerk reaction of "wtf is this mDNS shit and what was wrong with the "old reliable UPnP"

[spamizbad]

Ditching a native framework for something JS-powered and running everything thru a cloud server sounds like technical decisions willfully made by engineering leaders.

[sgarland]

Probably egged on by people telling them they had a much larger hiring pool if they went with JS (which is almost certainly true).

Just once, I’d like to see a leader actively refuse these kinds of arguments when the process they have is objectively better.

Never once have I ever experienced an Electron-ified version of an app and thought, “oh yeah, this is better.”

[dmazzoni]

That's an example of something that can be done well or done poorly.

AirBnB, UberEats and Facebook are all built with React Native and they have excellent performance.

Using a JS framework for your UI doesn't inherently mean it will suck. It can be done well.

If you expect it to be half as much work, you'll be disappointed.

If you expect it to be a tradeoff that makes some things easier and some things harder, and you're willing to invest in making it excellent, then it can be a very reasonable choice.

[stuff4ben]

It's not like the salesy-CEO was writing the code, there was still a bunch of engineers who said "hey this sounds like a great idea". Personally I want my CEOs to be on the sales side, make more money for the company. That being said you best have a good CTO/CIO that aren't sales-oriented.

[magicalhippo]

Our company makes B2B for a rather technical niche.

We got a sales-oriented CEO who knows when to listen to us developers. It has worked very well for our company.

Being more sales-oriented he's found good business models and knows our customers well, and hence what our products are worth to our clients so we're not selling our products too cheap. This was the case before he took over from a more technical CEO.

While a CEO with an engineer background can certainly do well too, I think it's probably easier to find a good sales-based CEO that simply knows when to listen to their technical team. At least in theory...

[rachofsunshine]

One imagines a lot of the engineers going "yay!" are just people who want to have a job tomorrow.

[bigfatkitten]

This architecture sounds like a profound engineering failure, not a sales problem. The sort of failure that should get engineering leaders fired.

[x0x0]

Hard to say. I'd bet there was a decent chance the eng team stridently warned the execs about what would happen and got overruled.

https://arstechnica.com/gadgets/2024/09/it-was-the-wrong-dec...

In particular

> Employees claimed that Sonos’ desire to get new customers and please investors was becoming more important than ensuring that old hardware would work properly with the new app.

That sure sounds like this was a deliberate choice.

That said, I suspect Sonos' market has mostly disappeared. A decade ago I paid $400+ to get streaming audio; now a lot of people are happy with Spotify Connect and $200 google speakers or a $50 refurb echo 4.

[nl]

The new mDNS discovery mechanism works much better for me than the old one. I had two speakers that would constantly require reboots to be discovered with the old version but now they are 100% available.

[insane_dreamer]

Those would have been CTO decisions or at least recommendations as to the technical merits of the change, not the fault of the CEO.

Now if the CEO made the change for other reasons (usually financial, such as customer subscription lock-in) despite the technical downsides (which should have been presented by the CTO), then yes, in that case the blame would primarily fall to the CEO.

[raffraffraff]

Nice article by Andy. It's astonishing that they released that magnitude of change, and that they didn't provide a way to roll back once it showed itself to be a car crash. It should have been an opt-in beta, then opt-out, and maybe then after the bugs are squashed, incrementally rolled out.

I understand why they'd to remove this big clatter of legacy protocols, simplify it, and encrypted everything. A tech-focused CEO would surely want that too, but perhaps might respect the amount of work and testing involved. What they forgot is that in a Sonos is a clatter of legacy protocols on top of speakers that are sonically "ok". Wasn't that their unique selling point? Why wouldn't a CEO with a sales background understand USP?

As someone pointed out: they want to turn once-off purchases into monthly subscription. Maybe. They see this enormous userbase and brainstorm ways to squeeze recurring revenue out of it, but ironically they ruin the product and turn an army of advocates into enemies.

[wouldbecouldbe]

This sounds more like a modern CTO felt the need to refactor the a big part of the codebase for the sake of it and if that wasn't foolish enough, they decided to not roll it out incrementally.

[surajrmal]

I'm not sure any single one if those was necessarily problematic so much as the fact they did all of transitions at the same time and perhaps didn't do enough diligence in testing and slowly rolling out to ensure parity. For instance they could have rolled out mdns support with fallback to upnp and perhaps iterated untill they knew for a fact mdns was finding all the same devices as upnp with similar or better latency. However it seems that's not what they did.

mDNS is used by all the major players in the iot space today and there is a reason for it. For instance I believe Chromecast uses mDNS for discovery. Routers have had a long time to work through any possible issues. New code will always suffer from bugs and I'm pretty sure that's been one of the problems they face more than anything else.

[sholladay]

You blame the sales-oriented CEO for the problems but then point to a list of highly technical changes as the ultimate cause. A salesman knows nothing about these architecture decisions and would have trouble asking for them to be implemented even if they somehow knew it’s what they wanted to do.

Could a more technical CEO have turned the ship around more quickly? Sure. But let’s be honest, the blame rests at the feet of the engineering team. Someone got excited about using some new tech and didn’t fully consider the ramifications. This happens all the time. And if you’re lucky, the code review saves you, or if not then QA saves you, or if not then the beta testers save you. If a problem remains after that, then it tends to become really hard to undo, from an organization perspective.

[elevatedastalt]

These sound like extremely technical decisions that presumably engineering leads in the company came up with, signed-off on, and convinced leadership to go ahead with.

I doubt a Salesperson has the technical expertise to initiate any of those changes.

[accrual]

It could have been the other way around, though. Engineers could have been faced with calls asking for a higher degree of integration and dependence on cloud servers for profit reasons (carefully sold as better UX), then developed it because that's what they're paid to do.

[Twirrim]

> especially for older Sonos devices with limited processing power.

That reminds me: When S3 dropped support for MD5 ciphers, it ended up causing problems for a number of their customers who had remarkably old computers connecting to S3. The machines struggled to handle the newer / stronger ciphers they were now required to use. In one case it went from "just about keeping up" to "got no hope". That was a "fun" way to unexpectedly break folks.

[Terr_]

> The machines struggled to handle the newer / stronger ciphers

Sort of like "test your stuff simulating a really shitty network connection", perhaps something else in that vein would be "test your stuff with excessively slow crypto and longer-keys."

[btreecat]

I'm not sure I understand the issue w/moving from UPnP to mDNS if everything was still locally accessible and managed.

Kinda feels like those two issues are orthogonal.

[cabinguy]

Do you think a sales person or a technical person dreamt up those changes you believe broke sonos?

[jdmg94]

mDNS is superior to UPnP, they just made a compounding sum of bad choices that ended up in a bad architecture. I do hope companies start learning that you can't have suit doing running an engineering company

[Mindwipe]

Google has engineers running an engineering company and that has turned every product for five years into a disaster.

[jdswain]

I've implemented both UPnP discovery and mDNS, and mDNS was quite a bit easier to make reliable than UPnP. However, if they did have a reliable UPnP system, it would almost certainly destabilise the software for any transition like this. There's just so many different network issues to deal with, it's tough to debug when a user reports a problem and it's probably an issue with their router which is only sold in Germany. It is very frustrating class of bugs, when the app just doesn't find devices on the network.

[egorfine]

mDNS is far superior to UPnP. What casted a bad shadow over mDNS was the Apple's discoveryd vs mDNSResponder saga[1].

[1] https://www.macrumors.com/2015/05/26/apple-discoveryd-replac...

[madeofpalk]

Tom Conrad was Chief Product Officer at Quibi. They're not out of the woods yet.

[bmitc]

Engineering led companies can also be pretty miserable as well. Look at Google, for example.

[urbandw311er]

Wow, thanks so much for the succinct and informative summary. I’m an owner of multiple SONOS speakers and am enraged by how these changes have effectively crippled my devices that I spent much hard-earned cash on. I am beginning to despair. I hope and pray they can just roll back half of them.

I suspect it’s all related to centralisation and control and subscriptions to radio services and profit however so I won’t hold my breath. Most enshittifcation has profit at its root. :-(

[xattt]

Is this reversed?

[harrall]

Bruh an engineer probably suggested those changes.

You think a salesperson is suggesting mDNS and frameworks?

[rootedbox]

The salesperson had no idea what mDNS or the frameworks was.. and rubber stamped it.

[Glawen]

Yep, it is definitely an engineer behind this, wanting to show off.

My job now is to deal with the aftermath of failed design choices at my company. It only took a couple of guys to impose their deluded design, because noone stood up to call their bullshit.

[Tteriffic]

Likely project manager or architect.