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.
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 later, a years 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.
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.
18 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, 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.
Aza Raskin, former head of user experience at Mozilla Labs and creative lead for Firefox, now runs Massive Health, a startup that aims to help people take control of their health. This post originally appeared at his blog.
Categories: Uncategorized
Great post – got us all thinking!
Dr. Tschwiet is right on point. If anyone has learned anything from implementation of health IT, it is not that “digitizing” the record is the “cure” of all of our communication and health service delivery ills. It is merely a facilitator of communication and data warehouse/repository of information. It is how we USE this information in the delivery of care that is most important. Just having and communicating the data won’t lead to reducing morbidity and mortality. It is only when the data becomes used in a meaningful way at the bedside and for decision-making that will make the difference.
There are many successful models out there – Mayo, Kaiser – that deliver excellent quality for lower costs. The problem is our perverted reimbursement system. There is also to paradigm shift needed to move from a solely curative mentality to a prevention mentality. With everything we know about healthcare and the advancement of science, we should be the healthiest people in the world- yet we have serious chronic illness with significant comorbidities, fragmented continuum of care, lack of primary care physicians who have given way to hospitalists and specialists, etc. The SYSTEM is part of the problem. Patient-centered medical homes are getting closer to the way it used to be, with a “patient home” being the PCP and all the supportive services being provided as a network from that hub. Our fragmented healthcare and reimbursement system is piss poor, yet we have some of the brightest minds and best scientists in the world.
Having worked in healthcare for almost 20 years and quality improvement for 10, I have to agree whole-heartedly that not knowing what the problem is, IS indeed the problem. People go about their merry way thinking that they are solving problems when they have only just scratched the surface. Quality and process improvement are so much dirtier than just scratching the surface and using bandaids to smooth things over. Digging deeply into the organizational structure and finding the irritants and pain points will generally lead you to the problem itself…and after careful reflection on the problem and the implications, then, only then, will you be able to develop effective solutions.
I am confident that you are right, generally we are trying to solve the wrong problem.
I am not confident that you know what the right problem is.
But we certainly need all the help we can get, so I am very keen to see what Massive Health might be releasing as addressing the “right” problem. I did like the design of the food logging app…
-FT
The notion that there is an engineering solution to health care is in itself a problem.
Engineering should restrict itself to providing capabilities to implement a business solution, just like the cart should restrain itself from overtaking the horses.
I agree with Peter, we seem incapable of reaching consensus on what the solution, or the many experimental solutions that Joe would like to see, should be.
And this is not because we cannot define the problem. It is because we cannot agree on the constraints for possible solutions.
“We need to notice and extract lessons and guides from the different models that are already up and running here and there in healthcare, delivering better healthcare for less.”
Joe, health care here doesn’t lend itself to being able to be tinkered with to arrive at the best solution because it’s not a mechanical problem with a defined outcome – it’s an attitude problem. The best engineer in the world can’t out-engineer bad attitudes.
What is the U.S. trying to LEARN from the lessons that Europe, Japan, Canada, or Taiwan can teach us. We don’t want to learn, we just want to act tribally.
> If engineers could solve health care we’d have it done by now.
No, re-think the problem. The core problem with figuring out what works and what doesn’t in healthcare is a lot like the designers working for a year on one model: Most of healthcare in this country assumes one operating business model: Commoditized, insurance-supported, fee-for-service. It is obvious that this does not get us what we need. Then we argue about what would be _the_ model with which to supplement that, or substitute for it.
We don’t need to figure out _the_ model. We need to allow many different models to be tried in many different ways by different actors (such as health systems, states, tribes, employers, health plans). We need to notice and extract lessons and guides from the different models that are already up and running here and there in healthcare, delivering better healthcare for less.
My book on this, “Healthcare Beyond Reform: Doing it Right For Half The Cost,” will be out in March from Taylor and Francis.
Well, I have been following this undeniably brilliant young man for a while now. I’ll guess I’ll have to wait a bit longer for some concrete specifics. Visionary inferential paradigm-shift generalities are not gonna get us anywhere.
None of which is to advocate keeping our heads completely down in the weeds.
The philosophical connection between the wisdom of this post and our woes in health IT is that we continue to identify the problem as ‘digitizing the traditional clinical record’ rather than ‘improving the health of patients’.
The daily process of tediously documenting episodic moments of care in today’s EMR’s does a lot to codify the traditional health data but very little in leveraging the power of technology for reducing morbidity and mortality of disease.
Until we shift from episodic and utilization based payment incentives and towards wellness, outcomes, and patient-centered reimbursement, we will be stuck with digital documentation systems that inherently are designed to solve the wrong problem- documenting utilization and illness.
The problem is a political problem. Even though identified it does not make it easy to solve. If engineers could solve health care we’d have it done by now.
There was this book I was reading from T. Reid. He asked his doctor in rural India if he could heal him. He said ‘no, I won’t your body will’.
Could that be another way of looking at problem? Of course problem with that is it will render many of us unemployed.