A common characteristic among exceptionally creative and innovative people is that they read outside their central field of expertise. Many of the solutions they find have their origins in the answers other people have found to problems in unrelated fields. Breakthrough ideas can happen when you adopt practices that are common in other fields. This is a foundational heuristic to open software development. Raymond (1999) observes:
Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone. Or, less formally, "Given enough eyeballs, all bugs are shallow." I dub this "Linus's Law." (P. 41)
So named for Linus Torvalds, best known as the founder of the Linux operating system. In the case of the Linux operating system, no one developer can can have absolute expert knowledge of every line of code and how it interacts (or not) with every other line of code. But collectively a large pool of contributing developers can have absolute expert knowledge of the system. The odds are good that one of these contributors has the expertise to identify an issue in cases where all the other contributors may not understand that particular part of the system well enough to recognize it as the source of the agony.
This idea easily scales to include knowledge domains beyond software development. That is, solutions being found by people working outside the problem space or by people working within the problem space in possession of expertise and interests outside the problem space.
Imagine, around 1440, a gentleman from Verona named Luigi D'vino who makes fine wines for a living. And imagine a gentleman from Munich named Hans Münze who punches out coins for a living. Then imagine a guy who is familiar with the agricultural screw presses used by winemakers, has experience with blacksmithing, and knowledge of coin related metallurgy. Imagine this third gentleman figures out a way to combine these elements to invent "movable type." This last guy actually existed in the form of Johannes Gutenberg.
Assuming D'vino and Münze were each experts in their problem space, they very likely found incremental innovations to their respective crafts. But Guttenberg's interests ranged farther and as a consequence was able to envision an innovation that was truly revolutionary.
But if you, specifically, wish to make these types of connections and innovations, there has to be a there there for the "magic" to happen. Quality "thinking outside the box" doesn't happen without a lot of prior preparation. You will need to know something about what's outside the box. And note, there aren't any limitations on what this "what" may be. The only requirement is that it has to be outside the current problem space. Even so, any such knowledge doesn't guarantee that it will be useful. It only enhances the possibility for innovative thinking.
There is more that can be done to tune and develop innovative thinking skills. What Bock suggests touches on several fundamental principles to transfer of learning, the "magic" of innovative thinking, as defined by Haskell (2001, pp. 45-46).
Learners need to acquire a large primary knowledge base or high level of expertise in the area that transfer is required.
Some level of knowledge base in subjects outside the primary area is necessary for significant transfer.
An understanding of the history of the transfer area(s) is vital.
To summarize, in your field of interest you must be an expert of both technique and history (lest your "innovation" turn out to be just another re-invented wheel), and you must have a sufficiently deep knowledge base in the associated area of interested from which elements will be derived that contribute to the innovation.
References
Haskell, R. E. (2001). Transfer of learning: Cognition, instruction, and reasoning. San Diego, CA: Academic Press.
Raymond, E. S. (1999) The cathedral and the bazaar: Musings on Linux and open source by an accidental revolutionary. Sebastopol, CA: O'Reilly & Associates, Inc.
Image by István Kis from Pixabay