“Resonance Sensitivity”: The Rare and Differentiating Skillset That Makes Design a Deep Competitive Moat

by ChatGPT based on prompts from Jonathan A. Handler

by Jonathan A. Handler, MD, FACEP, FAMIA

Design Can Be a Deep Competitive Moat

People often claim physical design and user experience (together, for short, “design”) are easily copied by big companies and therefore not a competitive moat. Yet, that rarely seems to happen. Most products seem pretty “meh”. If great design is easily copied, then why does it happen so rarely?

To those who say design is not a competitive moat, tell that to Apple, Porsche, Tesla, Coke, Disney, and Nike. They didn’t get the memo. Two of these (as of 6/3/2026) are in the top 10 largest companies by market cap in the world. If design is not a competitive moat because it is easily copied, then how do so many companies successfully compete this way?

Copying Design Is Hard Because It Requires the Rare Quality of “Resonance Sensitivity”

Most organizations struggle to copy the designs of their best competitors, and often not because of inadequate capital or patent protections. In fact, it seems the bigger the organization, the less able it is to execute great design… unless it “began life” as a great design company. Mediocre products often sell well by competing on price or other characteristics besides quality and user experience. However, too many people conflate sales with user delight (aka, “awesomeness” of the product). Sales tell you how many chose your product. Awesomeness tells you how glad they are they did. Although awesome products sometimes fail and “meh” products frequently succeed, many of the very biggest and best companies offer successful and awesome products.

Why is it so hard for a big company to simply copy something awesome from a competitor, even when not blocked by patents? Most build products by following widely held “best practices”, yet those “best practices” typically seem to produce mediocre products. Why is that? The usual answer I’ve heard is, “They didn’t follow the best practices enough! They need to do them more and better.” In most cases, I suspect they need to do the opposite.

Specifically, I think Steve Jobs nailed it when he answered the question, “How do you know what’s the right direction?” by saying, “Ultimately, it comes down to taste.” By taste, I infer he means the ability to discern whether a product or service (“product”) will create elevated states in those who experience it, such as delight, desire, deep appreciation, and intellectual flow. In its highest form, taste also includes the ability to recognize the product characteristics that enable those states. In shorthand, I label “taste” as the ability to quickly discern if and why a product is awesome.

Unfortunately, most seem to believe “awesome” is either: 1) so subjective that it’s irrelevant, or 2) practically everyone can quickly and easily recognize “awesome.” I infer from Jobs’ statement that neither could be further from the truth. Just about everything that leads to mediocrity seems to flow from these misperceptions.

Even more challenging, those who lack taste generally cannot see when others lack it, and may not even value it. This cascades into product teams that lack taste entirely or that fail to defer decisions to team member(s) who have it.

Lack of taste has contributed to the common “best practice” of producing an “MVP.” This horribly misleading term sounds like “Most Valuable Player,” the best possible accolade, when it really means “Minimum Viable Product,” the worst possible product that a customer will still accept. Building an MVP practically guarantees mediocrity as the best possible outcome, and garbage as the typical outcome. In short, this is because:

  1. Product teams tend to grossly underestimate the minimum that customers will accept, and to misjudge which elements are critical vs. which are nice to have. To quote myself, “The minimum bar is almost certainly too low and off-target.“
  2. Given budget constraints and deadlines, teams drop the “nice-to-have” features. Then they rationalize that “must-have” features aren’t really “must-have” and drop some of them too, further lowering the bar on their “MVP.”

The resulting product releases fail because they fall far below the minimum customers will accept. Specifically, it has been reported that 85% of new consumer products fail and 90% of tech products fail. I’ll bet virtually all those product teams felt they followed “best practices.”

Everything about most big organizations seems to work against taste. Although it can be objectively assessed under my definition (see Note below), I believe most use the colloquial definition, therefore they consider it too subjective and don’t value it. Since leaders who lack taste often can’t identify those who have it, they can’t put those with taste into decision-making positions. People told they lack taste generally feel insulted, and people who assert or attempt to prove they have taste are frequently perceived as egotistical self-promoters. It’s no surprise then, that “taste” seems valued only in rare, “design-forward” organizations.

Note: One way to objectively measure “taste“ under my definition is to compare predictions of product satisfaction survey results to actual results from intended users. Another is to have been the lead decision-maker or creator for products in that domain that intended users loved (e.g., as demonstrated in user surveys).

Since “taste” feels like a charged term that gets interpreted differently than I mean in this post, we need a new term. I propose “resonance sensitivity,” and for those who lack it, “resonance insensitivity” (thank you, Physics, for letting us borrow your term for this context). I define “resonance” in this context as the tendency of a product to facilitate an elevated mental state in its user (as described above). Those with resonance sensitivity can quickly tell if customers will resonate with products, at least those in a specific domain (e.g., clinical medicine, guitar playing, etc.). Everyone else (most people in the world) has resonance insensitivity in that domain. Resonance sensitivity in one domain does not necessarily imply sensitivity in another.

Although I don’t know if it’s a requirement, resonance sensitivity in a domain often accompanies competency in that domain. Competency implies an ability to perform excellent work, which itself implies an ability to recognize excellence. However beware that:

  • People often conflate competency across domains. For example, software often comes with a graphical user interface (“GUI”). An extremely competent programmer who writes brilliant and beautiful code may use it to build clunky and ugly GUIs. Although software code and GUIs often go together because software code creates GUIs, competency in coding does not guarantee competency in GUI creation. In fact, I have found these two skillsets almost never go together. Yet teams often leave the initial GUI design to the programmers without assessing, or even having the ability to assess, whether the programmers are also great GUI designers.
  • People seem generally terrible at recognizing competency and work quality. Managers typically assume competency based on current job title, previous job titles, years of experience, education, the candidate’s self-claimed successes, and references. All of these are poor substitutes for an actual expert directly assessing competency by evaluating actual work and its quality.

Zen and the Art of Motorcycle Maintenance provided an outstanding description of this latter point in Part 1, Chapter 2, then Part 2, Chapter 8. I suggest you read these yourself if you haven’t already, but for now:

<BEGIN MILD BOOK SPOILER ALERT>
The protagonist goes to “veteran” motorcycle repairmen who, multiple times, charge him more than he can afford. Each time, these so-called experts fail to fix his motorcycle. Ultimately, he becomes his own expert by taking apart the engine and fixing it himself. The fix proved simple.
<END MILD BOOK SPOILER ALERT>

Even Though People Think It’s Common, the Ability to Recognize Awesome (Resonance Sensitivity) Is Rare

Ironically, Zen and the Art of Motorcycle Maintenance, which has been described as a “meditation on quality,” was reportedly rejected over 120 times by those who failed to recognize its quality before an editor accepted it for publication. It went on to sell 5 million copies. Even the editor who agreed to publish it never expected to make a profit. The original manuscript and other related items were acquired by the Smithsonian Museum of American History. Even though this book is both a bestseller and, perhaps even more relevant to this post, a federally recognized natural treasure, it was not recognized as such by the first 120+ so-called experts.

This story repeats itself over and over in virtually every product domain. Soon after Steve Jobs led the release of the groundbreaking Mac, he was forced out of Apple, the company he had founded. Apple’s board of directors had told the young innovator/founder that he needed a CEO to provide “adult supervision”. They apparently didn’t think he could lead Apple now that it had become a big company. Jobs hired John Sculley, a former Pepsi CEO, to lead Apple. Then they clashed, the board sided with Sculley and Jobs was out. Did the business veterans make the right choice when assessing who was most competent to lead Apple? Did the CEO veteran outperform the inexperienced innovator? Under Sculley, Apple made and released the Newton, a product reportedly “synonymous with failure.” The day after Sculley resigned in 1993, the company reported revenue was down 97% from the prior year. Jobs returned as “interim CEO” on September 16, 1997, and soon after was made official CEO. The day before Jobs’ return as CEO, Apple’s market cap was $2.5B. On the day before he resigned as CEO due to illness, Apple’s market cap was $281 billion. Over 100x growth in less than 15 years! His legacy continues. In November, 2025, only four countries in the world had entire economies greater than Apple’s market cap. Perhaps even more relevant to this post is what was produced during his incredible tenure: the game-changing and beloved iPod, iTunes and iTunes Store, iPhone, iPhone App Store, iPad, iMac, MacBook Air, Apple Stores, and more.

Most people think product teams will obviously and instantly recognize when their product is awesome. I assert the opposite: that not only are most unable to quickly recognize “awesome” (resonance insensitive), when they do think something will be awesome, it probably won’t be. Why? Because, awesome often results from innovation, elegance, or both. Although the resonance insensitive may like the ideas of innovation and elegance, they often reject those ideas in practice because:

  • Since an innovation is (by definition) new and different, the resonance insensitive find it out of step with the rest of the industry:
    • “If this is so great, why isn’t everyone else doing it?”
    • “In fact, nobody else is doing this.”
    • “Our expert consultants say this violates best practice.”
  • When compared to the rest of the industry’s products, an elegant product may seem overdone to the resonance insensitive:
    • “Are these fancy details critical, or just nice to have?”
    • “Will people really care about this or even notice it?”
    • “Our expert consultants don’t think this will matter.”

So, organizational decision-making often deems “meh” as awesome while deeming “awesome” as out of step, overdone, or both.

Resonance Insensitives Often Fail to Recognize When Their Products Are Awful

Upping the ante, “The Team” often ends up composed of resonance insensitives (since resonance sensitivity is rare and domain-specific), and resonance insensitives usually fail to recognize when work is “awful.” Even though people can usually recognize awful in products they use, they commonly struggle to recognize it in products they produce. This occurs because, often:

  • The Team’s members would never be users of the product and therefore don’t experience it as the users would.
  • The Team makes no attempt to “dogfood” the product (find some way to use any aspect of it in their own daily routines).
  • The Team fails to spend significant time shadowing real users and deeply understanding their day-to-day work, beyond perhaps a quick meeting or a site visit.
  • The Team’s members are incentivized to “avoid churn” and get the product out the door on time and within budget, meeting the bare minimum requirements. The incentives encourage rationalization that a bad product is adequate (e.g., “It’s just two extra clicks, what’s the big deal?”).
  • Even if one member of The Team correctly recognizes a product as awful, there is usually tremendous pushback from The Rest of The Team, such as:
    • “Are you sure it’s really that much of a problem? Because if we change it now, it will blow our budget and schedule.”
    • “It’s too late to change it — we’ll ship it and ‘learn’ from customer feedback.”
    • “No one else on The Team thinks it’s a problem.”
    • “We showed mockups to real users and they thought it was fine.”
    • “It meets the business and project requirements.”
    • “We worked hard on this and you are telling us our work was bad, and by extension, that we are bad!”

Note: In this post, I have capitalized “The Team” because I often see people act as if each team is a separate and very special entity, endowed with superpowers far beyond the capabilities of its individual members, and far beyond the abilities of any other individual on Earth. I suspect this rarely leads to the best product outcome.

Even Copying an On-Market Product’s Design Requires Resonance Sensitivity in the Final Decision-Maker to Succeed

Now imagine something on the market for some time that has been widely recognized as awesome. The Team at a competing company aims to simply copy it. What happens? “Well,” they tell themselves, “it’s not patented, but we can’t just copy it because then we will look like copycats rather than innovators. Plus, we have some great ideas to make this awesome thing even better.” They can’t help themselves; they simply can’t bring themselves to follow the adage, “if it ain’t broke, don’t fix it,” or, “if it’s awesome, don’t ruin it.” When The Team members don’t know how to create awesome, or even distinguish awesome from awful, the “great ideas” aren’t great at all. Via “groupthink,” their version of the product often “regresses to the mean.” This is a well-recognized, frequent outcome of “designing by committee.” However, by misclassifying “design by committee” as “teamwork and collaboration,” it becomes “best practice” rather than “worst practice.” Ahhh, who doesn’t love corporate doublespeak!

Note: Teamwork and collaboration are, of course, fantastic and important. But, generally someone has to be the final decision-maker, or at least the “tie breaker”, and if that person lacks resonance sensitivity, the product will reflect that. The great examples I have seen of incredible collaboration in the design of awesome all had an amazingly resonance sensitive final decision-maker at the helm. Consider the “Brain Trust” at Pixar, per the excellent book, Creativity, Inc.: Overcoming the Unseen Forces That Stand in the Way of True Inspiration. Although composed of deeply resonance sensitive individuals, final decisions still remained in the hands of the film’s director. And I believe that an absolutely critical requirement to be a director at Pixar, from what I have seen, heard, and read, is resonance sensitivity in film, the ability to recognize and cultivate film awesomeness.

So, although people often say that large competitors can “easily copy” a great design, I think they have it backwards. More often, I have seen that small competitors can often copy great work because they aren’t yet big enough to accrue the dysfunctional team dynamics and counterproductive incentives that tend to result from the “best practices” adopted by large organizations. As the small competitors grow, their resonance sensitivity tends to get diluted unless they avoid the problematic “best practices” and remain “design-forward.”

The Simpler the Design Is in Theory, the Harder It May Be to Copy in Practice

People commonly think that the simplest designs are the easiest to copy. I think the opposite! The simpler and more elegant the design, the less likely a team can implement it without adding complexity and degrading it away from awesome. Worse, after they’ve tinkered with it, they often think it’s better because they are resonance insensitive and can’t tell the difference between awesome and awful. Years ago, this concept was expressed in a video I found both brilliant and hilarious.

Don’t believe me? Consider the reported experience Jeff Bezos, the founder and CEO of Amazon, trying to implement one-click purchases on his website. This seems (at first) like a simple, obvious “invention,” and yet he was granted a patent for it. People were outraged, saying essentially, “How can you get a patent for ‘inventing’ something so obvious as purchasing with one button click?!” But Bezos prevailed in his patent defense. He reportedly had many travails trying to get the team to follow his simple and elegant request. He asked for one-click purchasing, yet the first version built by the team had maybe four clicks. He sent them back and they returned with two clicks, one to purchase (“See! It’s a purchase with one click!”) and another to confirm. Nope, he had to send them back, yet again, to build it as truly one click. The Team couldn’t believe he really wanted one-click to buy a product. What if the user clicked by accident? The key insight behind this invention was to allow users an undo button to cancel the purchase immediately afterward if they had made a mistake. Since most people don’t click “Buy” accidentally, it would truly be a one-click purchase for most. Resonance insensitivity nearly caused elegant simplicity to degrade into an overly complex and less awesome design. It took the persistent force of will of a directly-involved and resonance sensitive CEO to prevent it.

Cultivating Resonance Sensitivity

Can resonance sensitivity be cultivated in a domain? I believe it can! Even a relatively small investment may reduce resonance insensitivity. Interestingly, most don’t seem to make that small investment, thus the moat remains secure. Heck, I’d bet most people won’t even make it this far in this post!

For those willing to make the investment and to believe I have any right to provide advice on garnering resonance sensitivity, here are my thoughts. As always, YMMV and caveat emptor.

1. Read the Classics to Learn the Basics of Resonance Sensitivity

I think some “must-read” classics include:

Note: Some reading this post may mistake my comments as demonstrating the need for UX teams. Yes and no. 😀 Too many think they can just offload design and resonance sensitivity to the UX team. Too many think that having the title of “UX designer” equates to having resonance sensitivity. Unfortunately, UX designers often lack expertise in the domain of the specific products on which they are working, and worse, many are nowhere near achieving the expertise that develops after 10,000 hours of practice in UX itself. Too many UX teams rely far too heavily on simple heuristics (e.g., ensuring accessibility for users), basic assessment tools, misused “personas“, and usability testing. Many UX folks I’ve met have not read some, or even any, of the classic texts in the field listed above, and I consider that immediately suspect. I’ve worked with some true UX experts — they were outstanding and greatly improved our products. Having now some resonance sensitivity to UX expertise, I can see the tremendous differences between true UX experts and those who just carry the title.

2. Experience Excellence, and Do So with Intention, to Enable Resonance Sensitivity

If you’ve never experienced awesome, then mediocre, and even bad, might look great. If all you’ve ever eaten is raw flour, then an unsalted cracker might taste amazing in comparison. But try the bread from a master baker, and suddenly the mediocrity of that unsalted cracker becomes obvious. Exposure to excellence is critical to recognizing excellence, and that exposure must be done with intention.

By intention, I mean paying attention to what, specifically, you find great about the product. For the master baker’s bread: How does it look? How does it smell? What is its texture? How does it sound when you cut it, break it, and bite into it? How does it feel in your hands? What is its temperature? How does it feel in your mouth? How does it taste at first? How does it feel as you chew it? What is the aftertaste? There are surely many other questions to ask. You don’t have to like the product you are trying. Within the product category, you just have to experience (with intention) products people love and products they don’t.

If you have been lucky enough to only experience “the best,” or haven’t experienced “mediocre” in a long while, then you may have to go the other direction. You may have to experience the mediocre and the bad to gain context. This recalls an experience I had years ago. One of my friends is a master flamenco dancer. For years, virtually the only flamenco shows I saw were those of his troupe or those he recommended. In other words, the best of the best! Then I went to a show all on my own. I couldn’t believe the difference. I paid careful attention to the differences between this troupe and the others I’d seen. Although I do not consider myself resonance sensitive for flamenco, after years of watching the best followed by a single viewing of a less skilled troupe, I instantly became less resonance insensitive.

Not everyone will agree on what is great. You may disagree with “experts.” From this, you might infer that resonance sensitivity is, indeed, entirely subjective. However, remember that you are not learning how to agree with so-called experts. You are not trying to predict whether a product will generate huge revenue. You are not trying to predict whether everyone on Earth will find it awesome. You are not trying to predict whether a corporate procurer will think it was a good buy for their employees. You are not even trying to match your own preferences with those of the intended user. You are trying to cultivate an ability to recognize whether an appropriately targeted yet meaningfully-sized set of users will have an elevated experience with it. In other words, predicting whether intended users will love it.

3. Deeply Understand the User to Effectively Apply Resonance Sensitivity

I believe that a deep understanding of the product’s user, while not sufficient alone, is an absolutely necessary requirement for resonance sensitivity in the domain of the product. Most intended users probably have enough resonance sensitivity to try a product (or functional prototype) for a short time in real-world use (not just wireframe reviews or unrealistic user testing) and determine if others will find it awful or awesome. With that said:

  • Some users may be outliers in their needs, wants, environments, and/or workflows, so that they prove resonance insensitive despite their expertise.
  • More commonly, they will not give quality feedback.
    • They may not be able to describe exactly what they like and don’t like.
    • They may give overly positive feedback because they 1) want to be nice, or 2) see potential and assume the product will be improved from unusable to awesome before release.
    • They may give overly harsh feedback because they overestimate what their colleagues will consider minimally acceptable, perhaps especially if the reviewer is a manager.

Simply having an intended user on The Team as the final decision-maker is not enough. That person must have resonance sensitivity (e.g., developed it by reading the classics and experiencing excellence with intention, and/or has otherwise demonstrated sensitivity).

It may not be possible to have an intended user as the product’s final decision-maker, nor is that likely necessary. However, whoever serves as the final decision-maker must have resonance sensitivity, including a deep understanding of the intended users. A key to deeply understanding the user (if the final decision-maker is not already in that domain or very close to it) generally involves shadowing the user in their actual work for at least several hours, and often for days or even weeks. Unfortunately, this almost never seems to happen. 🥲

  • As noted, too many treat “personas” as a substitute for shadowing users. They create imaginary names, apply stereotyped demographics, call them “personas”, present them in a slideshow, and never use them again (thank goodness, because this use of personas is useless, IMO).
  • The shadowing often gets substituted with progressively more inferior approaches that fail to serve the need. These substitutes almost never lead to a deep understanding of the user and the relevant need:
    • The shadowing gets substituted with an onsite tour for The Team, which is nothing at all like an individual shadowing actual users for hours.
    • The tour gets substituted with user interviews.
    • The interviews get substituted with a PowerPoint presentation.
    • The presentation gets substituted with documents for the team to read on their own.

Perhaps worst of all, the final decision-maker (often a manager or executive), virtually never deigns to do any of this work. They typically see this as “low-level, detail work to be done by The Rest of the Team.” Despite an elevated position, if the final decision-maker hasn’t cultivated resonance sensitivity, including a deep understanding of the user, the product is usually doomed. Conversely, in those rare instances that the final decision-maker has resonance sensitivity, a wonderful product has the potential to result.

Warning for those who are, or become, resonance sensitive: When someone else is the final decision-maker and relatively resonance insensitive, you may find those situations frustrating because the final decision-maker will likely often disagree with your insights and fail to be convinced by your reasoning. Resonance sensitives may thrive best when they are the final decision-makers, working in design-forward organizations with other resonance sensitives, and/or operating in “any yes” rather than “all yes” environments.

Conclusion

Resonance sensitivity may be rare, but I don’t think it’s hard to improve one’s resonance sensitivity. The first step is to recognize when you don’t have it yet.

About 20 years ago, I would have reacted poorly if someone told me I lacked taste. I didn’t know what I didn’t know. However, my close friend and mentor decided I needed to develop an eye for quality and important details (less resonance insensitivity). Suddenly, fashion magazine after fashion magazine was delivered to my house. “You don’t have to read the articles,” my friend said. “Just look at the pictures and learn. People who make these magazines tend to have a careful eye for the fashions that will bring delight to their readers.” Soon, out in the world, I was noticing fabrics, styles, designs, and so much more. I could see who was tracking each trend, remaining retro, or marching to the beat of a different drum. I learned to see things that had always been there yet had been invisible to me.

Over the years, I’d like to think I’ve become less resonance insensitive in many domains, and resonance sensitive in a few. But what if I’m overstating my acumen, and/or my assertions are wrong? In the worst case, if you follow my suggestions, you will have read a few widely-recognized classic texts in this area, tried some amazing products and paid more attention to your experience with them, and spent more time with your anticipated end users. In the best case, you will have developed greater resonance sensitivity and the products you build or manage will be the better for it. Best of all, those products will have a deeper competitive moat, thanks to your resonance sensitivity. Since many fail to recognize this as a significant moat, your competitors may underestimate you and your products. From my experience, they do so at the peril of their own business. After all, you might not be “the next Steve Jobs,” but then again, you might be.

All opinions expressed here are entirely those of the author(s) and do not necessarily represent the opinions or positions of their employers (if any), affiliates (if any), or anyone else. This content also does not necessarily reflect the author(s)’s experiences or opinions in relation to any current or former employers and/or affiliates (if any). The author(s) reserve the right to change his/her/their minds at any time. Nothing here should be construed as medical advice.

, , , , , , , , , , , ,
, , , ,

Leave a comment