The collapse of Mt.Gox this week has sent shockwaves through the early-adopting tech community. Hundreds of millions of dollars worth of bitcoins have been lost, and account holders are justifiably angry about their missing balances. It is easy to heap blame on Mt.Gox’s founders and call this a once-in-a-lifetime calamity, but the context behind the company’s demise is far more pernicious and occurs far more frequently than it should in the tech community.
Users today take incredible risks when starting to use a product, risks that they don’t appreciate when they click on a trial button or download an app. System reliability is often assumed when it is unwarranted, and data integrity and loss prevention is rarely guaranteed. Worse, we make little mention of the beta status of new services, misleading users to believe that the product they are using is far less risky than it appears in the glossy product pages. In no other industry would companies be able to get away with this, and if we don’t change things fast, our exceptional absence of regulation may become part of the past.
The Mt.Gox saga lays bare a dirty little secret of Silicon Valley: the users of our products are our test subjects. We experiment with them, we A/B test on them, we fail them, sometimes repeatedly. My own data has been overwritten, modified, deleted, leaked, and deleted again by early startups. Multiply by the multitude of services we all use in our daily lives, and suddenly it can seem that every few days something is going wrong.
Even early-adopting tech users are starting to become wary. As Jeff Atwood wrote on his blog this week, “I’m not excited by the prospect of installing an app on my phone these days. It’s more like a vague sense of impending dread, with my finger shakily hovering over the uninstall button the whole time.”
He is not just talking about system reliability, but also the corrosive business models that encourage data to be leaked to any number of revenue-generating affiliates. When I installed Secret a few weeks ago, I hesitated for several days when it asked for complete access to my contacts, an ironic notion given its anonymous functionality. While the company has done nothing to abuse my trust, it is the ecosystem that is encouraging this level of cynicism.
There is plenty of blame to go around for the state of affairs. It starts with founders who take a lean startup approach and attempt to hoodwink customers into believing that their software is far more developed and stable than it actually is. How many times have we heard about the “100 year startup” that gets talent-acquired a mere 14 months after its existence? We also need to look toward VCs and other investors who demand steep growth profiles even at the expense of core business operations. Startups should always be building the proper foundation for a long-lived company, even if that means a slightly less intense focus on growth.
Part of the problem is that technology startups are very different from other kinds of new ventures. Due to the lock-in nature of software and services, users often become reliant on a product very shortly after signing up. Unintentionally, their data starts to accumulate, and they may develop processes with the service that are difficult to transition to another system. Every company needs to deeply protect their customers, and yet, we see startups like Mt.Gox act so completely cavalier with customer information.
Furthermore, many users are still living with a software mentality, because the software they purchased in the past works for years. Most of the world does not upgrade all of their software in lockstep with the latest product releases. That is one reason for the success of cloud services, but it also remains an Achilles’ heel – the company behind the service needs to survive in order for the service to continue functioning. My elementary school was still using computers from the late 1980s without too much hassle, but today, a company failing literally means it is no longer available to me.
To be fair, startups are necessarily experimental — more art than process. There are going to be hiccups, as there are in any new business as the team determines the best fit for a product in the market, or the right pricing structure. Large corporations are also not immune to these problems. Apple deserves some serious blame between the failed rollout of its new Mail application and the encryption vulnerability crisis of the past two weeks. Google’s shutdown of Google Reader last year was also quite damaging to many news junkies. But at least in that case, Google created sufficient lead time with its shutdown that other startups like Feedly were able to make the transition relatively seamless. Few startup users enjoy such convenience.
There are ways to avoid these outcomes. An easy one would be to take an open approach to data, ensuring that customers and users are always allowed to export their data. That open approach should also follow through in a startup’s communications, which should clearly indicate the expected reliability and guarantees of a service. Startups that are more advanced should begin to think through service-level agreements that guarantee certain levels of uptime, data integrity, and data-loss prevention. By making a lot of the reliability statistics key performance indicators for the company that are also contractually binding, a founder can set a high and consistent bar for service.
More simply, though, we need to commit to a founder culture in which we first do no harm. We owe nothing less to the early adopters of our software. Such a commitment does not have to come at a cost. WhatsApp was the largest acquisition of all time, and it used the programming language Erlang to build highly reliable systems for communications.
There is incredible opportunity for the next generation of startups to take reliability as their given, and for founders to prepare to build for the long-term. As users increasingly use services that fail their expectations, they are going to become more and more educated about what services to use, and which to avoid.
Comment