You Are Solving The Wrong Problem
My first blog post for the Month of May came to me while I was in search of some inspiration to stay calm and composed and let the Agile Way do its thing for our efforts at Menoovr.
When I decided to pursue menoovr as a business after receiving raving fan reviews at Startup Weekend San Jose 2011 that ended on Apr 17,2011 met with my friends at Karthavya and discussed the project. As members of a fraternity that believes in Good Customer Service and having experience in Customer Expectation Management in India, they duly asked me when does this need to be completed by.
I had the option of telling my team that we needed to be "done" by this date and over a course of time see that deliverable missed and/or frustration/friction fly around, but I didn't do that as I have but many a times in my career seen it happen and decided to pursue the Agile way.
The agile way or to be more precise the SCRUM way says cut a slack of 40% during iteration one and 20% at iteration two allowing for learning curves and infrastructure setup especially when working with very new technologies. But to do that for an aggressive person like me involves some learning curve. When you are on such a learning curve you sometimes need inspiration. This one is mine, I hope it inspires you too.
The blog post is "as is" from the article "You Are Solving The Wrong Problem" by Aza Raskin posted on UX Magaznine. To view it at UX Magazine's web site please click here.
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."
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 ofHenry 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.
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.
