A startup is an experiment – it takes a set of hypotheses about market conditions and it tests them. An established organization can also begin a start-up enterprise. A successful startup is a market disruptor, bringing efficiency and value to a market. A sliver of this efficiency is retained as profit and distributed to shareholders. Sometimes start-ups fail because the fundamental hypothesis is invalid. If this is realized early, pivoting may be feasible. Other times, however, hypothesis testing is not straightforward. Failure to execute is the real startup killer. When a startup fails to execute, the hypothesis is never given a chance to truly be tested.

There are many startups that have failed, but their deaths have a purpose. Their stories depict experiments–often very expensive multi-year experiments–and the results of those experiments. For those that were unable to fully test their hypotheses, we can still learn from their flawed assumptions about successful execution. While successful companies seem like likely role models, successor bias, and the fact that companies are often not transparent about their inner workings, means that there is generally more to learn from those that fail than those that succeed. Like a politician learns from history, and a scientist learns from scientific literature, the aspiring entrepreneur must too learn from these stories.

There are several resources that record the stories of failed startups, such as startupgraveyard, autopsy.io, reddit shutdown, and Collapsed

Here’s a look at a few failed experiments, and the lessons their stories provide:

Covered Oregon

Lesson: Engaging properly is critical regardless of the budget or the reputability of the vendor.

Covered Oregon was a $240 million project that ended in failure. The project was contracted to Oracle using federal funds with the intent to build an online health insurance marketplace and to overhaul Oregon’s existing IT infrastructure for its health care programs. The project failed without even launching, and Oregon was forced to use the Federal exchange instead. The debacle resulted in the resignation of then Oregon Governor John Kitzhabe, a breach of contract lawsuit from Oracle, a counter civil complaint for breach of contract and racketeering from the state of Oregon, and this scathing congressional report. Failure to this extent is uncommon, so it is important to understand what went wrong.

Issues such as high-risk scheduling and scope creep plagued the development of Cover Oregon. However, many of these issues would have been avoided had a different project management structure been chosen, meaning that the engagement model was, in fact, the root cause. As the congressional report finds:

“The Cover Oregon project suffered from an overly ambitious scope and risky contracting practices. Most of the contracts awarded by OHA and Cover Oregon specified that contractors were to be paid on a time and materials basis, rather than upon completion of certain deliverables.”

Although time and materials is a common engagement model, it often not the best choice. Here the vendor Oracle was not incentivized to produce successful results, but rather to maximize the time billed for the project. Any change orders received for new features, regardless of the quality, value, or cost of the proposed change, would increase Oracle’s profit. It is no coincidence that costs in these types of engagements tend to expand until the total maximum budget is reached, as it did here. Time and materials engagements can work when the client’s system integrator is knowledgeable enough to oversee solution discovery and help shape the direction of the project. But in this case, Oregon had no IT professional managing the project. Oracle, therefore, failed to benevolently act to constrain project scope and produce efficient solutions that would keep costs reasonable.

Color

Lesson: Integrating feedback is mandatory. Make sure the product is loved and enjoyed before staging a massive product launch.

Color was the 7th startup of Bill Nguyen, a prominent silicon valley serial entrepreneur whose ventures include Onebox.com and Lala (exited for $850 million and $80 million, respectively). Color earned $41 million in funding by promising to compete with Facebook with an “elastic network” and a “multilens” experience. It was essentially a social photo feed that took into account physical proximity. Rumored to have received a $200 million offer by Google prior to the launch date, expectations were high for Color.

A large marketing budget and $425,000 spent for the domains of color.com and colour.com meant that Color had a widely anticipated launch. Color enjoyed the No. 2 spot as the most downloaded social-networking app, but it didn’t last. Users quickly rated it one or two stars (out of 5) and quickly abandoned the app. The problem was that for Color to work there needed to be nearby users, making it essentially useless for the initial user base. It would have been possible to work around the problem by pre-seeding the database or doing a geographically-limited roll out. However, the discovery came too late, as users also struggled to navigate the UI and found the app to be generally confusing. After an unsuccessful pivot to a Facebook-based platform, Color failed.

Color’s failure is often used as an example of the Web 2.0. Whereas the Web 1.0 was characterized by large series A rounds, expensive domains, and big product launches, the Web 2.0 was characterized by the methodology of lean product development that leads to products that differentiate themselves by providing value. Web 1.0 strategies no longer work well. The users would not enjoy the product, regardless of the marketing budget. A better approach is to build an MVP with modest funds, and through successive Agile iterations build upon the product in response to user feedback.

Mt. Gox

Lesson: Consider security, organization, and industry standard development practices as an integral part of the product.

At its peak between 2013 and 2014 Mt. Gox handled 70% of all Bitcoin transactions in the world. In February 2014, Mt. Gox suspended all trading and announced that 850,000 bitcoins had been lost, an amount at the time worth more than $450 million. Overnight, a successful tech leader in the booming industry of cryptocurrency collapsed. A deeper investigation revealed that issues at the company had gone unnoticed for several years. The story of Mt. Gox is a cautionary tale of what may lie below the surface of a seemingly high-quality product.

On Wednesday, July 26, 2017, the Department of Justice released an indictment against Russian national Alexander Vinnik for, among other reasons, allegedly laundering funds from the hack of Mt. Gox. While the entire story remains obfuscated, it is clear that security controls at Mt. Gox were severely lacking. Security controls are often categorized as physical, technical, and administrative. Each of these controls must be implemented to avoid points of failure. Mt. Gox, however, went astray in all three.

Physical Controls

Physical controls may include closed-circuit surveillance cameras, alarm systems, or physical locks. In the case of Mt. Gox, you would expect standard physical controls common at financial institutions. However, it is clear that such precautions were not taken.

A bitcoin can either be placed in a hot wallet, where it retains an active internet connection to the Bitcoin network, or a cold wallet, where it does not. Currency exchange services like Mt. Gox should keep the majority of digital assets in secure cold storage, while only keeping whats needed to cover transfers in hot wallets. At one point Mt. Gox indicated that the cold storage was behind a firewall, describing a cold storage that actually retained an internet connection and not one that was in fact cold. After an attack in June of 2011 Mt. Gox moved the majority of bitcoins to safety deposit boxes dispersed throughout Tokyo. However, these cold wallets were not correctly reconciled with customer accounts. After the original report of loss, Mt. Gox claimed to have found ~200,000 missing Bitcoin, indicating that they hadn’t sufficiently organized and managed their cold storage at all.

Technical Controls

Technical controls, such as encryption and automated audit logging are necessary components of any tech company and are especially crucial for crypto-currency companies like Mt. Gox. However, failure here is obvious.

Mt. Gox blamed transaction malleability for the multiple incidences. Transaction malleability refers to a documented issue with the Bitcoin design, and it could potentially allow a malicious user to abuse the exchange by altering the ID of a Bitcoin transaction before being confirmed on the Bitcoin network. However, if transaction malleability is indeed to blame for Mt. Gox’s issues (this independent study says it’s not), it would have been due to negligence to resolve the issue. There are technical workarounds for the issue of transaction malleability – workarounds that, unlike other exchanges, Mt. Gox failed to implement.

Technical auditing is also an important aspect of technical controls. A company as prominent as Mt. Gox should have considered undergoing independent security audits, which Mt. Gox never did. Systems should also rigorously follow a procedure for new code releases, such as having separate QA and staging servers, etc. Mt. Gox, on the other hand, did not even use standard version control practices, such as Git.

Administrative Controls

Administrative controls involve controlling organization level factors to limit security risks, such as performing background checks on new personnel or limiting their access to the system. It also refers to regulatory factors, which is an interesting topic in the cryptocurrency world.

In the case of Mt. Gox, the CEO Mark Karpeles was the only employee to have full access to the system. Considering that he was by no means a security expert, not hiring more qualified engineers early was a huge administrative mistake.

Mt. Gox escaped regulation, largely because Bitcoin was at the time a new technology. However, future exchanges are unlikely to have this luxury. A few already offer insurance against loss. Rigorous accounting, required by financial institutions, was also ignored. Had Mt. Gox been held to a higher level of scrutiny, many fewer people would have lost their money.

Google Glass

Lesson: Identify early when your product has no market fit.

Google Glass, a novel of engineering that promised to usher in a new technological era, never lived up to its lofty expectations. Google Glass, at least in its known consumer form, was only available to the general public from May 2014 to January 2015. Even with the budget of Alphabet (Google’s parent company), and the benefit of Google’s impressive brand, the product just couldn’t succeed. Although criticized heavily for its marketing strategy, the reason Google Glass couldn’t find product/market fit was not that the product wasn’t great, but because the market wouldn’t accept it. The underlying hypothesis–that consumers would be eager to purchase augmented-reality wearables–was invalid.

Instead of a traditional product launch, Google instead opted to go with an early adopter program. “Glass Explorers” could pay $1,500 to become early adopters. This group, mostly comprised of tech aficionados, were highly critical of the product. Google followed up by investing little in paid media marketing and failed to get many excited about the launch date.

The less than optimal marketing aside, Google Glass failed because there was no product/market fit it could find. Successful products solve a real-world problem and provide value to the marketplace. While it may provide a sense of exclusivity, Google Glass also provided a feeling of unease to those around. People felt their privacy intruded when those around were wearing Google Glass, unsure if the wearer was actively recording. Ultimately, society deemed privacy too valuable, and no wearable will be able to change that anytime soon.

While Google Glass is an interesting example of a visionary product that wasn’t accepted, Google’s next move is also a great example of what to do with your product fails. Google next released Google Glass Enterprise Edition and has found industrial application for Google Glass, like increasing factory efficiency by augmenting worker’s experiences on the production line.


This article was last updated at: Tuesday, October 10, 2017 9:25 PM