How Borrowing Brilliance Actually Works in Practice
Borrowing Brilliance The Six Steps To Business Innovation By Building On The Ideas Of Others Author David Kord Murray Apr 2010 is essentially a playbook for taking ideas from one industry and applying them to another. The core concept isn't revolutionary if you've ever worked across multiple sectors, but the framework gives you a structured way to do it without feeling like you're plagiarizing or making stuff up as you go along. The six steps Murray outlines are: identify a model that works elsewhere, deconstruct how it works, adapt it to your context, test it at small scale, refine through iteration, and scale once it proves itself. It sounds obvious when written out. The hard part is actually finding the right models and knowing when adaptation is legitimate versus just copying. I spent three years running a mid-size logistics operation before someone handed me this book. We were trying to reduce warehouse pick times, and I had been stuck in engineering-mode for months. The breakthrough came when we looked at how grocery stores do stock rotation using FIFO systems. That's literally it. The insight from Borrowing Brilliance is that you don't invent solutions from nothing. You find working solutions in adjacent or unrelated fields and translate them.
The first step—identifying models that work elsewhere—requires discipline. You have to actively look outside your industry instead of waiting for innovation to come from within. I used to do this informally, which meant I'd stumble on good ideas occasionally but never systemically. The book's contribution is forcing you to be deliberate about it.
The Deconstruction Phase Is Where Most People Mess Up
Step two is deconstructing how the borrowed model works. This means understanding the mechanics, not just the surface-level approach. When I tried adapting the grocery store FIFO system, I almost missed the critical component: the color-coded dating labels. The pick-time reduction wasn't just about rotation order. It was about visual cues that eliminated decision-making at the shelf level. Deconstruction requires you to ask why each element exists, not just what it does. If you skip this, you end up copying forms without functions, which is a common mistake. I've seen companies implement features from other industries without understanding the underlying problem those features solve. The result is feature sprawl that doesn't actually move metrics.
Adaptation Requires Translation, Not Replication
Step three involves adapting the model to your context. This is where you decide what parts transfer directly and what needs modification. The grocery FIFO system couldn't be bolted onto our warehouse operations unchanged. Our products don't have expiration dates in the same way. But the principle of visual prioritization translated well. I learned through experience that adaptation has a failure mode: over-modification. When you're uncomfortable with a foreign concept, you tend to reshape it so heavily that it loses its effectiveness. The sweet spot is keeping the core mechanism intact while adjusting the implementation details. This usually means stripping away everything except the functional essence of what you're borrowing.
Testing at Small Scale Prevents Costly Failures
Step four is testing the adapted model in a controlled environment. Murray emphasizes starting small because cross-industry borrowing introduces uncertainty. You don't know how the adapted model will behave until you see it in action within your specific context. In my logistics example, we tested the visual prioritization system in one warehouse aisle before rolling it out company-wide. The test took two weeks and revealed that our pickers needed different visual cues than the grocery model provided. We switched from date-based labels to zone-based color coding, which matched our inventory structure better. A full rollout without that test would have cost us approximately eight hours of picker retraining per warehouse location.
Iteration Is the Unsexy Part That Matters Most
Step five is refining based on what the test reveals. This is often skipped or rushed because people want to declare victory and move on. The problem is that cross-industry models almost always need adjustments after initial implementation. The more removed the source industry is from your own, the more refinement you'll likely need. I found that the refinement phase typically takes two to three times longer than the initial test. That's not a law of nature, just an observation from running this process repeatedly. You should budget accordingly rather than hoping iteration will be quick.
Scaling Only After Proven Results
The sixth step is scaling the refined model across your organization. Murray warns against scaling before the model has been proven in multiple test contexts. A single successful test is a data point, not proof. You want to see the model work in different conditions before committing resources to full deployment. We rolled out the visual prioritization system after successful tests in three separate warehouse zones over six weeks. The rollout to all twelve warehouses took about ten days. Pick times dropped by roughly eighteen percent within the first month of full deployment. That result came from patience during testing, not speed during implementation.
When This Approach Fails
Borrowing Brilliance is not universally applicable. There are scenarios where it won't help. If your industry has highly regulated constraints that make cross-industry models incompatible, the framework hits a wall. Pharmaceutical manufacturing, for example, has compliance requirements that make direct borrowing from other sectors nearly impossible. You can still use the principle of looking elsewhere for inspiration, but the adaptation step becomes much more restrictive. The framework also assumes you have people who can think laterally. If your team is purely execution-focused without analytical depth, deconstructing and adapting foreign models will be frustrating. You need at least one person on the team who enjoys figuring out how things work under the surface. A more suitable approach for highly constrained industries is reverse-engineering competitors within your own sector. It's less exciting but more practical when external models can't legally or practically apply.
Practical Takeaway
The book is worth reading if you're responsible for operational improvement and feel stuck in industry echo chambers. The framework itself is straightforward enough that you don't need to absorb every detail to apply it. The real value is in the case studies Murray provides, which show you what deconstruction and adaptation look like when done correctly. I'd recommend skimming past the introductory material if you already understand the basic concept. The step-by-step breakdown and the failure modes he documents are where the practical content lives. The rest is repetition of the core idea with various examples. If you're looking for a download or full text, this is a published book from 2010 and isn't freely available online. You can find it through standard bookstore channels or as an audiobook through most major platforms.
