How Small Beats Large

How does a smaller company beat a large company with seemingly unlimited resources?

This is a problem I have been struggling with, and here are some thoughts (basically a synthesis of Porter and Christensen).

The problem has to be looked at from both sides, let's call them SmallCo and BigCo. The SmallCo's strengths alone are not going to be enough, nor the BigCo's weaknesses. It's only when the former's strengths match the latter's weaknesses that you have a David beats Goliath situation.

So let's look at it from both sides, starting with BigCo.

Just because a company has the resources to fight and win on any given single front, does not mean it can do so on all fronts, simultaneously. At some point every empire overextends itself. Where's the weak link?

A large company can have weak points where it lacks a) willingness/motivation, or b) ability to compete.

• Lacking willingness/motivation to compete. Perhaps because
• a) under the radar situation. The market in question is unattractive at the surface, or too small to move the needle for BigCo. 
• b) requires trade-offs. Examples would be if the market takes away resource from BigCo's favored customers, doesn’t match corporate value, or leads to cannibalization of opportunities. In his book "Seeing What's Next", Clay Christensen cited example of a firm that counts on post sale service agreement not being interested in an off-the-shelf /self-service product.
• Lacking ability.
• Perhaps because BigCo's activities and processes are not tailored to the value proposition offered by SmallCo.
• BigCo may have difficulty replicating SmallCo's value chain.

Moving on SmallCo's side. How does SmallCo take advantage of BigCo's weaknesses while avoiding its strengths?  

• Distinct customer segment and value proposition that does not match BigCo's. 
• SmallCo would target over-served customers, under-served customers, non-customers (creating new market)
• Tailored value chain supporting that value proposition. The value chain should show 1) uniqueness, 2) internal fit, 3) independence from BigCo.
• Uniqueness. It has to be different from BigCo's. Otherwise you will just be overwhelmed by brute force.
• Internal Fit (interdependency). The value chain should fit together in a way that’s hard to replicate. Ideally the parts are interdependent on each other. This way your competitive moat compounds and is hard to replicate.
• Independence. Separate value chain. If parts of the value chain overlap, then SmallCo could be forced to play by BigCo's rules.

Basically if your David, make sure you can afford to NOT play by Goliath's rules.

A Short Example with Elastic N.V and Chewy

These are two companies that compete with Amazon in two completely different industries. The differences provide them different strengths and weaknesses relative to Amazon.

Elastic ("ESTC"), which I have written about here, provides search functionalities that Amazon effectively copied. Chewy ("CHWY", as discussed here) is an online pet food/supplies provider. 

Which has a better chance against Amazon?

Amazon's Motivations

I would say Amazon is much more motivated to go after Elastic's search market, which competes with Amazon's AWS segment. This segment of Amazon not only provides more profitability than its e-commerce segment, but it is also growing much faster. A quick look at Amazon's earning releases shows tremendous focus on developing AWS's capabilities. Overall, Elastic's search/indexing market looks strategic to Amazon.

On the other hand, pet e-commerce is seen as a fairly steady, slower growth market. Pets are hardly ever mentioned in Amazon's earning calls. 

Verdict: Amazon is much more motivated to attack Elastic than Chewy.

SmallCo's Value Chain

Chewy has its own distribution facilities, call center, and service reps. These fit together in a way that reinforces Chewy's niche strategy (as discussed here). In terms of pet products, its suppliers does overlap with that of Amazon's, and that could be a problem.

Elastic though, actually deploys its hosted service on AWS! Talk about NOT having an independent value chain! Elastic belated realized Amazon meant harm and started diversifying to Microsoft Azure in addition to Google (GCP), but the damage has been done.

Verdict: Chewy's has a more distinct value chain from Amazon.

We can go further, but this is enough to show that Chewy will have much stronger defense against Amazon's invasion.

Elastic (ESTC): SaaS Transition Kills Open Source Debate, but Too Early

Elastic N.V. (“ESTC”) provides elasticsearch, an extremely popular open source search engine that’s used for search, infrastructure monitoring (including logging), and security. An excellent background is provided here, written by “CMF_Muji”. He did a great job covering the basics of the company, product, and use cases. I will not repeat that effort here.

For the purpose of this article, I will refer to Elastic the company as “ESTC”, as distinct from elasticsearch the product.

Elasticsearch the product is well established. No one questions the product is great, or that it’s a de facto standard (at least in areas like logging); or that it has a long growth runway ahead of it. So let’s get to the point.

Amazon’s Attacks on ESTC

The biggest problem for ESTC investors are threats to its open source business model, as exemplified by Amazon’s recent moves. In this post I will explain the nature of Amazon’s attacks, and why I think this highlights ESTC’s vulnerability to other and future threats.

Amazon's attack has two fronts: 1) Amazon's hosted service (“Amazon Elasticsearch Service”) competes with Elastic's hosted service (“Elasticsearch Service”). This actually has not been a huge problem. Despite the obvious potential for naming confusion, ESTC’s own service is growing nicely. 2) Amazon’s “Open Distro for Elasticsearch”. This stems from Amazon’s complaint that ESTC mixes open source and proprietary code in its default distribution.

Of the two, Amazon’s Open Distro is by far the bigger problem. This article gets to the crux of Amazon’s criticisms.

The issue is a bit of “he said, she said”. Note that ESTC actually let you download an all open source version with no proprietary features. So arguably Amazon fails its attempt to claim moral high ground. Granted, ESTC's OSS version is compiled version and not the source code, and that a developer who want to work with the open source code from Github will have a hard time avoiding the proprietary code. Still, if you’re a developer who just wants to use the ELK stack, you’re not going to fiddle around with the source code in Github, you’ll just download the binary anyways. So I’m not sure this whole debate matters for the average user.

ESTC also says it’s all very clear what’s what, according to the article.

“All of the code for our proprietary features are kept in a separate top-level folder called “x-pack,” to avoid any mixing or confusion. We also include a header on every source file, indicating whether it is licensed under Apache 2.0 or the Elastic License, to prevent any ambiguity”

Non-existent Barrier to Entry

If this debate is purely about open source versus proprietary, then there’s an easy way for ESTC to put it all to rest. They can simply provide a version that only has free open source – the source code, not the binary.

But that’s not the only issue. Amazons Open Distro actually has more functionalities than ESTC’s "all open source" version. It is closer to ESTC’s premium distributions, but all for free.

With the first release, our goal is to address many critical features missing from open source Elasticsearch, such as security, event monitoring and alerting, and SQL support,” Cockcroft wrote.

Will these extra features be enough to sway developers toward Amazon’s version? Who knows? Does it matter?

The point is, this could just be the start. Anytime ESTC comes up with some premium proprietary feature, AMZN can fork it and come up with a free and open source version. Perhaps they’ll even add features that are better than those in ESTC’s premium paid version. It would then be up to ESTC to match those features in price (as in zero, free), and release them under open source Apache 2.0 license. Will they have to do that? I don’t know. The potential for an ugly spiral to the bottom is certainly there.

The underlying problem is ESTC’s “Open Core” model. There is next to no barrier to entry. Source codes for the core functionalities of elasticsearch are on Github for all to see and use. Forget Amazon, an enterprising startup can take those codes, add their own features (open or proprietary) and created their own version. “open source” is more like open season for wannabe competitors.

Adding to that pressure, selling software is not Amazon’s core business, nor Netflix’s, nor Expedia’s. Elastic charges for their service by “nodes” and it gets expensive real quick. Big corporate customers won’t hesitate to hurt ESTC’s business if that gives them an edge in negotiating and pushing down those licensing costs. For ESTC this could be an ugly race to the bottom – everything for free.

Transition to SaaS Makes this Debate Moot

Now let’s go back to CMF_Muji’s article. One of his best insights is that ESTC’s acquisitions all have something in common, which is these are applications built on top of elasticsearch itsef. ESTC can then easily integrate them into its own platform and offer SaaS products.

Note I’m not talking about the so called “SaaS” that shows up as revenue in ESTC’s income statement. ESTC counts Elasticsearch Service as “SaaS”. But that’s really just hosted service, still very much a “build it yourself” approach. It’s more akin to IT infrastructure/platform (see notes for various product lines). What I mean by “SaaS” here is end users getting the application functionalities without having to interact with the underlying infrastructure stack. Think of SaaS like SalesForce, like Workday.

That’s not ESTC, at least not yet. For now they are primarily a vendor of on-premise, self-managed software, with offers to host that on the cloud (but still have customers build their own apps on top). And even that hosting, “Elasticsearch Service”, is still under 20% of revenue.

ESTC is moving in the SaaS direction though. With a series of acquisitions, ESTC is well positioned to shift away from selling infrastructure software/source code and toward being an enterprise application vendor. App Search Service (powered by Swiftype which they acquired), Site Search Service, and the new Enterprise Search Service – these are all closer to what I would consider SaaS products. ESTC also just acquired Endpoint, and will use it to security application space.

CMF_muji correctly points out that this “true” SaaS approach is an upside option for ESTC. I think it’s more than that. It’s a way out of this whole “existential threat to business model” quandary.

This is a step function change in business model – selling application instead of selling enabling infrastructure. Your value proposition is different. The customer’s mindset is different. The SaaS user will focus on fulfilling the business case and ignore the infrastructure. They will not play around with Github and source codes.

At that point the whole debate of open source versus propriety becomes moot.

That is a promising thought, but one that is a long way off. The value proposition, customer set, as well as ESTC’s sales and marketing approach all have to change. This is by no means an easy move.

What I'm doing with the Stock

ESTC is a company with optionality, but also one whose core business model is threatened and will likely have to undergo a big transition (no easy feat). It is also trading at some 13x revenue. 

For that, ESTC goes into the too hard pile.

When would I revisit? I would when actual SaaS revenue (ex Elasticsearch Service) shows a clear pathway toward being half of total revenue. I will also rethink this if stock shows technical support in low $60’s.


Notes: The product set

ESTC’s offerings consist of 1) on premise and self-managed, under which there are free and premium versions, and 2) cloud offerings, which include ESTC managing the infrastructure for you, as well as what I consider “true SaaS” application offerings.

• On premise/self-managed products
• https://www.elastic.co/subscriptions
• Free versions. The default distribution ("Basic") includes open source as well as proprietary features (but still free).
• Paid versions. The Gold and Platinum versions include support as well as advanced features.

• Elastic Cloud. https://www.elastic.co/cloud/
• Elasticsearch Service - this is their hosted service (can choose AWS, GCP)
• Elastic App Search Service
• Elastic Site Search Service
• These are cloud software, but not all are SaaS. ESTC counts all 3 to be SaaS, but I would only count the latter two (App Search and Site Search) as real “SaaS” in the sense of how market uses the word. Elasticsearch Service (for now the bulk of revenue in this segment) is still "build it yourself" software.

• Elastic Cloud Enterprise
• https://www.elastic.co/products/ece
• This is confusing naming because this is very much an on-premise solution. Sure, it can be deployed on public or private clouds, but if someone wanted to deploy on public cloud, they would have just used ESTC or Amazon’s hosted service instead of installing this.
• here's the description: Elastic Cloud Enterprise, or ECE, is the same product that powers the Elastic Cloud hosted offering, available for installation on the hardware and in the environment you choose. ECE can be deployed anywhere - on public or private clouds, virtual machines, or even on bare metal hardware