Inspired Thinking: What Sonos Got Wrong

How often have you come across a terrible piece of technology and wondered how it ever made it past the drawing board? 

Buttons in weird places. Features you’ll never use. Options you need but can’t find. You wonder: who signed this off, and did they ever use it themselves?

One thing is for sure – they would’ve benefited from reading product management guru Marty Cagan's influential book Inspired: How to Create Tech Products Customers Love.

It focuses on “product teams” – the people responsible for building the tech we use –  and has become a must-read in the industry. As Chad Dickerson, former CEO of Etsy put it: “If you only have one book on product management, this is the one.”

Drawing on his experience building hugely successful products at companies like eBay, Netscape, and HP, Cagan argues that great products don’t materialise from great ideas alone. They come from well-structured teams who work together effectively. Get this right, he says, and you’re in with a shot. Get it wrong, and you risk launching a dud that drives users mad.

Hitting the wrong notes

If, like me, you have Sonos speakers pumping music into every room in the house, you will be able to relate to the latter scenario.

In May 2024, the wireless streaming giant rolled out a major update to the app millions of customers rely on to control their speakers. 

It did not go well.

Behind the sleek new interface, core features had disappeared – alarms, playlist editing, song queues. Some users couldn’t even connect to their speakers, rendering their expensive multi-room systems virtually useless.

Internet forums exploded. The company’s CEO Patrick Spence issued a public apology and pledged that restoring the missing functionality was the company’s “number one priority”. Over the following months, Sonos released 16 separate updates to restore the features that the new app had stripped away.

The fallout was considerable. The company’s share price fell by 15% and Spence stood down at the start of 2025, along with the firm's chief product officer.

It reads like a case study in what Marty Cagan would likely describe as the exact opposite of how an “inspired” product team should operate.

According to Inspired, the best products come from teams that deeply understand their users and have the autonomy to creatively solve their problems. Not from teams chasing deadlines to fulfill top-down directives.

So what might Sonos have done differently?

Four steps to “Inspired”

Here are four lessons from Inspired that might have saved Sonos from an app-solute disaster.

1. Fall in love with the problem (not the solution)

It’s easy to get attached to the shiny new thing you’re working on and lose sight of why it’s being developed in the first place. Cagan argues that teams who fall into this trap lack an important trait shared by successful product teams who are “stubborn on vision but flexible on the details.”

From the outside, the Sonos app refresh looked like a solution in search of a problem. Users weren’t clamouring for fewer features or a snazzy redesign.

The real pressure seems to have come from within – shipping a new app to align with the launch of the company’s new headphones.

As Cagan puts it:

Good teams get their inspiration and product ideas from their vision and objectives, from observing customers’ struggle, from analysing the data customers generate from using their product, and from constantly seeking to apply new technology to solve real problems. Bad teams gather requirements from sales and customers.

2. Discovery > Delivery

Cagan champions a process he calls “dual-track development”: where discovery and delivery run in parallel. 

Think of discovery as detective work –  testing hypotheses, experimenting with prototypes, and gathering user feedback. This isn’t a phase to be tagged on at some point in the project – it should be running throughout. Cagan’s golden rule is that new products should be tested early and often during development.

Had Sonos followed this model, it’s hard to imagine the ill-fated app would have made it to launch. With regular feedback, they could have corrected course long before the backlash.

Cagan says:

Good teams engage directly with end users every week, to better understand their customers, and to see the customer’s response to their latest ideas. Bad teams think they are the customer.

3. Beware the roadmap to nowhere

Most product teams work to a “roadmap”. These often come from management, setting out the features and projects the product team is expected to prioritise, along with delivery deadlines for the next quarter or year. The urge to establish a document like this  is understandable; managers want to ensure that the most valuable work is being prioritised, and they need a plan that the rest of the company can work to.

But Cagan warns that this can often be a trap:

Typical roadmaps are the cause of most waste and failed efforts in product organisations.

Why? Once a roadmap is published, ideas become promises – even the bad ones. In reality, many ideas fail. Some won’t solve a real problem, others won’t work in practice. And sometimes users just aren’t as excited by an idea as the tech whizz who had the light-bulb moment.

What matters most isn’t knowing what will be shipping 12 months from now and building it on time. It’s building the right thing. The best teams stay flexible and iterate as they go.

Instead of feature-packed to-do lists, Cagan recommends building roadmaps around problems to solve and outcomes to achieve. This lets teams pivot when needed, focus on what matters, and act like “missionaries”, not “mercenaries”.

Mercenaries pat themselves on the back for shipping features and hitting deadlines. Missionaries keep sight of the real reason they’re building products: to solve problems for their users and the business. 

4. Don’t go chasing waterfalls

So why don’t all companies work like this?

Cagan has a surprising answer: waterfalls

Many tech companies still follow a linear, step-by-step product development process. Ideas are generated, business cases are built, roadmaps are developed, and requirements are scoped. Then, the baton is passed through design, development, testing, and deployment. These tasks cascade downwards and each depends on the completion of the previous one.

This “waterfall” model might look neat on paper, but you may already have spotted the flaw. A waterfall only flows in one direction. Once a decision flows downstream, it’s hard to swim back up and suggest a change of course.

The result? Designers and engineers are brought in too late to shape the solution. Developers become code monkeys, tasked with execution, but given little room to contribute their creative or technical insight.

Cagan says:

If the first time your developers see an idea is at sprint planning, you have failed [...] getting the engineer’s perspective earlier also tends to improve the solution itself, and it's critical for shared learning.

So what should companies do differently? The answer is surprisingly low-tech and straightforward – get the right people in a room together.

This means product managers, engineers, and designers working side-by-side from day one – collaborating like a small start-up to solve problems together, rather than passing specs down the chain like a big assembly line.

Cagan sums it up:

Good teams [...] sit side-by-side, and they embrace the give and take between the functionality, the user experience, and the enabling technology. Bad teams sit in their respective silos, and ask that others make requests for their services in the form of documents and scheduled meetings.

Set for success 

The Sonos app debacle was a costly and high-profile failure – but far from rare. As Cagan notes, 90% of product releases fail to meet their objectives.

There’s no guarantee any product will succeed. Most ideas miss the mark. But had Sonos followed the Inspired principles – user-driven discovery, cross-functional collaboration, prototype testing, and outcome-focused delivery – they might have avoided alienating their fan base.

Instead, they became a cautionary tale of what happens when companies lose sight of how great products are built.

Exceptional products are the result of teams empowered to learn fast, adapt constantly, and stay relentlessly focused on solving the right problems. That’s what turns good ideas into products people can’t live without.