When is it better to kill a project? Silicon Valley often lionizes failed technology efforts, provided those projects had ambitious aims. Fail as fast as possible, goes the maxim of many a startup, and soon enough you’ll hit success. Although this collective mentality can lead to crushing depression among startup founders, it’s also endured for a number of years. When does a technology company know when something’s a failure? That can prove a difficult question to answer. Take the example of Slack, the ultra-popular enterprise messaging service. In 2011, a startup run by Flickr co-founder Stewart Butterfield launched “Glitch,” a browser-based game. Less than a year later, “Glitch” failed due to a lack of players—but Butterfield and a small crew of tech pros decided to take the internal messaging system they’d built during the game’s development, and market it as an enterprise-centric communications tool. The rest, of course, is history: Slack is a resounding success, used by dozens of companies. In the end, perseverance allowed Butterfield’s team to transform crushing failure into dizzying success. Some startup founders, upon hearing stories like that, feel compelled to stick with their projects to the ignoble end. They’ll burn through every cent of VC funding, and sit typing in their rented office until the landlord shows up to shut the place down. But that sort of effort doesn’t guarantee success: for every Slack, there are a thousand startups that attempted some sort of Hail Mary pass and failed. After years of trial and error, Google X—the tech giant’s innovation lab—has a solid formula for deciding when to shut down a project. Google X is famous for its so-called “moonshots,” such as self-driving cars. Rather than drag out projects that may not succeed in the short- to medium-term, the Google X team ruthlessly evaluates and eliminates. If a project likely won’t make money on the open market, it is killed; if it may take fifteen or twenty years to mature, it is killed; if the underlying technology seems unsound in any way, it is killed. As Google X head Astro Teller told The New York Times, the company pays employees to behave ruthlessly: “They will not raise their hands and say, ‘This project is just not what we should be working on, unless you start bonusing [sic] them.” Promotions are another incentive. Of course, Google X has lots of money to burn, and its employees can afford to walk away from a project rather than see things through to the bitter end. Even for the most cash-strapped startups, though, Google’s core lesson still applies: no matter how much you love a questionable project, sometimes it’s better to kill it as soon as possible, rather than continuing to burn money and time. The Value of Killing a Project Fast
When is it better to kill a project? Silicon Valley often lionizes failed technology efforts, provided those projects had ambitious aims. Fail as fast as possible, goes the maxim of many a startup, and soon enough you’ll hit success. Although this collective mentality can lead to crushing depression among startup founders, it’s also endured for a number of years. When does a technology company know when something’s a failure? That can prove a difficult question to answer. Take the example of Slack, the ultra-popular enterprise messaging service. In 2011, a startup run by Flickr co-founder Stewart Butterfield launched “Glitch,” a browser-based game. Less than a year later, “Glitch” failed due to a lack of players—but Butterfield and a small crew of tech pros decided to take the internal messaging system they’d built during the game’s development, and market it as an enterprise-centric communications tool. The rest, of course, is history: Slack is a resounding success, used by dozens of companies. In the end, perseverance allowed Butterfield’s team to transform crushing failure into dizzying success. Some startup founders, upon hearing stories like that, feel compelled to stick with their projects to the ignoble end. They’ll burn through every cent of VC funding, and sit typing in their rented office until the landlord shows up to shut the place down. But that sort of effort doesn’t guarantee success: for every Slack, there are a thousand startups that attempted some sort of Hail Mary pass and failed. After years of trial and error, Google X—the tech giant’s innovation lab—has a solid formula for deciding when to shut down a project. Google X is famous for its so-called “moonshots,” such as self-driving cars. Rather than drag out projects that may not succeed in the short- to medium-term, the Google X team ruthlessly evaluates and eliminates. If a project likely won’t make money on the open market, it is killed; if it may take fifteen or twenty years to mature, it is killed; if the underlying technology seems unsound in any way, it is killed. As Google X head Astro Teller told The New York Times, the company pays employees to behave ruthlessly: “They will not raise their hands and say, ‘This project is just not what we should be working on, unless you start bonusing [sic] them.” Promotions are another incentive. Of course, Google X has lots of money to burn, and its employees can afford to walk away from a project rather than see things through to the bitter end. Even for the most cash-strapped startups, though, Google’s core lesson still applies: no matter how much you love a questionable project, sometimes it’s better to kill it as soon as possible, rather than continuing to burn money and time. 
