The problem is we don't understand the problem
azarask.in
azarask.in
MacCready's insight was that building a human-powered aircraft was 'easy' if you knew how to build such a craft. (And in fact today you can take his work and build your own Gossamer creation) So the challenge was this was a search for a new airplane design methodology to explore the airplane design space, and that this 'meta' problem had a much different form of solution than the stated problem of 'build an airplane that does this.'
The applicable insight for entrepreneurs is that if someone thinks solving problem 'x' in a cost effective (i.e. monetizable way) is "impossible", then the search is for new and different ways to solve 'x' which are more efficient than the well known ways. Too meta I know, sorry.
The conclusion is: to solve a problem you need a tool with which you can iterate fast.
The author states that we don't understand we need such tool...
Here's a great video on that:
Back in the 90's in the workstation lab, I tried again and again to get fellow 1st year CS students to use the debugger. They'd always say, "I'm too busy for that now!" Then, around 3am, they'd be desperate enough to let me show them how to recompile with the debug option, and we'd take 60 seconds to find the pointer bug they'd been pulling their hair out over for hours.
This is also why I love Smalltalk. Your objects and your code execution become palpable, handleable things. You can even collect examples and put them aside in groups for further categorization and pondering. Yes, not only do I sometimes have little clusters of Object Inspectors on my screen, I have sometimes had little groups of debuggers with alternate executions. This is not the normal condition, but if you ever get into a situation where you are making lots of comparisons, it's nice to know you can do this as easily as you could for real-life objects on an actual tabletop.
EDIT: Yes, sometimes I will play around with little stacks of execution stacks.
The best part is that you can re-invoke practically always!
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.”
Not understanding the problem and solving the wrong problem are 2 very distinct things.
Aerodynamics of conventional prop planes is by now a done deal. With anything from a Piper-Cub to a 747, there are tons of similar craft already existing you can imitate and a market from which you can draw funding to build near-production functionality prototypes.
This was not true for the extremely low power region of the design space, however. For that region of the design space, he returned to the "tinkering" paradigm of the Wright Brothers.
There is a clear and clearly useful analogy for startups here.
Once MacCready figured that out, creating the mylar + aluminum place becomes almost intuitive. However the best part of the story for me was the fact that this took place a full 18 years after the challenge had been issued. And we worry about missing an opportunity to address the challenges by weeks or months. Instead, let's remember that a solution twice as good will catch any front runner.
Wish more people would think about it.