Sonos app rewrite saga

24 Aug 2024

This was posted orginally on X and LinkedIn, reproducing it here for posterity.

It’s been fascinating to watch the Sonos, Inc. app rewrite saga unfold. While it’s impossible to know the constraints they are dealing with as an outsider, I’ve led rewrites of several popular apps and can talk about this topic. What I think they should do 👇

Revert to the old app immediately to stop the bleeding and then fix the new app. Fix all issues and test the new app very thoroughly with external beta testers before relaunching. The rewrite shouldn’t have shipped without this in the first place.

If that’s not possible, then make big changes to the team first. Have the best crisis leader at the company take over. Find all ICs who have been raising the alarm and give them authority to move fast. Remove anything that gets in the way - people/processes/tools/etc.

Define a clear exit criteria that the entire company needs to work towards. Create a dashboard where everyone can track progress. Share weekly updates with the entire company using this and nothing else.

Create a single source of truth - all issues, feedback and bugs should flow into a single place. Have a small team (≤3) triage and prioritize them. Everyone else focuses on fixing them.

Appoint DRIs - Divide problems by areas (feature x, stability, performance, etc) and appoint a single Directly Responsible Individual (DRI) for each. Set clear goals for each of them to achieve. Prioritize skill over titles/experience while picking them.

Sign the entire company up for testing - You can no longer rely on just the QA team to find bugs. Everyone needs to test the app daily, especially all managers and execs. All hands on deck.

Improve external comms - Looks like all the feedback and complaints, at least early on, was not handled properly. It’s time to over-correct. Reply to every single app review, forum post, etc. first to acknowledge the issue, and later informing that it has been resolved.

Ship faster - Weekly app releases are table stakes in 2024. Ship fewer changes more frequently so that they reach users faster. Put risky changes behind server-side feature flags. Publish a list of all the fixes shipped in every release.

Celebrate wins - this is going to take months to resolve and the team needs to remain motivated if you want a shot at succeeding. Celebrate wins after shipping every significant improvement. This helps create momentum and things will start to get easier.

Finally, I wish them all the best. This is a nightmare scenario for any mobile team and hope they overcome this soon.