“Fail fast” is a mantra in Silicon Valley. While the development sector is starting to accept more failure—through “Fail Fairs” and reports centred around learning from failure—it is still far from achieving the speed of failure practiced in, for instance, the tech sector. Most development programmes don’t know if their program is failing months or even years after launch, whereas tech ideas can recognise failure within days. Can the development sector catch up?

DAI recently launched a USaid project in Cambodia called Development Innovations, with the aim of funding tech ideas with impact on the social sector. The response from local NGOs, civil society organisations, and tech companies has been massive. To help the project build capacity and select the most promising ideas, DAI hired 17 Triggers, a design thinking firm for good causes, to run a two to four-day training for potential grantees on how to fail fast. I sat down with Mike Rios, chief innovation officer at 17 Triggers, to get his thoughts.

Where does “failing fast” come from?

To clarify, there are basically two types of failure: slow and fast. Slow failure wastes a lot of time and money. Fast failure helps you learn and improve, with little time and effort.

From what I can tell, fast thinking was born out of a painful mistake. In 1989, Jeff Hawkins created the first computer tablet for Samsung—more than 20 years before the iPad. Innovative idea? Yes, but a market failure. The device was big and heavy and people didn’t even want to hold it. Hawkins wasted years of his life and potentially millions of dollars. He vowed to never fail slowly again.

On Hawkins’ next project, to create a handheld device, he took a piece of paper, drew what the screen could look like, glued it on a piece of wood, and stuck it in his pocket for weeks. He kept looking for ways to improve it, failing fast and changing the screen as needed. Through many iterations and fast failures, he created the wildly successful Palm Pilot.

Today failing fast has developed into a science in the tech sector. For example the first rapid prototype of Google Glass took only 30 minutes, where they quickly learned that controlling the device with your hands would fail.

So why is failing fast good for development?

Most of the development sector is still operating under the slow failure model. A project can go on for three to five years and spend millions of dollars before managers know if it failed. It doesn’t have to be this way. By using some of the principles from failing fast, you can know if an idea is bound to fail within only a few days.

Predicting failure in just a few days is a big claim. Could you give an example from the training?

We had each team of experts create a two-minute pitch about their idea: What’s the problem for the user? How does their solution to the problem work? What’s the benefit? Then they presented to a jury of real people who could either vote “Yes yes yes!” they would like to sign up or “No thanks” if they weren’t sure or didn’t like it.

The response? For every group, the great majority of ideas received mainly “No thanks.” For example, one human rights organisation wanted to create a website that would host a human rights manual, but users didn’t want that. It doesn’t take quantitative evidence or a randomised control trial to learn what people clearly don’t want—just some honesty.

The good news is that while no one wanted an online manual, some people wished they could chat live and confidentially with a real person about how to handle land grabbing issues. Suddenly, an iteration presents itself and the idea can be improved, instantly.

What lessons are there in this training for the development sector?

We launched this training by telling participants they have a 99% chance of failure if they execute their idea as it is. What I liked most about this training is that every group embraced that mentality, recognised the need to fail fast, and did three to five iterations of their idea in less than two days. All it took was some honesty and humility. Some of the ideas changed drastically, saving potentially millions of wasted dollars. Could you imagine what would happen if we took two days to step back before implementing every development programme?

Often, we tell ourselves we should have the answers, but failing fast recognises that to succeed we need to acknowledge that we don’t know. Luckily, our users have all the answers.