Many of you have been reading about the recent issues with the new version of the Sonos app. As Sonos owners, some of you may have experienced these problems firsthand. I became a Sonos owner just within the past year and have been very satisfied with the sound quality of their speakers. The old app functioned well, integrating seamlessly with Spotify, SiriusXM, Pandora and other music services. Being able to control the speakers and music from within the app, or even outside of it, was a good experience.
A few months ago, Sonos released a new app. While it looked promising on the surface from its new UI (User Interface), it turned out to be filled with bugs and functionality that didn’t work. In essence, the app looked better but worked worse than its predecessor. For example, if you tried to play music in the living room, it would start playing in the dining room instead or vice versa. Volume controls didn't work correctly, and overall, the app was super buggy.
Given my 30+ years in the software development business, I wanted to share my thoughts on what possibly went wrong here. Recently, Patrick Spence, the CEO of Sonos, issued a letter to all Sonos users, admitting that they needed a new app and rushed its creation. This haste led to the problems users are now facing. Unfortunately, I’ve seen this happen before with companies.
I believe there are two major failures here, which serve as important lessons for all of us.
1. Rushing the Development Process
We get to see the inner workings of a variety of different businesses with the work we do at Visus. Occasionally, management imposes a tight timeline for delivering a solution without fully understanding what is required to design or build the solution. And when I mean design it, it’s not just the graphical interface but designing the entire solution including architecture, APIs, and the specifications for all the functionalities.
When a timeline dictates the effort, and the effort is larger than the timeline allows, shortcuts are taken, such as adding more people or cutting corners to get the product out. However, this approach rarely results in a good experience or final product.
Over the years, I’ve learned that if management insists on a timeline that is too short for the necessary level of effort, it's important to take a step back. Ask yourself: What can we realistically deliver within this timeline that we can stand behind? That’s where the MVP (Minimum Viable Product) concept fits in. Iterating and rolling out additional features after the MVP rollout would likely provide a much higher probability of success and a feedback loop to consider from users.
I've seen this scenario play out time and again, and I've heard similar stories from clients with internal teams who were pushed to deliver something as quickly as possible. When you're dealing with a major re-architecture, redesign, or brand-new app, you need time to design the solution properly, develop it, and, most importantly, test it before you release it.
2. Inadequate Testing
The second lesson learned from the Sonos app debacle is the apparent lack of proper testing. Had the app been properly tested by a QA team, someone should have put the brakes on its release and said, "We rushed this, we had a timeline, but we should not publish it yet because of all the problems we encountered."
By going ahead and publishing the app despite its flaws, Sonos caused more pain and damage not only to its loyal users but also to its brand. It is estimated that this fiasco will cost Sonos $20 to $30M to fix. If the app needed an extra 2-3 months to be released in a functional state, that would have been a much wiser and cheaper decision than dealing with all the negative press and user dissatisfaction they’re facing now.
Over the years, we've refined our process to get things right the first time and we do that with our 4D Process. It's simple and straightforward but there are still companies that want to get something done fast by skipping design and rushing development. Unfortunately, we have scars from taking such projects on and have identified that those projects are not a good fit for us.
So, here’s the takeaway: When you have a project—whether in software development or another industry and a tight timeline constrains the design, development or testing process, take a step back and ask yourself, "If we go through with this build in a rushed fashion and it doesn’t work out, are we willing to live with the consequences and deal with unhappy customers?" Most likely, the answer will be no, and it’ll be time to rethink the best path forward and still accomplish the overall goal with an MVP and rolling out features afterwards.
Hopefully, Sonos will resolve the app issues soon, allowing us to once again enjoy not only the exceptional sound quality but also the seamless user experience we've come to expect from their products.
Prioritizing quality of development and testing always wins the race. Fast and sloppy leads to serious issues as in any other endeavor. I hope these insights helps you as you plan your next project.
About the Author
Michael Daoud is the founder and CEO of Visus LLC. He is passionate about technology, innovation, and leadership. Michael loves working with clients on strategy and how to best leverage technology for their organization's success and competitive advantage.