The Problem is That We Don't Understand the Problem

wrote this on in . 4 reactions

In 1959 a British industrialist Henry Kremer created a prize of '50,000 ($1.3M) challenging the first person to build a plane that could fly a figure eight around two markers, each half-a-mile apart. The planes would be powered only by the pilot's body (no engines were allowed). Over the 17 years that followed, 50 official attempts were made to create such a plane and win the prize. None of them came close.

It wasn't until 1977 when an aerodynamicist named Paul MacCready decided to tackle the problem. After observing the 50 unsuccessful attempts he came to a realization: "The problem is," he said, "that we don't understand the problem." A recent UXmag article does a great job of describing what MacCready meant by this:

MacCready's insight was that everyone working on solving human-powered flight would spend upwards of a year building an airplane on conjecture and theory without the grounding of empirical tests. Triumphantly, they'd 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, a couple hundred meters later the flight would end with the pilot physically exhausted. With that single new data point, the team would work for another year to rebuild, retest, relearn. 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.

The problem was the problem. Paul realized that what we needed to be solved was not, in fact, human-powered flight. That was a red herring. The problem was the process itself, and along with it the blind pursuit of a goal without a deeper understanding 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.

We've mentioned before how rapid prototyping and iteration even helps kindergarteners beat MBAs thanks to their intuition for experimentation. McCready recognized a similar opportunity here: the problem was the process and not the product.

If he could increase the speed of his own innovation through an alternate process, McCready also knew could increase the volume of feedback he would get over a much shorter period of time. He was even able to run more than one test flight during a single day! These iterations gained momentum for his plane design and helped him learn faster. On Aug. 23, 1977, McCready won the Kremer prize.

Iteration Builds Momentum
Everyone is a Designer
Abu 0zaskod3 j4nthwyubpspihmxakayfsblaz0mgm
Create, Debate and Win Your Team Over

It has 1 comment.

Geoff (ZURB) says

I've always been taught that the more ideas you can get out on paper, be it sketching, building or any other way to manifest ideas, the more that can come out of the process. The process of ideas is the most important step to bringing forth a product. Because nothing is perfect from the beginning, we need to process, test and adjust. Some people like to invest everything into one product and hide it from the rest of the world until it is "ready," but almost always, that product fails. If you have the courage to share and test over and over, something amazing will happen. Process can't be overlooked because in the end, our product comes from the process.