Wanna Solve Impossible Problems? Find Ways to Fail Quicker

A case study in how an intractable problem — creating a human-powered airplane — was solved by reframing the problem.



1959 was a time of change. Disney released their seminal film Sleeping Beauty, Fidel Castro became the prime minister of Cuba, and President Dwight D. Eisenhower made Hawaii an official state. That same year, a British industry magnate by the name of Henry Kremer wondered: Could an airplane fly powered only by the pilot’s body?

Like Da Vinci, Kremer believed it was possible and decided to try to turn his dream into reality. He offered the staggering sum of £50,000 for the first person to build a human-powered plane that could fly a figure eight around two markers set a half-mile apart. Also, he offered £100,000 for the first person to fly across the English Channel. In modern U.S. dollars, that’s the equivalent of $1.3 million and $2.5 million. The Kremer Prize was the X-Prize of its day.


[Paul MacCready holding a “Speed Ring,” a device he invented for competitive glider flying.]


The problem was the process itself.

A decade went by. Dozens of teams tried and failed to build an airplane that could meet the requirements. It looked impossible. Another decade threatened to go by before our hero, Paul MacCready, decided to get involved. He looked at the problem, how the existing solutions had failed, and how people were making their airplanes. He came to the startling realization that people were solving the wrong problem. “The problem is,” he said, “that we don’t understand the problem.”

MacCready’s insight was that everyone who was working on solving human-powered flight would spend upwards of a year building an airplane on conjecture and theory without a base of knowledge based on empirical tests. Triumphantly, they would complete their plane and wheel it out for a test flight. Minutes later, a year’s worth of work would smash into the ground.

Even in successful flights, the flight would end with the pilot physically exhausted just a couple hundred meters later. With that single new data point, the team would work for another year to rebuild, re-test, and re-learn. Progress was slow for obvious reasons, but that was to be expected in pursuit of such a difficult vision. That’s just how it was, went the common thinking.

The problem was the problem. MacCready realized that what needed to be solved was not, in fact, human-powered flight. That was a red herring. The problem was the process itself. And a negative side effect was the blind pursuit of a goal without a deeper understanding of how to tackle deeply difficult challenges. He came up with a new problem that he set out to solve: How can you build a plane that could be rebuilt in hours, not months? And he did. He built a plane with Mylar, aluminum tubing, and wire.



The first airplane didn’t work. It was too flimsy. But, because the problem he set out to solve was creating a plane he could fix in hours, he was able to quickly iterate. Sometimes he would fly three or four different planes in a single day. The rebuild, re-test, and re-learn cycle went from months and years to hours and days.

Find a faster way to fail, recover, and try again.

Eighteen years had passed since Henry Kremer opened his wallet for his challenge. Nobody could turn that vision into an airplane. Paul MacCready got involved and changed the understanding of the problem to be solved. Half a year later later, MacCready’s Gossamer Condor flew 2,172 meters to win the prize. A little more than a year after that, the Gossamer Albatross flew across the English Channel. So what’s the lesson? When you are solving a difficult problem, re-frame the problem so that your solution helps you learn faster. Find a faster way to fail, recover, and try again. If the problem you are trying to solve involves creating a magnum opus, you are solving the wrong problem.

[Thanks to Alan Kay for turning me on to this story.]

About the author

Aza is the founder of Massive Health, and was until recently Creative Lead for Firefox. Previously, he was Head of User Experience for Mozilla Labs