It starts with someone posting an AWS press release in the company chat. “AWS Announces FooBar,” the headline reads.

The announcement skirts around technical details, as usual, but contains a worrying amount of buzzwords that overlap with the company’s product. Somebody responds with a grimace emoji 😬. Others reply with all the ways AWS FooBar is totally not like our product and, anyway, ours is better, and, and… The flurry of replies betrays their true collective emotion: We’re screwed.

They’re right to be worried.

Cartoon about the unpleasant future.

As a marketing consultant to enterprise software startups for the past six years, I’ve helped companies navigate and succeed in this scenario at least eight times.[1] In this article I explain why every software startup should be prepared for this scenario, why the initial panic is justified, and how to position products against alternatives from “Big Cloud” (AWS, Azure, GCP).

Every Software Startup Should Be Prepared to Compete Against AWS, Azure, and GCP

Even if you’re not competing with Big Cloud today, there’s a good chance you will soon.

This is especially true if your product is in the serverless, stream processing, machine learning, containerization, IoT, data warehousing, or batch processing space. Those are the fastest growing cloud services—according to a survey from Rightscale—and Big Cloud companies know it.

Big Cloud companies earn the bulk of their revenues from metered billing of storage, compute, and streaming. Having turned those infrastructure workloads into commodities, the Big Cloud companies are in a race to provide differentiated products higher in the stack just to bring more customers onto their infrastructure.

That is evident in the sheer size of their product portfolios and pace of product releases: AWS has 182 products and made 83 major product announcements (launches or major releases) in 2018.[2]

Table showing the number of products and major product announcements from AWS, Azure, and GCP.

You Should Worry When Big Cloud Launches a Similar Product

There is a tendency, upon learning of a Big Cloud intrusion, to bury our heads. Internal emails will include explanations for why the Big Cloud product “is not really competitive,” “is not as good as ours,” and “can only take a small piece of the market.”

Maybe those things turn true, but there are good reasons to at least take the competition seriously:

1. Resource Imbalance

Big Cloud companies can win by brute force: Pouring obscene amounts of resources into engineering, marketing, and sales until they outrun or outlast the competition. It won’t be enough to have a better product by a smidgen, or to have a small head start in the market.

2. Complicated Relationship

Startups participating in Big Cloud partner programs, such as the AWS Partner Network, will find themselves sharing sensitive information and valuable resources with the competition. For them, leaving the program would mean relinquishing a potentially significant acquisition channel.

Meanwhile, Big Cloud wouldn’t flinch at losing a startup partner, and therefore has no incentive to be prudent with the information it obtains.

3. Broad Reach and Influence

AWS can get on stage and influence a thousand people, or send an email and influence a hundred thousand, or play a TV commercial and influence millions. Using their broad reach and brand recognition, Big Cloud can influence how people perceive the market and make their decisions.

4. Captive Audience

Even better than a reachable audience is a captive audience. Big Cloud companies have millions of users, already running on their platforms and familiar with their products. They can reach this audience to upsell and cross-sell products in a few clicks.

5. Pricing

The objective for most Big Cloud products is not to make profit, but to bring customers onto the platform and increase infrastructure usage (compute, storage, streaming). Therefore the products can be used as loss leaders: Priced at very low or no cost, provided they drive increased infrastructure usage. For startups, at best this eliminates the option to compete on price, at worst it forces them to lower prices with no way to make up for it.

6. Easy Access

Engineers at companies already running on AWS can buy, deploy, and integrate an AWS product before their coffee cools. Metered billing means there are no upfront costs or negotiations. Being on the same platform means seamless integration between tools and services.

7. Early decision

In the past, decision makers had to choose whether to build a solution in-house or purchase software from a vendor. Today, the low prices, easy access, and brainshare of Big Cloud offerings create a new option for decision makers: Use what their cloud platform is offering.

It used to be “buy vs build.” Now it’s “buy vs build vs big cloud.”

For software startups, this means they can be ruled out even earlier in the buying process, before any conversation, evaluation, or feature comparison takes place.

How to Win Against Big Cloud

Prepare

Attend trade shows, seek out insiders who might tip you off about looming competition, and generally keep an ear to the ground. Advance warning will allow you to dredge a wider moat, prepare a response, and avoid company-wide panic when the press release hits.

Having a pre-emptive strategy for competing against Big Cloud will make it possible to ride the initial wave of hype following their announcement, leveraging their campaign to bring attention to your own product, and pulling away from other startups who will be caught by surprise.

By the way, I write an article like this every month or so, covering lessons learned from growing B2B software startups. Get an email update when the next one is published:

With the right strategy and execution, the launch of a competitive product from Big Cloud could be turned into a positive inflection point for the startup and its market.

Even if you are not competing against Big Cloud now, good preparation will improve reaction time and chances of succeeding when the moment comes. If your product even remotely encourages more use of cloud compute, storage, or streaming, then you should prepare.

Support Multi-Cloud

According to the same survey by Rightscale, 84% of enterprise organizations have applications and workflows scattered across on-prem, private cloud, and public cloud environments.

If you are “the #1 solution for X on AWS,” and AWS launches a solution for X, you become a distant second choice.

If your product works across a variety of environments, then it will remain a viable—and probably better—option for buyers that want to solve an organization-wide problem. Those buyers will need a solution that works across their entire infrastructure, not just the part on AWS.

Support for multi-cloud and hybrid environments is one of the most common reasons I hear from decision makers for why they bought software instead of using the cloud offering.

Multi-cloud and hybrid-environment support could be a decisive advantage over Big Cloud offerings. And, unlike a small lead in features, this advantage will last a while: Big Cloud companies have little incentive to make products for other platforms.

With options like Kubernetes and Gravity, adding that capability to products may not require a monumental engineering effort.

Think Twice Before Open-Sourcing

While it helps with awareness and credibility, open-sourcing products in whole or in part lowers the barrier to entry for competitors. For any new and sufficiently popular open-source product X, it is trivial for Big Cloud to introduce a “Managed X” offering, as AWS did with Elasticsearch, or to pair it with their security products and package it as “X for Enterprise,” as AWS did with MongoDB and as Google did with Kubernetes.

(The Kubernetes story has a few fun twists in it: First, the company Docker released an open-source containerization product. By the time they launched a paid container management service, Google already developed and open-sourced their own container management solution, Kubernetes, which won the market. Then, after Docker released an enterprise solution for managed containers, Google beat Docker once again with the launch of Google Kubernetes Engine.)

For example, when AWS launched a “Fully managed, scalable, and secure” packaging of the open-source software Elasticsearch, it led the makers of that software to admit:

“… Amazon competes with us for potential customers, and while Amazon cannot provide our proprietary software, the pricing of Amazon’s offerings may limit our ability to adjust the price of our products.”

The questionable benefits of open-core business models, combined with the vulnerability it opens to competition from Big Cloud companies—who are not ashamed of taking advantage—is why I advise companies to guard their product and not go open-source, or to limit their vulnerability if they already open-sourced, as Confluent did by changing their licensing when AWS pulled the same maneuver with Kafka, the open-source software from Confluent.

Position Against the Category, Not the Product

Now that companies decide between “build vs buy vs big cloud” before doing side-by-side comparisons of products, startups must position their product as a better alternative or complement to the entire “big cloud” category of solutions.

Don’t talk about who has the better features. First, given the engineering resources available to Big Cloud companies, any feature advantage will be short-lived. Second, buyers make feature comparisons much later in the buying process, after ruling out the majority of options based on their perception—not features—of those products.

So why is your product better than Big Cloud, despite the (likely) higher cost and time to deploy?

Here are common answers I have found from my interviews with buyers, that may or may not apply to your product:

Works Anywhere with Anything

“Our product deploys, runs, and integrates with applications on any infrastructure. Organizations running applications hybrid or multi-cloud environments can use the product without restrictions and without consolidating to one cloud provider.”

Self-Service for Non-Technical Users

“Products from Big Cloud providers often serve the users closest to infrastructure work, such as engineers, operators, architects, developers. Our product lets non-technical users such as […] do their work without being blocked by or burdening technical teams.”

End-to-End Solution

“Our product is an end-to-end solution that does not require engineering work to glue parts and other systems together. Big Cloud products act more like building blocks that work well with other parts of their platform, but are not that useful or even usable on their own.”

Purpose-Built

“Our product was made—and continues to be developed—to solve the unique needs of your industry. It integrates seamlessly with people, workflows, tools, and systems you already have, such as […].”

Expert Partners

“In addition to documentation and examples relevant to your use cases, we provide expert support and consultation to all customers, regardless of their size.”

Customer-Driven Development

“We are laser-focused on making the best product for […], constantly making improvements based on input and emerging needs of people like you.”

If you’re still unsure how to explain your advantage over Big Cloud products, ask the buyers who chose you over AWS, Azure, or GCP, like I did for Gravitational and for Netlify.

After developing new positioning to compete against Big Cloud, turn it into new or updated messaging, align the company on that messaging, and bring it to market through your sales and marketing channels.

Conclusion

The entry of Big Cloud is not always a death knell, but it’s serious. Startups that acknowledge the threat from Big Cloud companies, prepare accordingly, and react with the right strategy and sense of urgency could not only survive but thrive. Maybe even long enough to be acquired by one.

[1] An incomplete list: I was consulting FoundationDB when AWS launched Aurora; Scalyr when AWS launched its Elasticsearch service (often used for searching through logs); Gravitational when Google launched GKE; Domino Data Lab when AWS launched Sagemaker; Etleap when AWS launched Glue; Nexla when Google acquired Alooma and as AWS launched AWS Lake Formation; Netlify when Google acquired Firebase and when GitHub (owned by Microsoft) launched Actions.

In one case I saw things from the other side: When the startup Particle launched their IoT solutions, I was consulting AT&T on launching their own IoT platform and marketplace… True to form, AWS also launched an IoT platform that year.

[2] Product counts are approximate, and do not include general business product groups such as G Suite or Office 365. Sources: 1, 2, 3, 4, 5, 6, 7, 8.

◼

PS - Liked this article? I write one every month or so, covering lessons learned on B2B startup growth. Don't miss the next one:


If you need help with marketing and revenue growth, get in touch.