UX Magazine

Defining and Informing the Complex Field of User Experience (UX)
Article No. 663 May 2, 2011

You Are Solving The Wrong Problem

There is some problem you are trying to solve. In your life, at work, in a design. You are probably solving the wrong problem. Paul MacCready, considered to be one of the best mechanical engineers of the 20th century, said it best: "The problem is we don't understand the problem."

Story time.

It's 1959, a time of change. Disney releases their seminal film Sleeping Beauty, Fidel Castro becomes the premier of Cuba, and Eisenhower makes Hawaii an official state. That year, a British industry magnate by the name of Henry Kremer has a vision that leaves a haunting question: Can an airplane fly powered only by the pilot's body power? Like Da Vinci, Kremer believed it was possible and decided to push his dream into reality. He offered the staggering sum of £50,000 for the first person to build a plane that could fly a figure eight around two markers one half-mile apart. Further, he offered £100,000 for the first person to fly across the channel. In modern US dollars, that's the equivalent of $1.3 million and $2.5 million. It was the X-Prize of its day.

Paul MacCready holding a Speed Ring, a device he invented for competitive glider flying.
Paul MacCready holding a "Speed Ring," a device he invented for competitive glider flying.

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, MacCready, decided to get involved. He looked at the problem, how the existing solutions failed, and how people iterated 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 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 latter, a years worth of work would smash into the ground. Even in successful flights, a couple hundred meters latter 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.

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, retest, relearn cycle went from months and years to hours and days.

Eighteen years had passed since Henry Kremer opened his wallet for his vision. 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 bit over a year after that, the Gossamer Albatross flew across the channel.

What's the take-away? When you are solving a difficult problem re-ask 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(S)

User Profile

Called an interface guru by publications like Wired and Fast Company, Aza is the co-founder of Massive Health, and was until recently Creative Lead for Firefox. Previously, he was a founding member of Mozilla Labs. Aza gave his first talk on user interface at age 10 and got hooked. At 17, he was talking and consulting internationally. Aza has founded and sold two companies, including Songza.com, a minimalist music search engine that had over a million song plays in its first week. He also creates modular cardboard furniture called Bloxes. In another life, Aza has done Dark Matter research at both Tokyo University and the University of Chicago, from where he graduated with honors in math and physics.

Add new comment

Comments

5
7

Aza, interesting story. I'd like to use it as part of a training on problem definition in a corporate training curriculum I am working on. Do you have a source for the quote "The problem is we don't understand the problem"?

23
23

I was curious about the 'Speed Ring" in the caption to one of the photos, so I did a little research. The thing he is holding is actually a cross section of a wing spar (see the Wikipedia article on Paul MacCready for the correct caption - http://en.wikipedia.org/wiki/Paul_MacCready).

He did actually invent the speed ring, but it is very different from the photo - see http://en.wikipedia.org/wiki/Speed_to_fly

23
27

I heard Paul MacCready speak in Los Angles over twenty years ago. Very inspiring. There are also a couple of books out about the flights of his planes. Worth reading. Thank to Dan Roam for putting the link to this story on FB.

24
30

Every problem can be iterated quickly upon. Usually, iterating the most significant problems factored out from bigger problems is wise.

29
22

So humankind should just give up on problems that can't be iterated quickly upon? What if someone gave Christopher Columbus this advice?

22
31

I wouldn't necessarily want to find a faster way to "fail". I think what you would want to do is recover faster from failure, but I get what you are trying to convey.

25
28

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

Excellent advice!

29
26

Thanks for this inspiring story, really like the way it was put on.
"The problem is we don't understand the problem."
Nice quotes.

28
28

Excellent advise.