Clearing the Clouds: Debunking Misconceptions about Adopting a PLG, Key learnings from Cloudflare
Appeal to the hobbyists
Welcome to issue #9 of Indiscrete Musings
I write about the world of Cloud Computing and Venture Capital and will most likely fall off the path from time to time. You can expect a bi-weekly to monthly update on specific sectors with Cloud Computing or uncuffed thoughts on the somewhat opaque world that is Venture Capital. I’ll be mostly wrong and sometimes right. Views my own.
Please feel free to subscribe, forward, and share. For more random musings, follow @MrRazzi17
I've been investing for the better half of three and a half years and have constantly seen companies adopt a Product-Led or Self-Serve motion—the ability to sign up for a product with only a credit card and often an email address— especially regarding infrastructure and security. While this motion can be helpful and sometimes work, it may be wrong for you and/or appeal to the buyers in the select industry you're segmenting. I suspect PLG and its rapid success over the last couple of years have been due to the success of enduring infrastructure companies such as Datadog and Cloudflare, who, by all accounts, pioneered the notion of self-serve for an industry in which the only way to buy software was to speak to someone on the other end.. and in some instances, if you weren't a large enough company, you weren't even worth the time.
While I know the debate of "Bottoms-Up" vs. "Top-Down" can be somewhat contentious, I'm focusing this blog post on what I learned worked well at Cloudflare, and often, with anything, context matters. Some of these lessons should be relevant today, while others may not.
Democratize Access
First and foremost, Cloudflare revolutionized the DNS and CDN (and, over time, security) industry by providing enterprise-like products for the masses and, quite literally, the Internet (cue Disruption Theory, more on that later). At the time, the only current solutions that would allow you to speed up your page loads, cache your content more effectively, and load-balance your traffic were primarily serving large enterprises. While helpful for enterprises, it left a vast swath of web properties searching for solutions they could afford, whether personal blogs or mid-medium-sized companies. Cloudflare democratized enterprise products and had a large enough surface area (e.g., anything on the Internet) to allow it to build a viable business. It's still remarkable to watch the original launch video of Cloudflare (then CloudFlare) at TechCrunch Disrupt (linked below) that talks about the mission of democratizing performance and security products:
At the same time, Cloudflare simplified complex enterprise products into simple and usable products. It didn't require companies to install hardware and only took five minutes to get up and running (via DNS). At its core, Cloudflare's original mission was to ensure that if you had any web property, it should be served appropriately (secure and performant) at no cost. Cloudflare revolutionized the CDN/DNS industry and became an essential utility for anyone and any company. To quote Cloudflare co-founder and CEO Matthew Prince, "There is only really one price point for a service like ours, and that's free." It's worth calling out the importance of ensuring your backend infrastructure supports the economics of free usage. I may be biased, but often bare metal gives you more leverage, and with more leverage in infrastructure, the better the margins.
Appeal to the Tinkers
One of the best-kept secrets about the success of Cloudflare was its ability to appeal to hobbyists. Given the nature of a free product and effectively enterprise-grade products, the surface area of web hobbyists came to Cloudflare en masse. In addition to signing up mid-market companies and enterprises, Cloudflare could be used by anyone with a personal website, and it turned out that these hobbyists or tinkers had a "day job." What I saw happen over time was that these tinkers or hobbyists would use Cloudflare for their projects or websites; inevitably, they would often bring in Cloudflare to use at their day jobs, whether for performance or security. And in some sense, there was no reason for a POC (proof of concept), considering that these buyers had already been users.
Live for the Edge Cases
The beauty of having a product that lends itself to being used by anyone, anywhere, is that you’ll often have edge cases in which people use the product in ways you couldn’t imagine or in ways you hadn’t marketed initially.
In the case of Cloudflare, we’d see anomalies on the network all the time, and often, we’d study the edge cases with great precision, which would lead to either an infrastructure advancement, product unlock, or, in some instances, discovering security threats before they became well-known. These nefarious attacks were hidden in plain sight. An example would be spike traffic hitting our Kuala Lumpur PoP (Point-of-Presence) at abnormal rates in the middle of the night (Terabyte-level throughput). After studying such anomalies, we’d run any inference to see if this was happening across any other PoPs and if the behavior was precisely an anomaly or a trend. Not only would this stress test our infrastructure with low stakes (e.g., self-serve paying customers with different SLAs), but we’d intelligently learn about the traffic patterns, enhance the network, enhance our performance and security products, ship something to the enterprise that was already battle-tested, and lastly, use the battle-test network to dogfood our products.
Akin to the birth of AWS, what better way to build infrastructure than building it for yourself first at a mass scale? In the infrastructure world, we were always a step ahead of scalability for our customers. I believe this is one of the unfair advantages of Cloudflare’s ability to ship products at unjust velocity. Embrace the edge cases and study them relentlessly.
Ship, Ship, Ship
Looking under the proverbial hood, you’ll often see that Cloudflare organizationally was modeled after Clay Christensen's Disruption Theory, which is covered in his book, The Innovators Dilemma. As a refresher for those who aren’t, like myself, Disruption Theory zealots, Christensen teaches that there are three types of innovation:
Sustaining innovation, in which a company creates better products to sell for higher profits to its best customers
Low-end disruption, in which a company enters at the bottom of an existing market and offers a lower-priced product with acceptable performance, ultimately capturing its competitors' customers
New-market disruption, in which a company creates and claims a new segment in an existing market by catering to an underserved customer base, slowly improving in quality until the incumbent businesses’ products are obsolete
Low-end and new-market disruption are disruptive innovations differentiated by their relationships with the existing market. New-market disruption occurs when an innovative product creates a new market segment. In contrast, low-end disruption enters the bottom of the current market to provide an overserved audience with a “good enough” product. Cloudflare mastered (2) Low-End Disruption. Cloudflare entered the market as a low-end market provider, and thus, it stuck to its roots as the business scaled from a few lines of code to ~$22B Market Cap as of this writing. “Almost always, when low-end disruptions emerge, it creates a situation where the leaders in the industry are motivated to flee rather than fight you,” Christensen says on Disruption Theory. “That’s why low-end disruption is such an important tool to create new growth businesses: The competitors don’t want to compete against you; they just walk away.” In the textbook case of Cloudflare, the product offered and continued to provide the following three characteristics:
It offers “good enough” quality by market standards, but not the best. Customers at the top of the market likely won’t be interested in this product, making it seem non-threatening to incumbent businesses.
It targets consumers at the bottom of the market. These are people overserved by the current product offerings—that is, they don’t need all the bells and whistles that come with an expensive price tag.
It profits at lower prices per unit sold than the incumbent businesses. This is essential because if the profit margins are lower than the incumbents’ products, they won’t be motivated to fight the entrant for market share. The incumbent businesses’ pursuit of profit is the causal mechanism that enables entrants to continue to move upmarket. (In the case of Cloudflare, owning their bare metal.)
Also covered in Christensen’s book and modeled by Cloudflare was its organizational structure to support low-end product velocity while gradually moving up the market, setting up your company from the outset to keep shipping to the low end of the market, especially as you scale where all of your Resources, Processes, and Values (RPV) are diverted to support sustained innovation. Early on, Cloudflare set up two distinct product teams:
Product Strategy, now the Emerging Technology and Incubation Team
Product
The Product Strategy team was set up to work on moonshots, whether 1.1.1.1 or things adjacent to the core Cloudflare products. The core mandate was to continuously ship products aimed at the low end of the market. Product and Product Strategy were separated into different geographies, and the team could *almost* work autonomously. In effect, it was and is a company within a company. If there were an ounce of commercial success with some of the projects, it would graduate into the Core Product team at Cloudflare, where it would get RPV to scale the product line. This structure has allowed and continues to allow, Cloudflare to ship relentlessly to the low end of the market.
Avoid Commoditization
Now, there is such a thing as having too good of a self-service plan where AEs don’t lose deals to competitors but lose deals to lower-priced plans! I won’t attempt to dispel the fact that there is a one-size-fits-all fix to figuring out pricing levers. At Cloudflare, what worked tremendously well with upsells was baking in (at higher tiered prices) enterprise-needed and/or expected features such as:
SSO Support
Uptime Service Credits
Support
Audit logs
Enterprise Logs
Naturally, you’ll have a product that organically appeals to the high-end market as you start to wallet-share from incumbents and larger enterprise contracts. But for the mid-market, baking features that become checklist complaint needs for companies as they mature only make it easier to move up the market. But beware, this can also be a delicate balance where sometimes a $200/mo plan looks better than a $2000/mo plan.
Investing
As an Investor, evaluating PLG-led GTM at the earliest stages is like licking your finger and catching the wind. It’s messy, it’s unclear, and it’s non-linear, but what I look for in companies adopting a “bottoms-up” approach is simple:
Are you appealing to the low end of the market (as defined by the target industry)?
Is the product good enough for [x, y, z reason]?
What are the edge cases?
Can this co-exist with an (inferior) incumbent in a given company’s stack?
It’s also highly likely that none of these answers exist, which can be acceptable considering the stage of the company. Personally, biases aside, I look for companies that embrace bottoms-up / PLG motions as a product innovation and RD center, in addition to having top-of-funnel within their DNA. Given the trends of the past several years and bottoms-up being well-known within buyer communities, I couldn’t be more excited about the era of infrastructure companies building with PLG at their core.
Thanks for reading! If you think I’m dead wrong and/or missing crucial components to my thinking, please don’t hesitate to reach out so I can further stretch and refine my reflection in the space! Pricing is an ongoing lever constantly changing, and there’s no telling what the next evolution of pricing will look like in the decades to come. Feel free to drop me a note at zain [at] ridge.vc or a line on Twitter @MrRazzi17 if you found the piece helpful or want to riff on anything infrastructure, security, VC, and pricing.