Paul MacCready won the Kremer Prize for human-powered flight in 1977, after the prize had been open for 18 years. Other teams spent years building aircraft, tested them once, crashed, and started over, meaning they had at most one learning cycle per year.
MacCready reframed the problem. Instead of “how do I build a human-powered aircraft,” he asked “how do I build something I can crash and rebuild in hours.” His Gossamer Condor was built from aluminium tubes, mylar, and piano wire, and it crashed constantly, but he’d rebuild it the same afternoon and fly again.
His competitors were solving the airplane problem, while he chose to solve the iteration problem.
When I first read this story1, I realized how useful of a framework it was. Identifying and solving the real problem demanded that one take a step back and think, resisting the urge to immediately chase the appearance of productivity or “bias for action”, and often facing the challenging task of convincing others to go against established norms.
Despite the challenges, the rewards were worthwhile: greatly increased chances of success, reduced cost of failure by making it fast, and sometimes the signal that the task wasn’t even worth embarking on in the first place.
Speed of iteration, like in MacCready’s case, can be the right problem2 because it allows you to stay nimble, react fast and adapt to your needs, business or otherwise. When working across groups of people, it can often mean removing yourself from being a bottleneck so you can tackle bigger and better things.
Stop and find the real problem. Often it’s speed. The time you spend making iteration cheap pays back faster than jumping straight into the work.
Footnotes
I read this in 2011 from Aza Raskin, who was Head of UX at Mozilla at the time. It’s influenced my thinking since.↩︎
This applies directly to AI and coding agents. See Solving the Right Problem: Economist Edition, Part 1.↩︎