Selling Cloud vs Selling SaaS
A seller’s take on product-led growth in the enterprise
There’s been a lot of chatter in enterprise tech about product-led growth (PLG). For founders and VCs, there’s a new PLG playbook that influences how startups approach product design, what metrics to look for when demonstrating early stage traction, and who to hire as your first head of sales/growth.
For sellers, we’re starting to a see a divide between top-down, sales-led growth (SLG) representing the old guard, and newer co’s adopting bottoms-up, PLG selling motions. Of the top 20 private cloud companies on the 2021 Forbes Cloud 100, 70% have go-to-market functions that are either Dev-first or PLG, only 10% are pure Top Down (source).
Having seen best-in-class enterprise SLG (MuleSoft), and best-in-class PLG at enterprise scale (AWS), the sales motion does feel different. In this post, I highlight three shifts I’ve noticed as a seller, drawing from my first year on AWS’s Enterprise Greenfield team, where I work with orgs with relatively little to no AWS footprint, and contrasting it with my prior role selling subscription software-as-a-service (SaaS) at MuleSoft.
Selling 1 product that customers purchase versus 200+ cloud services that are consumed
It’s interesting — selling, whether it’s one or many products, starts the same way. You get your account list, and you need to figure out how to prioritize your time prospecting into the territory. Depending on what you’re selling, there’s usually a good method for ranking accounts by propensity to buy, using an Ideal Customer Profile (ICP). Then, it’s cold calling, emailing, trying to get ahold of people gauging whether there’s the right kind of pain, or right kind of project, where you think you can help.
As you’re looking for pain and projects, that’s where things start to diverge. Selling one product, I’d be looking for a very specific type of pain — technical pain that our product can address in a differentiated way, that manifested in business or process pain that we could use to measure the weight of the problem and corresponding value if solved. Looking for a project was important because it’s a signal that the company had prioritized getting something done, involving a coordinated effort among many people, with an executive sponsor responsible for the project’s success, on an allotted budget and timeline. The selling came in connecting the customer’s pain, project, and your product. Something like, [“hey customer”], you’re introducing risk in delivering your project on time and within budget if you try to plow ahead with your current IT tooling/processes, because these pain points will fester into meaningful roadblocks; with our product, you can remove those roadblocks and deliver the project X% faster at Y% less costs, if you invest $Z amount in our software.
I would need to discover big pain, and a big project, to even have a shot at getting a deal. Then, I’d have to run a tightly-controlled sales process where things could go off the rails at any time — customer walks away, competition intercepts you, POC goes haywire — and the deal would evaporate. Outcomes were binary, and high stakes: I either made it through the gauntlet and got a deal, or I got nothing.
Selling AWS, every account is qualified, and given the breadth of use cases we can address and the fact that no upfront or minimum spend is required, almost every opportunity is qualified to pursue. You don’t need to exclusively attach yourself to “big pain, big project” transformational initiatives. Those are obviously still good, and in the AWS world those are data center exits or what we call mass migration opportunities. Yet there’s a whole range of opportunities you can pursue “down market” within an account that you’d typically walk away from in a one-product, one-shot world. The “small pain, no project,” “medium pain, medium project” combinations on the pain:project spectrum.
This creates a much more dynamic sales process. There’s less deliberate, methodical “elephant hunting” (“need big pain, big project”), and more running-and-gunning, trying to do whatever’s in your power to get something going in an account (“any pain or project will do!”).
Depending on what you uncover in discovery, you need to know enough about AWS (a) services, (b) programs, and (c) people to make the right judgement call on what next steps to prescribe to the customer.
For path (a), the way you combine a subset of AWS services into a solution architecture puts an emphasis on the “building” (we give you a toolkit), compared to tying back to a packaged SaaS product with predefined features. This shifts the emphasis away from learning about a product’s capabilities (product demos, POCs in a walled-off sandbox environment), to learning about how to navigate the AWS console and getting real-world, hands-on experience with AWS services (training, Immersion Days, credits for you to run POCs in your own AWS account).
For path (b), AWS offers specific programs — e.g. Data Lab, Migration Acceleration Program, Digital Innovation, Experience Based Acceleration, or one of our Private Equity programs for PE-backed portfolio companies — that have predefined steps you take the customer through, usually with funding attached and assigned Subject Matter Experts. These are not tied to a specific AWS service or subset of services, but tied to an outcome. Think of it as applied expertise, or a mini consulting engagement.
For path (c), AWS has many people on our bench for pure advisory work: Enterprise Strategists, Enterprise Technologists, technical specialists, industry specialists, and “pan-Amazon” expertise — reaching across the aisle to our friends across business units within Amazon (e.g. Amazon Advertising, or “learn how Amazon runs its global customer service operations”).
Ideally, taking a customer down one of these paths will lead them to take action, to do something. The ultimate output is them creating an AWS account and starting to consume AWS services, generating usage revenue. But it’s not always a direct path. Sometimes, things will peter out — equivalent to a deal dying — but instead of that being a dead end, it just means you need to revert back to prospecting, discovery, and finding another angle in. You can keep cycling back between steps 0–3 even within the same account, creating a flywheel of activity that should, eventually, lead to usage revenue. I call this the Earn Trust flywheel.
Sales as a gatekeeper versus sales as a value-added service
I’ll cut to the chase: customers don’t need to talk to a sales rep to start using AWS. It takes ~3 minutes to create an account (instructions here), and from there you have access to an extensive Free Tier and the ability to consume 200+ cloud services, on-demand. Spin something up, spin it down, pay-only-for-what-you-use. This was one of the early promises of cloud computing, and it continues to be quite liberating compared to “Click here to talk to Sales” or needing to go through a long vendor-led procurement cycle to see and/or get access to the software.
This is obviously true for a developer signing up with a credit card to do something very simple and low cost (like, why should they talk to sales to spin up an EC2 instance, and conversely would you want to be the middleman on a $1 micro-transaction like that, as a seller?). What’s been interesting in my role at AWS is seeing accounts who still abstain from talking to sales even when they’re running large-scale enterprise migrations to AWS. This is rare, of course, but anecdotally in my territory I’ve seen a $5b revenue retailer release an RFP to migrate all their business applications, including SAP, to AWS — enclosed with architecture diagrams, cost estimates, and a spreadsheet with names of 15+ project leads representing different parts of IT — and there’s been no contact with AWS sales. As their AWS sales rep, it’s perplexing — and humbling — to see this.
It begs the question, what is your value to the customer? Part of your value is cutting through the noise and guiding your customer through a prescriptive process (aligning the right AWS services, programs, and people, referenced prior). Part of your value is holding the purse strings for AWS investment credits or funding; the goal here is to waive or mitigate any financial risk associated with trying out AWS. Most of my job is project management, aligning a wide variety of internal and external stakeholders to a regular cadence of activities progressing us towards some stated goal; or organizational change management, getting executive buy-in to pursue a new thing (cloud) and change the culture around how IT provisions infrastructure or ships software. It’s more consulting, less sales.
If that’s one side of the existential question, the other side is, what is your value to a PLG company? In some ways, companies like AWS don’t need sales people. How can you prove your worth and make an outsized impact?
I’ve found that I need to be just as comfortable prospecting into the “hands on keyboards” type developers or IT admins, as I do prospecting into the C-level. It’s fighting the ground war, while also working the diplomatic channels.
Fighting the ground war mimics the bottoms-up, developer-led adoption that’s always been a key part of AWS’s growth. To effectively fight on this front, you need to be data driven. Monitor usage trends and behaviors, then proactively offer ideas based on what you’re seeing that can increase the rate or magnitude of organic adoption. I have a Tableau dashboard, for example, showing usage insights in my territory, one of which is “Weekly Usage Anomalies” with account-level and service-level usage trends, positive and negative, that could be signals for me (sales) needing to get involved. If there’s no baseline usage, you want to tease out the developers or IT Admins who may be open to at least learning more about the cloud, offering education and enablement. Tease out the edge use cases where you can create value without entangling yourself in the politics of a company’s core infrastructure strategy, like by targeting finance, marketing, business intelligence, or app dev teams.
Working the diplomatic channels in parallel is important because you need executive buy-in for any large scale change. If an account has been closed off to cloud for this long (remember, it’s 2021; cloud is not a bleeding edge, unproven technology), that means there’s strong command-and-control within IT, from the CIO down. You won’t even get a random developer account sign-up because they’re all scared into compliance. An executive needs to give the green light. This requires fighting entrenched relationships the CIO may have with hardware and on-premises software vendors. It requires evangelizing to other CXOs so that they see how the cloud benefits them, which applies indirect pressure on IT to open up.
It’s a war for mindshare in these accounts. You want everyone from the lowest-level developer to the CIO calling you when net-new use cases, projects, or initiatives come up. When they’re hitting roadblocks. When they’re getting audited by Microsoft or Oracle. When they’re doing anything related to tech, even if it’s a peripheral SaaS evaluation where AWS has no dog in the fight (“Hey Karl, we’re evaluating Digital Asset Management tools, any products you recommend?” — real example from a CTO in one of my accounts). This requires sustained effort to get your name out there. A lot of activity cranking on the Earn Trust flywheel.
“Doing deals” versus growing usage-based revenue
Doing deals is like stepping up to that carnival strongman game where you swing the hammer and try to get the swing just right where the thing goes up and hits the bell. You may take a swing at a bunch of potential deals, but only a few swings will hit right where you’ll hit that jackpot. At MuleSoft, a good rep would do on average 2 deals a quarter, and you could toggle between increasing your deal size (higher ASP) or increasing your top of funnel pipeline (more “at-bats”) in order to keep a consistent deal-closing rhythm against your quota. (If you toggled up the deal size high enough, some Strategic reps could hit their number on just 1–2 deals a year.) The deals were a lot of work and relative to how many opportunities that progressed from first-call to closed-won, few and far between — but when they hit, they hit big. Each deal, on average, could take a good 15–20% off your annual quota.
Growing usage-based revenue is like shoveling gravel. It’s a lot of hard work, and you’ll look up and it’s hard to see the gravel piling up that high after each shovel. Over time, though, when you step back the accumulation can be quite meaningful. Each “shovel” or activity you do with a customer may increase the usage ever so slightly, but the more you keep shoveling the better you get at finding leverage points in your work, i.e. calibrating around types of sales activities that lead to higher-on-average returns in consumption.
From a finance or public markets perspective, what’s interesting is that you can book a big SaaS deal, but that can mask actual product usage. Product usage may be non-existent if the software’s not implemented properly; it may be delayed; it may be anemic relative to how much licensing the customer thought they needed at the time of negotiating the deal. If you look at software history, creating an artificial delta between forecasted demand and actual usage sounds awfully familiar to customer pain points with on-premises software licensing purchases.
SaaS did disrupt this, for a time. Remember Salesforce’s pay per user per month, disrupting Siebel Systems? The Salesforce of 2001 is different from the Salesforce of 2021. Salesforce contracts today are financially engineered, combining multiple products, swapping products in/out, doing acrobatics with the deal terms to avoid any decrease in ARR and pull-ahead projected growth in licensing usage in exchange for locking in better rates now. Salesforce, impressively, will hit $26b in annual revenue this year. If you pulled back the curtain, I wonder what percentage of the provisioned licensing that customers have subscribed to is actually utilized (20%, 50%, 80%?).
Pound for pound, AWS’s forecasted $59b in 2021 revenue is impressive not just because of its sheer size, but because every dollar of revenue is correlated to a dollar in actual cloud services consumed. (Yes, AWS does large deals, where customers can commit to a certain level of future spend ahead of usage, but these deal constructs, like an EDP, typically make customers commit to a minimum “floor” of spend usage, not a “ceiling” that they need to really stretch to hit.)
That’s the macro theme underlying any discussion of sales driving usage revenue, versus doing a deal. In a consumption driven world, the customer must first use the stuff in order to generate revenue. Then, if they see value, they’ll use more, generating more revenue. There’s a tight feedback loop between consumption, value, and revenue. This reverses the traditional sales:customer power dynamic. It’s no more sales giving a customer projections of usage, or projections of value, informing a “big bang” upfront SaaS purchase. The order of operations for cloud is: use it, get value, pay us; not pay us, hopefully use it, hopefully get value. Incentives are much more aligned.
That’s what’s most interesting about this new generation of cloud native technology companies and PLG, since it naturally forces a tangible value discussion, which is where the best enterprise sellers will continue to set themselves apart.
