Navigating the Leap Into Enterprise
Good morning, everybody. Thanks for taking the time to join this talk. Today, I want to cover enterprise go-to-market, and that's with a lens towards Infra and SaaS companies. And presumably, if you're here, you fall into that bucket. If not, hopefully at least some useful tips and ideas for you, as well.
My name is Adam Gross. I've done a bunch of stuff in my career, primarily in the SaaS and CRM and developer-facing universe. Most recently served as CEO of Heroku, and now spend my time as an investor and advisor to a whole bunch of, typically developer-facing startups, as well as doing a bunch of board work, both in publicly traded companies like Vimeo, as well as nonprofits like Democracy Works.
When and How to Go Enterprise
And so, what are we here to talk about today? Really, one of the great things about my job and role is being able to work across a really broad set of startups and have fascinating conversations every day with founders, as they, frankly, are wrestling with a lot of the same problems. Which is fundamentally about building their companies, building their business.
And one of the most common questions that comes up in those discussions, even in the relatively early stages, is "What should we do about enterprise? Our investors are talking about it. Our employees are asking about it. What does this mean? How do we think about it? How do we frame it?"
And this is obviously a really big question. We're not going to be able to cover the totality of that in the few minutes that we have today, but I hope today that we can at least establish some common frameworks, language, definitions that will help you have that discussion with all of the stakeholders that you need to manage.
And hopefully, ultimately help you kind of navigate what is a tricky and complex question a little more quickly and a little more effectively.
Deal Size: The 1-2-3 Framework
I'm going to start by reintroducing a concept that I first laid out in a Heavybit video (https://www.heavybit.com/library/video/self-serve-go-to-market/) I did about 14 months ago, which is the 1-2-3 framework. And for me, the 1-2-3 framework is the grand unified theory of go-to-market. And I want to cover first, for a moment here, if you haven't had the chance to see that video, I do recommend you take a look at it if you haven't, because these concepts will be important in talking about framing enterprise among the possibilities you have in building your companies, and really ultimately where it fits.
The really short version is, in modern enterprise tech, go-to-market, you can think about all of your possible go-to-market and product value propositions, which in turn fundamentally drive the company building and organizations associated with those, as falling into one of three modes.
The first is traditional Free, what you would imagine going and signing up for, pick your favorite free product. The second, which is Team, which is typically signing up online, often paying online, potentially with the support of some inside sales organization behind that. But typically a high transaction volume, low-friction sale. And then the third being what we'll talk about today, which is enterprise.
And a couple things to highlight about this model for today's talk. One is the value proposition tends to align pretty cleanly with these three different modes. And I should add that, over the course of your company, you will probably end up operating in all three of these modes, but really a lot of the questions that founders face is how to prioritize these different modes and how to sequence them and how to think about investment across them.
So, in Free, value proposition typically is about creation, some kind of individual act. In Team, typically some kind of collaboration mode, video conferencing, Zoom, things like that are classic, as are a lot of the next gen collaboration tools out there, productivity tools. And then, finally, in enterprise, the value proposition is almost always centered around compliance. And we'll talk about that as well in this talk. And the other dimension we'll be talking about is deal size.
So, again, typically Free, maybe there's going to be some individual payment, average annual deal size. Let's call it less than a thousand. For team, less than 50,000. For enterprise, basically everything else. It's an important point to understand the nuance of what constitutes Team, what constitutes enterprise.
You could argue that maybe it's 25 is the cutoff point. You could argue, maybe it's 100,000 is the cutoff point. That'll vary, but for the sake of the presentation today, we'll just pick somewhere in the middle, at around 50K. And as we'll talk about in the presentation, it's really these two factors, the value proposition and the deal size, that really are at the core of what defines enterprise. So, what makes enterprise different?
What Makes Enterprise Different?
We're going to start by talking about that deal size dimension. We'll talk about the value proposition after that. And deal size is a really good proxy for really everything else associated with the sale, and all the things that you need to do and build, and be good at as a company, in order to participate in that market. And so, here, you can see those three different modes arrayed across what you can think about is the life cycle of a customer.
So, where does the customer come from fundamentally? How are they finding you? And I'm using the term here kind of broadly, where does the demand come from? What does the demand generation? What does the actual sale look like? What is the implementation? Who's responsible for that? How does that work? And then what's renewal? And the punchline in here is two things.
One is, with enterprise, you go through this transformation or step function where the enterprise motions and capabilities are really fundamentally different in terms of how all of these stages of the life cycle work than the ones that exist for Free and Team.
And there's a point here, which I'll emphasize. I think it's common for founders to think about what's different about enterprise as, "Oh, I'm just hiring some sales reps, and we will be able to hire, and then we will make our enterprise sale. And yes, we've got to find those folks, but that's all that's required."
One of the points of the slide is it's not just about sales. It's really about all of the different functions, demand gen sales, implementation, and renewal. And as we'll talk about, really, the key of this isn't so much even the sales people, and that's obviously an important and difficult function to build. It's really the question of demand generation, or fundamentally where your customer's coming from.
Where Do Your Customers Come From?
And that's where we go back to the 1-2-3 model, because there are really two approaches to enterprise. One is you are starting with enterprise, you're doing enterprise without the benefit of having a self-serve or team business, where you are going to have to effectively birth these new customers from nothing, and land them directly into enterprise. Versus what is more of a seed-and-grow, or conversion motion, where you are taking your existing team customer base and moving them into enterprise. And this is really about, you could even argue the whole ball game.
And that's because doing lead gen well is incredibly hard, and incredibly expensive. And it's something, as a function, that most companies don't have out of the gate.
And so, one of the biggest caution flags for companies going into enterprise too early, or going into enterprise without the benefit of having these other modes already built, is you are going to be dependent on building this traditional lead gen machine, which is typically a pretty unpleasant experience.
And one of the things that I find in talking to especially earlier stage companies is there's often a little bit of an enterprise mirage. Which is to say, by virtue of talking to VCs or being out there as founders, just doing product discovery, you have this early set of enterprise customers with attractive logos that you're engaged with and you are building product for, and you're like, "Wow, this is great. I was able to make these relationships and find these customers without having to do all this crazy other lead gen work. Gee, maybe I should just go ahead and continue to dive into that."
And that's this idea of the mirage. That you often have this pocket of enterprise customers that you get exposed to in an unnatural or unrepeatable, unscalable way, by virtue of just being a startup, that is different than building an enduring funnel and business in the enterprise.
And I'll nuance this by saying, I often talk to folks where they're working with enterprise customers, and they're understanding requirements, and they're getting really important product feedback and data. And that's really, really great, and I encourage that, but it's important to have a lot of intentionality.
Are you building a product there, or is the exercise to get a couple lighthouse customers, which will inform your product strategy and your overall development of your company? Or are you trying to build a full enterprise go-to-market machine and everything that's involved in that? The first I'm comfortable with. The second is an enormous investment that's going to be pretty tricky.
So, punchline, again, for most companies, it is going to be a lot easier, a lot more efficient and a lot more fun to build an enterprise business on top of a Teams business, as opposed to go straight enterprise and have to build all the lead gen mechanisms associated with that.
Deal Sizes for Public SaaS Leaders
Now, one of the reasons why that can sometimes be unpleasant or uncomfortable is you're like, "Hey, how am I going to build a business that's ultimately going to have its logo plastered on the side of the NASDAQ building in New York, if I'm not really acquiring these big customers that represent big deals and make things happen?"
So, I stole this chart, very conveniently, from SaaStr, that highlights looking at large, publicly traded cloud leaders, SaaS and Infra companies, and basically looking at how many customers they have and what's the average deal size.
And the punchline is pretty clear that having small average deal sizes or Teams-ish size deal sizes, below that 50 or 25K threshold, and having lots of customers is not incompatible with being a large, incredibly valuable thriving, publicly-traded company.
In fact, it is the most common model these days, and that's very encouraging. So, take some comfort in that it can appear sometimes that this is not a standard model, but with this new generation of companies, it is increasingly the norm.
And I'll add a couple caveats. One is going enterprise first and doing that kind of lead gen first thing, without the benefit of a Free or Team business, is absolutely possible. And plenty of companies do it. And you can see them, just in this chart reflected by their average deal size.
The Oktas, to some extent, you can see Coupa here, which is more on the finance side or Five9, the call center. These are a little more traditional, straight ahead enterprise. And that's great. That is a path, but that's unlikely to be your path. That is unlikely to be the path for most new SaaS and Infra companies.
With, then, the other caveat, which is, if you don't do enterprise eventually, which, again, looking at this list of companies most, if not all of them have enterprise offerings, with a few exceptions. If you don't do that eventually, you are probably going to fail. And my definition of fail here is drop below 20% year over year growth. And that's really what we all want to achieve at a minimum.
Final caveat. I just thought this was an interesting example. There is enterprise only, and there is enterprise first. And looking through the numbers, a great example of this is C3AI, which if you're like me, you probably have no idea what they do because they don't bother marketing to individuals or developers like me. But their average contract value is $7.2 million.
So, it wouldn't even fit on this chart. And that's a thriving, publicly traded company. Again, lots of models are possible, but the most likely path for you is going to be building a Teams business first.
Putting It Together: When Do You Go Enterprise?
Pulling all that together, talking about, "Do you go enterprise by going enterprise first? Do you go enterprise by building a Free and Teams business before that? The question that I most commonly get is, "When do you do it?" Not if, but when. And there are always these competing tensions around that question.
The first is what I'll call enterprise FOMO. Your competitors are there. You've got all these attractive customers and logos. You're missing out. And that wants to pull you towards doing enterprise earlier.
On the other side is enterprise phobia. And this, fortunately, I don't see as much, but certainly saw in a variety of companies I've worked at including Heroku. I think, to some extent, GitHub was famous for this. It was common of those vintage companies.
Again, fortunately a little bit less common now, which is this idea that somehow going enterprise is antithetical to the soul and mission and value of what made you successful with Free or Team users. And again, fortunately, that's, I think, been largely dispelled, but that can still be a cultural impulse that you'll need to manage.
Because, in fact, building a business that spans all the way from Free to enterprise is essential to serving your customers in the fullness of their journey, as well, of course, as building your business.
So, I like to think about, ultimately, what is the Goldilocks here? What is the not too cold, not too hot of this? And the test I would encourage you to ask yourself is, going back to that question of demand gen and where do customers come from-- Can you create meaningful demand for your enterprise product from your team and self serve customers?
Do you have enough that you can feed your reps, that you can build that business at whatever that minimal scale it needs? And that's really the only question. Because at the end of the day, demand is the fuel for these enterprise businesses. And that is going to be the constraint. That is the thing that most typically will keep you up at night.
And my punchline here is I rarely see it below 5 million in revenue. So, if you're under 5 million and building an enterprise business, I would raise an eyebrow, and it's rarely absent above 25 million. So, my ballpark Goldilocks number is 10 million. I've seen it creep down a little bit recently, but I think if you answer that demand question for yourself, it'll be a helpful framing.
What About Value Proposition and Product?
Okay, so we've talked about deal size and sales, and the when of enterprise. What I want to spend a minute talking about next is really the what, which is what is the value proposition in the product? And this is often what is really animating a company's or a team's desire to explore enterprise or go to enterprise.
And the thing that you hear most commonly is you're out talking to customers, and they love whatever the hell it is that you're doing, but they don't trust you, you little tiny startup, with all of their important data. And they say to you, "Gee, I love what you're doing, but I don't trust you. I don't trust your cloud. So, I want it on prem. And I'm going to pay you $1 million if you just deploy it on prem for me." And this is very attractive. It's what I sometimes call the indecent proposal.
And my first message is take comfort in the fact that this happens to everybody. I saw this happen in the early days of Salesforce. Fortunately, that company said no. I saw that happen in the early days of Heroku. I saw this happen in the early days of Dropbox. This happens to everybody. So, understand that this is a very natural reaction of just selling a cloud product, really anywhere.
And all of these objections to cloud are universal, and you're going to have to navigate them and negotiate them. These are not binary things to just flip a switch and now you've overcome it. This is just part of being a cloud business.
Managing, and again, back to that framework, this is fundamentally a question of compliance, or security and compliance, or trust, security and compliance. You are always going to have to manage that as part of your business, so treat it as that distinct value proposition that you need to build for, rather than some objection that you're just going to circumvent.
Compliance is a Feature; Thy Name is Tenancy
And you can see this in how companies that are further along have built their product line. So, at the top is the pricing page of Snowflake, the middle is Slack, bottom is FiveTran And you see the same pattern now, again and again, which is companies, as they get further into the enterprise, create their own top line, most expensive products that are compliance-oriented.
That is the value proposition. That is how they're addressing companies with the most strict compliance and security requirements, is by offering them a distinct product, a distinct tier on top of the other products that they have.
This is not just take something, offer a different deployment model. This is a whole new product line. So, the punchline there being think about this holistically as a product with its own distinct value proposition, rather than just, "This is a deployment model."
Now, if compliance is the core feature of this new product, the core expression of that feature is tenancy. So, what's common as well across all of these products is how they're being architected at their core.
Not Just a Deployment Option: Tenancy is Destiny
And I'm going to go on a little bit of a tangent that hopefully I won't lose you on, to explore this because I think it's a really important point that speaks to the core of the product strategy of what it means to go enterprise, and something that I think a lot of folks run the risk of getting wrong. High level, you can think about how you're building your product is one of three architectural modes.
Single tenant, which hopefully we're all familiar with, which is the old school, deploying an Oracle server database behind my firewall, I own the page or it's the customer, it's fully secure because it runs inside of my data center or at least my perception of secure. From a development point of view, it's a packaged piece of software and the teams that are building it, do a build of that thing maybe once a year or so.
I'm moving pretty slowly as the vendor. I am just dependent on whatever happens to be in your data center. So, I don't have a lot of control of what dependencies I want to take. I just say, "It'll work with these processors and this much Ram." And of course these deals are pretty, typically high because they have a pretty high implementation cost.
So, that's single tenant, of course, there's multi-tenant, which most of us are familiar with in the modern SaaS model, which Salesforce helped pioneer, which really shifted that. What is new in the world is what I call Meta Tenant. Sometimes it's called cloud prem or VPC deployment, which is really a new mix. And you can think about products like RDS or a product that I worked on for the private spaces that follows this model.
And the distinction here, and again, I could spend hours just talking about the slide, so apologize if it doesn't land, is it's a way of combining the isolation and dedication that you get, or discreet resources that you get, in a typical on-prem model within the cloud world. So, you typically have an isolated run time for anything that actually touches the data combined with a common control plane behind that. So, it's kind of a hybrid thing.
And the real advantage of this model is that it's a way to reach the most secure and nuanced and complex security requirements, and compliance requirements, with something that retains the economics and velocity and value proposition of SaaS. A lot to cover in this slide, but the punchline is this.
One of the most common mistakes I see companies do when they are thinking about engaging an enterprise from a product point-of-view is think that they can just go single tenant, and they'll take whatever their multi-tenant SaaS offering is and say, "Okay, we're just going to package off a single tenant version, and now we have our answer to all of those enterprise requirements."
Well, the problem with that is you've now basically just gone backwards into an entirely old model, which brings with it all of these constraints of the old model, in terms of how fast you're able to move, what the deployment and success criteria and complexity looks like, what the customer experience is, all the things that, frankly, are what we moved to cloud for in the first place. And I don't care if it is single tenant running on AWS.
At the end of the day, if you're shipping package software that's a customer's responsibility, you're inheriting all of those negative properties. And it's part of, again, I guess my caution or how I would think about framing your path to enterprise.
There is no shortcut on the compliance journey. If you go the single tenant route, you will be inheriting a mound of technical and organizational and process debt that you do not want to carry.
So, there's some exceptions here and there, but I would, just, again, to the point of this presentation, not going to cover all the details, but when you can, encourage a nuanced and intentional view of what your strategy is here.
Summary and Final Thoughts
So, in summary, going enterprise is really a decision that involves two things. What is the go-to-market motion? And that's holistically, not just sales, but also marketing, how you're going to be generating demand, and post sales on implementation and customer success. That's a whole bunch of stuff that needs to be worked out and thought about.
And it's a discussion and decision about product, which is, as we talked about, really a discussion about tenancy. And that's going to have implications for your product engineering organization that are pretty profound. So, the enterprise decision is going to touch everybody. Again, want to emphasize these are complex things that all companies will need to tackle eventually.
So, my message here isn't, don't do it. It's just do it with the right thoughtfulness and the right intentionality. As we talked about, a lot of this comes down to the most tricky part, which is demand gen. You can get to bigger deals using some kind of unnatural acts, but if you don't have a good Teams conversion motion, you're going to end up in demand gen hell. And I have seen company after company get in there and you start rotating your CMOs, and your sales leader and your marketing leaders can start fighting because it's just really, really hard to build this kind of stuff.
And you, as a CEO, are like, "What's going on? This is super painful. Why am I spending all my time here?" You don't want to be there, and you want to do your best to avoid that. So, I encourage caution there. And we're sitting here towards the end of the year. I'm working with a lot of companies helping them think about their next year planning.
I guess the thought I would leave you with is the most important decision you're going to make next year, really, regardless of what stage you're at, is how you are going to invest your resources across these three different motions. If you've got $100 to spend, how many are you spending in Free? How many are you investing in Team? And how many are you investing in enterprise?
And my message here, because none of us are going to get it exactly right, is it's better to be intentional than it is to strive for perfection.
If you just peanut butter, and you don't have an idea or framework or philosophy or intentionality behind those investment levels, you're going to end up basically just kicking the can down the road on all of these larger questions. So, think about it, have a plan, have a theory, at least, that you're using, and know that you're in good company as you struggle with these decisions. Because again, this is the same conversation that's happening across all of your peers.
Hopefully, that was a helpful, quick framing in thinking about going enterprise. My Twitter and email are there. I'm a proud, Heavybit LP alumni, an LP, an advisor. I'm always open to chatting. These are an example of some of the companies I work with, and I'd love to work with yours as well. Thank you so much.