Sonos replaced its CEO last week. The company faced significant backlash after launching a redesigned app earlier last year that was plagued by bugs, missing features, and connectivity issues, frustrating customers and tarnishing its reputation. This also led to layoffs, poor sales, and a significant drop in stock price.
While I usually don’t comment on companies I’m not involved with, as a long-time Sonos user, I was very frustrated that the alarm feature I had been relying on to wake me up in the morning for well over a decade disappeared overnight. There were other issues, too.
Throughout my career, I have worked on numerous redesign projects. A fiasco like this is totally avoidable. Today, I am sharing a couple of internal blog posts I wrote for my team (when I was Wattpad’s CEO) about this topic. Of course, these are just examples of the general framework I used. In practice, there are many specific details in each redesign that I helped guide the team through, as frameworks like this are like a hammer. Even the best hammer in the world is still just a hammer. The devil is in the details of how you use it.
These internal blog posts are just some of the hammers and drills in my toolbox that I use to help our portfolio CEOs navigate trade-offs and move fast without breaking things.
Happy reading through a sample of my collection of half a million words!
Note: These two posts have been mildly edited to improve readability.
Blog Post #1 – Subject: Feature Backward Compatibility
I have gone through major technology platform redesigns many times in my career. One problem that arises every single time is backward compatibility.
The reason is easy to understand: users can interact with complex products (such as Wattpad) in a million different ways. There is no way the engineering team could anticipate all the permutations.
There are two common ways to solve this problem. First, run an extensive beta program. This is what big companies like Apple and Microsoft do when they update their operating systems. This approach is also a great way to push some of the responsibility to their app developers. Even with virtually unlimited resources, crowdsourcing from app developers is still a far better approach. However, running an extensive beta program takes a lot of time and resources. Most companies can’t afford to do that.
The other approach is to roll out the changes progressively and incrementally. It is very tempting to make all the big changes at once, roll them out in one shot, and roll the dice. However, I am almost certain that it will backfire. Not only is it a frustrating experience for both users and engineers, but it also makes the project schedule much less predictable and, in most cases, causes the project to take much longer than anticipated.
Next year, when we focus on our redesign to reduce tech debt, don’t forget to set aside some time budget for these edge conditions that are so easily overlooked. Also, think about how we can roll out the changes more incrementally to minimize the negative impact on our users.
Blog Post #2 – Subject: The Reversibility and Consequentiality Framework
The other day, I spoke to the CEO of another consumer internet company. In terms of the scale of its user base, this company is much smaller than Wattpad, but we are still talking about millions of users here.
Like us, this company has been around for over a decade. Not surprisingly, technical debt has been an ongoing concern. A few years ago, the team decided to completely redesign its platform from the ground up. The redesign was a multi-year effort, and the team finally pulled back the curtain a year ago. While it is working fine now, this CEO told me that it took a few months before they fixed all the issues and reimplemented all the “missing” features because many of their users were using the product in “interesting” ways that the new version did not support.
These problems are fairly common when redesigning a new system from the ground up. In practice, it is simply impossible to take all the permutations into account, no matter how carefully you plan. However, if we mess things up, our user base is so large that it might negatively impact (or ruin!) 100 million people’s lives in the worst-case scenario.
On the flip side, over-planning could burn through a lot of unnecessary cycles.
One way or another, we should not let these challenges deter us from moving forward or even slow us down because there are many ways to mitigate potential problems. In principle, ensuring that the rollout is reversible and inconsequential is key.
The former is easy to understand: Can we roll back when things go wrong? Do we have a kill switch when updating our mobile apps? These are best practices that we have already been using.
However, at times, these best practices might not be possible. Can we reduce the consequentiality when rolling out? If the iOS app were completely redesigned, could we do it in smaller chunks, parallel-run the new and old versions at the same time, or try the new version on 0.1% of our users first? If not, could we roll out the new app in a small country first?
Again, our objective is not to avoid any problem at all costs. Our objective is to minimize (but not eliminate) the negative impact when things go wrong—not if things go wrong. Although Wattpad going dark for 100 million people for an extended period of time is not acceptable, in the spirit of speed, it is perfectly okay if we have ways to hit reverse or reduce the impact to only a small percentage of our users. These are not rocket science, but they do require a bit more thoughtfulness because our user base is so large that we can’t simply roll the dice.
P.S. This blog is licensed under a Creative Commons Attribution 4.0 International License. You are free to copy, redistribute, remix, transform, and build upon the material for any purpose, even commercially, as long as appropriate credit is given.
