I’ve often railed against the standard marketing trope of “here’s our proven system for solving problem X.†Proven systems pitches classify problems as simple to solve and, by implication, those with problems as either ignorant or lazy. My objection is that this offers little help for hard problems and we live in a world with lots of hard problems.
Suppose your interests lie in attacking hard problems? Call them wicked problems or management messes, these are the problems that constitute more of our agenda.
One answer is to acknowledge that answers to hard problems have to be custom crafted, with solutions tailored to the environment and the circumstances. Can we glean some value from the “proven systems†hawkers even as we recognize that our problems of interest don’t fit their premises?
MacGyver provides the essential strategy here. The point is to treat a proven system as design input to crafting a custom solution. To do this effectively, the first step is to reverse engineer the proven system. First, to understand the assumptions about the problem structure and environment driving the system design. Second, to extract the components and subsystems comprising the system. Third, to pattern match between the problem characteristics of the two systems—those of your problem and those built into the assumptions of the proven system. Fourth, to adapt and apply the subsystems that apply.
This approach depends on recognizing that you own the problem. That means rejecting an implicit premise of the proven systems perspective that you can transfer ownership and responsibility to the system.