Have you heard any of these lately? "Fail fast." "Always make new mistakes." "Ready, fire, aim." There's a certain brand of innovation that praises failure, attempts to launch something as soon as possible, and is skeptical of advance planning. This works pretty well for small-scale apps and experimental launches, but it's not a good idea for larger projects that really need to succeed.

Case in point is the U.S./Mexico border wall, which is back in the news. There's a huge amount of money at stake, and the project will almost certainly fail. I know this because I wrote a book, in part, on the last time the U.S. government pursued a "fail fast" approach on the border.

About ten years ago the U.S. tried innovating along the US/Mexico border with, not quite a wall, but a series of sensor towers - a few dozen spread across 50 miles - listening for crossing attempts. Once installed, it immediately became clear that the system didn't work. As I wrote in Customers Included:

"The sensors, which had been promised to detect people from miles away, would instead mistake windblown leaves, or even raindrops, for humans. There were more problems in the Border Patrol vehicles, which had been outfitted with laptops for agents to access the sensor data. The laptops, not equipped to work in the dusty environment of the desert, were prone to breakdowns - and even when they were working, Border Patrol agents had difficulty using them while driving on rough terrain."

The project, which cost taxpayers about a billion dollars, raised the obvious question: why didn't anyone find out what Border Patrol agents wanted, before building a system for them to use? This was, in fact, exactly the question that "60 Minutes" posed to the head of the project, near the end of its ill-fated run. Again, from my book:

The TV program ‘60 Minutes’ sent host Steve Kroft to Arizona to interview the head of SBInet, a man named Mark Borkowski. What followed was a surprisingly frank assessment from a government official:

Kroft: I’m just kind of amazed that they’re building this, what’s gonna be a multi-billion dollar system for the Border Patrol, and nobody asked the Border Patrol what they needed or wanted, or what would be helpful . . . that’s a pretty big mistake.

Borkowski: It’s a huge mistake, it’s a huge mistake.

There was one positive outcome of this misadventure: a rare moment of bipartisan agreement in Congress! Both sides of the aisle came together to agree, unequivocally, that this border project was a total waste of taxpayer money. (Senator John McCain called it "a complete failure.")

While it was nice to see bipartisan agreement, there's a larger lesson here about innovation: throwing money at a problem, while ignoring the people affected by the project, is a guaranteed failure. It appears, as the new border wall project takes shape, that the U.S. hasn't learned that lesson. (The government has posted an RFP for designs, due later this month: see the announcement and view some early reactions from architects. Here in New York, artists are building a #wallthatunites.)

The only difference this time around is scale. Last time we wasted a billion dollars. According to the New York Times and NPR, the new border wall is estimated to cost taxpayers over $20 billion.

For those teams that believe they must always "fail fast," the border wall provides a good counterexample. To put it mildly, launching a $20 billion idea without including users along the way is a bad idea. Taxpayers will not be happy to see their money - and that of future generations, to pay off the debt incurred - spent this way.

So the next time someone on your team points at a cluster of Post-It notes and says, "Let's launch it! Let's fail fast," just remember that there is another way. Spend a little time gaining some user insight - finding out what your users want - and then launch something that might actually succeed. What a radical idea! (And really, read the book.)

  1. As with so many other bad ideas, it comes from a good idea but is implemented by people who don’t understand the original idea. “Make mistakes faster” is actually about learning from mistakes faster. It is not about not planning, or ready, fire, aim, or we can figure out the requirements as we code. It’s about taking the time on a regular, and short-interval basis, to stop, re-group, look at what we’re doing, understand if it’s still a good thing, and then re-steer our efforts. You’re looking to strike the perfect balance between too many meetings and administrative overhead, and continuing too far down a bad direction before someone says “stop!” A fail faster approach to work does require you to know where you’re going from the beginning, but you must also to be willing to stop often to make sure, now that you’ve learned something, that your original idea is still correct.

    • I think it should be research if it’s an actual good idea from the start. Are we looking at the actual effect of undocumented immigration? Are we looking at the causes? Are we looking at what sustains the immigrants?

      It’s almost like designing a ocean-faring boat when you live in a desert. You can certainly take a shot at it, but without true understanding the properties of the ocean itself, you are doomed to failure.

  2. @Andrew – I think you have a point about how “fail fast” can work *in theory*. Yes, of course it’s better if teams “learn fast” and thus avoid unnecessary mistakes. But *in practice*, at least as I have observed teams out there, many of them latch on to “fail fast” as a license to launch something quickly with no meaningful inclusion of users. (There are several examples in “Customers Included,” like the MyFord Touch story.)

    @Mark – thanks for the pointer to the Duhigg piece – I hadn’t seen it before I ran this column. On point, though!

Comments are closed.