Disruption Is An Ugly Duckling

Focus on use cases and customers that are below the incumbent's radar

While many successful businesses have been built that are not disruptive, the disruption model lends itself well to the technology industry where new innovations are able to change the market. This gets at the heart of how disruption works. Disruption occurs when an inferior solution for an unattractive market changes the rules of the game. Following on from the prior post on disruption, here are some practical tips on navigating the choppy waters of competing against much larger incumbents.

Disruption often emerges as the ugly duckling, overlooked and then scorned by bigger companies that know better. When you are building a business that is disruptive, it is helpful to keep in mind that the larger incumbent vendors will act rationally to serve their largest, most profitable customers. The disruptor is better served by focusing on use cases and customers that are below the incumbent’s radar. In other words, don’t moon the giant.

You don’t have to be better than the incumbents. You have to be different. Generally speaking, disruptive products are worse than the incumbents when evaluated using conventional criteria. However, there must be one key way in which the disruptor is better for the underserved market.

Avoid Head-on Competition

When I was at MySQL and Duo Security, two companies that were disruptive, I knew we had a limited amount of time to build our business before the incumbents caught on. In both cases, we focused on fringe customers (mid-market companies, startups, web companies, universities and the like) avoiding direct competition with the big guys. We were grateful that the incumbents weren’t paying much attention. But it made sense. They were focused on large customers in traditional markets: Fortune 1000, financial services, healthcare, government, and so on.

In the case of both MySQL and Duo Security, the disruptive solutions were much less sophisticated than the incumbent’s offerings. We were feature poor in comparison, but much easier to use. MySQL was famous for its “fifteen minute rule” meaning a novice could download and start running MySQL in fifteen minutes, compared to the weeks of training required for Oracle. In the case of Duo Security, customers could sign up for a free trial and the majority were up and running with a cloud-based solution in under 48 hours, something almost unheard of in the world of cyber security at that time.

The ease of use of our products was in stark contrast to the incumbents. Oracle and RSA were all about meeting the needs of the most demanding experts in the most demanding companies in the most demanding industries. Easy just wasn’t in their vocabulary. The concept likely confused them.

For us, making a product that was limited but easy to use, was key to getting new users. Our customers weren’t sophisticated Enterprise DBAs and security experts. They were network engineers tasked with implementing security, or developers looking for a web database. They weren’t experts by any means. Often they didn’t how to begin evaluating potential solutions. So if we could help them get results quickly and give them confidence, there’d be no reason for them to evaluate more complex solutions. That turned out to be a great strategy.

In the case of Duo Security, we were able to show that users not only liked our product, they loved it. That was completely unheard of in the world of cyber security. Duo provided an easy, fun mobile experience that was vastly simpler than what people experienced with other security products. We routinely achieved an NPS (Net Promoter Score) in the 70s, higher than well-regarded consumer companies like Apple. This became a powerful part of our marketing as the best loved security company.

Incumbents Are Predictable And Rational

If you find yourself operating as a disruptor in the market, keep in mind that the incumbents will act rationally to serve their best, largest customers. If you can build your business by catering to customers in segments they don’t care about, you’ll avoid direct competition, at least for a while. And remember, making something better does not necessarily make it disruptive. It’s only disruptive if it opens up a new market that uses a different buying criteria. Your goal is to build a product that is “good enough” to get the underserved to buy from you.

You’ll likely find yourself in meetings with larger companies who will tell you they can’t buy from you until you have certain key features. And once you’ve implemented those, they’ll have another even longer set of additional required features. Don’t worry about that. It’s better to focus more on the the kinds of customers who actually do buy, rather than prospects who tell you why they cannot. Look for new use cases in neglected markets. Target customers who understand the disruptive model and are unlikely to buy from the incumbents.

Stay True To What Makes You Disruptive

Most importantly, avoid the pitfalls of the disruptive model. Don’t try to compete with the incumbents on their turf. That’s a loosing game. Duo Security never had all the features that RSA offered. We never tried to build on an-premise version. We stayed true to our cloud strategy and sought customers who were open to that approach. After all, we’d seen customers embrace the cloud for their applications and customer data. It was only a matter of time before they adopted it for security.

In fact, that became an important buying pattern for us. If a customer hadn’t already adopted several cloud applications, we knew they would stall out in the purchase cycle. It’s difficult to change customer behavior. Instead, focus on prospects who are already moving in the right direction.

As I mentioned in the prior post about disruption, at MySQL we had a great respect for Oracle, not only their technology, but also their people. But we still sometimes poked fun at them. The photo at the top of this post is MySQL co-founder David Axmark piloting his boat in front of Larry Ellison’s yacht in the Stockholm harbor.

We worked closely with Ken Jacobs, known to many as “Dr DBA.” Ken was Oracle’s second-longest running employee after Larry Ellison. Officially, Ken was our ambassador / handler inside of Oracle. But he was much more than that and became a friend to all of us.

The photo above is from the MySQL conference in 2006 where we named Oracle “partner of the year” following their acquisition of the InnoDB storage engine upon which we relied. Ken, recognizing the humor, was unfailingly gracious. Following Oracle’s acquisition of Sun, Ken retired from Oracle in 2010 after 30 years of service. It is with great sadness I learned that Ken Jacobs passed away in 2021.