Introduction Building Self-Serve Go-To-Market
Thank you everybody for taking a couple minutes out of your day to learn about self-serve go-to-market (GTM), a topic near and dear to my heart, I hope to be at least not the worst zoom of your day, given that we all live in zoom land these days.
You've heard a bit about my background. The part that may be more relevant, for the past 18 months or so since I left Heroku, I've spent it doing board advisory work for primarily developer-facing startups as well as some nonprofit organizations. One of the really rewarding things about being able to work across the range of companies that I do and at this stage is-- and there are probably about 30+ companies that I'm an angel investor in-- you really get to see a lot of the patterns that are surprisingly common when you're in the trenches every day. It's kind of hard to know what's unique and tough about whatever journey you and your company are on personally, versus, what's quite common to experience as a community.
I hope today to illuminate a little bit of that and share what I've seen working across a bunch of different companies, as we all look to increase our growth and revenue in this increasingly difficult time. This is a topic that I could literally spend hours and days talking about, but I'm really going to try and compress some key insights out. The other element of time here of course, is that in the current environment, all of us are under new pressure to really be focusing on our growth. And of course, with a little bit less margin of error, getting things wrong. So if I can help you avoid some of the mistakes that, at least I've made in the past, it will be mission accomplished. The other caveat is, I'm very much a frameworks person so this is going to be a frameworks presentation.
There's a lot of interest in self-serve as a thing. It's a topic that is getting a ton of attention and an important kind of theme in our industry. It's obviously been a trend particularly for developer-facing companies for a long time now. I think in light of how the current market environment is, it's getting even more attention for a whole bunch of reasons What is it? It's a lot more predictable than a traditional enterprise go-to-market. That can be really satisfying, especially in times of high uncertainties. But more importantly, at the end of the day, it's about having a much lower and much more efficient, go-to-market and customer acquisition machine.
I've had the pleasure of working a bunch of times with Tomas Tunguz, you probably know him from his blog. He's a partner at Red Point. This is a slide that I stole from him, basically looking at the sales efficiency of a bunch of software companies. And not surprisingly, when you look at the list, those that are kind of most self-serve oriented, and the core of their DNA tends to outperform in terms of efficiency. So that's obviously a really attractive thing in terms of the economics of your business, especially when we're all trying to manage cash that different way.
There are a bunch of other factors that I think are really appealing to founders. Building a self-serve go-to-market, it certainly isn't easy. I hope one of the things I can share today is, it's not as trivial as just putting your credit card form up and waiting for customers to come. It has much lower organizational complexity and risk than building the enterprise go-to-market, which is where so many companies not only stumble but have kind of really unpleasant and kind of gear-grinding experiences.
I think there's just a couple things to highlight there. One is, at the end the day, building self-service is a systems problem. It's the kind of problem that hasn't been solved. It's metrics oriented, it's process oriented, it's more of a machine, and founders are drawn to it. It's just a more satisfying problem space. The second, which is a little bit of a more nuanced point is the differences. It's like the difference between meal kit versus restaurant.
The point that I want to make there is, I get a meal kit from a service or a store, I'm on my own. As the customer, the expectation and burden of success, is clearly on me. When I go to the restaurant, every part of the experience is the responsibility of the restaurant, from the quality, of the parking, to the lighting, to the furniture, to the utensils, it's really kind of this holistic set of responsibilities you take on. There's a similar thing that happens with self-serve versus enterprise, which leads to all of this kind of organizational complexity.
Risk is the ethos. An enterprise sale requires this kind of very elaborate and engaged and expansive notion of customer success and responsibility, and that can be very tricky to execute. That's where a lot of the friction comes in.
I'll just add one caveat before I launch in. I'm a huge advocate of self-serve. With two caveats. One, in the long-run, it only works when it's paired with enterprise. I by no means hope to advocate self-serve at the exclusion of enterprise. It's essential that they go together, and that there are exceptions. It's not for everybody. It's not the only path. But for most companies, especially developer and infrastructure companies, it is the path.
Modes of GTM Exploration
Two kinds of modes I tend to see when I talk to companies: The first is the one that will probably match most of yours, is a free mode. You have no source product, whatever the case might be, and you kind of want to migrate self-serve. Or, I do see this about 20% of time, you're an existing enterprise, you got existing enterprise motion, you want to migrate down to self-serve. I'm going to focus more on the former today. And you're in the other camp, don't feel alone, that's definitely a pattern as well.
Pitfalls and Anti-Patterns
Here are some of the pitfalls and patterns. One of the main things I want to talk about is really how to frame self-serve, where it fits in the context, and how self-serve and enterprise relate. I'll spend time talking about aligning marketing, self-serve, some of the data infrastructure pieces, and ultimately ownership. So hopefully these will become a little clearer as we go through.
Brief History of Software GTM
There are two slides in this presentation that you should pay attention to. This is one. It's remarkable to me how much as founders, as technologists, as product people, as marketing people, we pay attention to the evolution and changes in technology trends. We all see the new frameworks and tool sand databases, we read HackerNews, etc. We have these refined aesthetics for looking at technology trends and migrations and patterns. But as a community, we end to not have as much an understanding or an aesthetic for the evolution of go-to-market itself.
We tend to think about go-to-market as a static thing that was born out of fire however long ago and now we're all just trying to wade our way through it.
One of the main points I hope to make today is that go-to-market evolves quite rapidly. And insofar as you can understand its evolution, and understand those patterns, you will be much better able to capitalize on those in your company. A classic kind of version of go-to-market that existed back in the 90s-- Somebody's selling an Oracle database to a CIO, on a golf course, with a Gucci shoe sales rep.
That's kind of the mental model that we have, and I think a lot of us find that very unsatisfying. Why? Because in that model, there's kind of an asymmetry between the buyer and the end user, right? The CIO buys the database, somebody a million rungs in the organization away has to use it. The CIO buys the expense reporting system, the CIO buys the web conferencing system. There's this asymmetry between buyer and user, the quality of the experience with the product tends to diminish. And that's why a lot of us have a little bit of this enterprise-phobia and skepticism, rightly so.
I'm not going to focus on that as much today but it's important to understand that was kind of where the world was in the 90s. I don't think we understand just how revolutionary the development of SaaS was for the new go-to-market motion. For the first time, with SaaS, I could sign up and enter my email address and get an application in an instant. This was a radical idea. In the 90s, if I wanted a CRM system, I would buy it, wait for the deployment to happen for 12 months, and then I would finally put my fingers on it for the first time.
Having a trial motion was also radically different. To be able to think about selling to department first and then sell up to the enterprise, that kind of seed and grow motion, that was also new. Now I could sell to a team because they didn't have the burden of the implementation complexity that would otherwise require dragging in the C level IT organization. With search, I now had an easy way of reaching those people because I could buy keywords and other kinds of advertising.
What's new is what I call go-to-market 3.0. That's what's obviously emerged in the past 10 years. That's the context in which true self-serve exists. Instead of selling to the department first and then selling to the enterprise, we're going to start with getting adoption for product at the individual level, then migrate up to the team via self-serve online motion, and then ultimately have an enterprise motion on top of that.
But among other things, is an understanding that each of these three motions is selling to the C level. Go-to-market 1.0 that was one motion, in go-to-market 2.0, these were two distinct motions organizations. This isn't about just one go-to-market motion. This is about distinct ones that need to align together and as an organization, an expertise that you're going to need to have across all of these.
The 1-2-3 Model
If you then kind of rotate that free team enterprise, you can kind of run those across what the customer journey is, or kind of a customer lifecycle, and see how these things kind of map out. This is the second slide that I ask you to pay attention to today, if you ignore the rest. This is what I call the 1-2-3 model. If anybody here today has ever worked with me at Heroku, they would have seen this before, this was really kind of my North Star for the organization, our growth from as you heard about 35 to 300 million.
The idea here is that there are really kind of three distinct but adjacent business that you're ultimately running. Now for today's talk, we're going to kind of leave out the enterprise piece, we're really just going to focus on team and self-serve. But it's helpful to think about these as again, kind of distinct channels that you have as you are migrating the user across them. You probably already know all that. What's really interesting is how predictable and repeatable the value proposition, the go-to-market motions, and the metrics are across these pillars.
That's really where the helpful patterns emerge, as you think about what your self-serve business is. Kind of implicit in that is saying, the value and the value proposition of your product for a free individual user is going to be distinct and different from value proposition of your team user. So as opposed to thinking about self-service just to go-to-market motion, it really has to be holistic and has to be about a different value proposition. Then on top of that, it's going to have a different go-to-market motion and you're going to measure the market differently.
The 1-2-3 Framework
What's interesting about this ism if you look across all of the all the companies that are kind of adopting, again, what I consider a 1-2-3 model, which is anybody trying to go from freemium kind of free, individual developer adoption all the way up through enterprise, it's remarkable how much the value proposition of the products and those tiers align. So I'd argue that in a free product, the value proposition tends to align to creation.
I'm an individual developer, I'm using Herokum I'm deploying an app, life's good. I'm a individual using a tool like Figma. I'm creating the same kind of single user mode that I would be in for creating a UI. I'm having a great time. That is very distinct from the value proposition off collaboration, which is fundamentally, how as a team are we organizing our work around a shared process.
So Heroku and single player mode versus Heroku and team mode, very distinct things. It's essential that you approach self-serve with that intentionality because you're ultimately going to be monetizing self-serve on that product. With free, what you're trying to do is drive adoption and engagement with team then with self-serve you're trying to take some percentage of that and convert it into ultimately what is typically a monthly MRR based business.
The punchline again here is that one, the value proposition with a collaborator of the product is different. So this has to start from a product-value orientation and the metrics are going to be different, and they're going to be predictably different in that almost always what you're measuring on 1 is engagement. And what you're measuring on 2 is MRR.
1-2-3 Framework: Product
What's really interesting and what I look for both as somebody creating products or as an investor, or as a coach in other companies, is how you do that transition up from free to team and then ultimately from enterprise. What's most fascinating for me is looking at that nonlinear value proposition change as you go from free to team. When you have that, it's almost like there are two product-market fit or customer discovery cycles that need to happen.
One is you have engagement with a free thing, or individual thing, but that is going to be distinct and different, complimentary but distinct, and different from that value proposition in the team mode and I'll give you one of my favorite examples, which is Postman. I think I saw some folks from Postman are on the call. Hopefully I'll get this right. This is kind of what I took away from talking to those folks.
So Postman is an API creation, authoring, management tool. You can think about individual mode as, 'this is a really useful utility for a developer to organize their API creation activities.' Okay, that's great. Well, in the team mode, what it becomes is, 'a way for multiple teams to organize what is a distributed development effort.' If I'm no longer building a monolith, and I'm now building across multiple teams with different services, which is a pretty common way for engineering organizations to operate these days, how you coordinate those teams, so you can build a holistic system is a really big strategic business problem.
What postman found, at least in my interpretation, is that by using that same tool with modifications, it now became this way of orchestrating this really strategic business process. Similarly, with LaunchDarkly if you just look at it as a utility for creating feature flags, you can say, 'well gee, that's convenient. I can write it myself or I can use this this thing off the shelf and I'm saving time.' That's kind of an interesting but limited value proposition.
When you think about LaunchDarkly in team mode, what it becomes is a way for a team to organize its business process in between PM and engineering, about how features are actually being created and deployed. So it almost becomes a product management process tool on rails. It's a very distinct value proposition, as you go into fundamentally enabling these collaborative business processes.
That's a hugely valuable thing. That's where you start really driving conversion. If you're just offering the same product, and this one has some modest differentiation from the free to team, you're going to have limited success in conversion. It has to be a distinct value proposition. I'll go back one slide to just say, for something on the enterprise side, what comes after that almost universally is compliance.
Here's a Heroku example. I'm an individual developer on free, I'm building apps, I'm having a great time. I'm now using it as a team. So now it's all about things like pipelines and how I'm organizing my overall software delivery practice and have multiple people contributing the same code base and doing testing, all that kind of good stuff. Then in enterprise, it becomes again distinct, where now it becomes primarily about what the compliance is with the organization, which means specifically, typically security, HIPAA, all those kinds of things, although there's also important kind of business process elements there as well.
What's also interesting then, is if you could think about what your different customer facing functions are-- from closest to the customer marketing to further customer biz ops, so marketing, sales support, customer success and retention, and then the back office pieces-- and you can think about how you then array them across these different pillars. The point of the slide isn't that this is the right answer. The point is that you have to think differently about who owns these pieces in these different modes.
As an example, who's the primary marketing owner? Is it a traditional programs-oriented marketing owner? Or is it a PMM marketing owner? So, often where companies go sideways, and why I find this framework so helpful, is it's really hard for an organization to execute well,in any one of these pillars. If you don't have some way of keeping these things separate and rationalized, you're just going to have people running over each other all the time, and it's going to make a bad time even worse.
It's really important that you understand, what organization and who are the people in the teams that own these along the way. As an example, one of the more interesting discussions is, who owns sales? Now sales here, in the free mode means, wow are you driving adoption? Though not of course, it's most often a marketing function. As you get into team, there are a lot of different ways of slicing it.
This is an area where I have a lot of different conversations with different startups. Sometimes that's done by marketing, which is to say, there aren't any reps at all. Sometimes you have an inside sales organization that's dedicated. That's how we did it at Heroku. Sometimes you have a support organization that, in addition to doing support, is effectively doing sales in that self-serve mode.
I will say I'm increasingly a fan of the idea of support again, especially for the products that we tend to work with as developer-facing companies, of having a combined support/sales organization for the self-serve tier. Again more to unpack there, but hopefully gives you some of the things that are important to consider.
Question One: Who Owns the Number?
One of the most fascinating things I see when I go talk to organizations about their self-serve efforts --and these are often companies that have quite robust self-serve efforts in place-- is who owns the number. So you're creating a self-serve business, you are, whatever the number is you're committing to for the year, 3 million, 5 million, 100 million, who owns that number? It's fascinating to me that this is a question that seems to elude so many companies or they get it wrong.
When I go talk to companies and I ask them this question and they say, 'well, I don't know. We don't know who owns the number.' Then I try the CEO, I say 'okay, well you own it.' That's the default state, where the CEO owns that, which is not always a great model. I think the common practice is to have sales own it. I have to say that I'm pretty skeptical of that approach because typically what will happen is you've hired some sales exec, who comes from that 2.0 world and you're asking them to participate in a 3.0 land and they don't get it.
This is probably one of the most challenging things overall, is there aren't that many people in the universe as a percentage who've done sales 3.0 versus 2.0. Why framing is so important is because they will tend to drag the company back to a 2.0 frame or they'll just be kind of a frame mismatch.
A classic example I see all the time, here is a company has, a bunch of free adoption, it's going great. They hire their sales exec because their VCs told them to. As a standard product technology founder, they're like, 'great, you go work on all this mysterious stuff.' Then they start immediately jumping to enterprise. Even in those environments, if you then try and backtrack and have some self-serve efforts emerge, sales will discount it, sales doesn't understand it, they will kind of yoke the organization back towards enterprise because they're operating in that 2.0 model.
It's possible for sales to own it, but I'm skeptical because it's often hard for them to really understand the value of having self-serve as a viable business. Then you're down to marketing or product. At Heroku, we had a hybrid function where marketing owned the self-serve business, which was pretty substantial, over 100 million when I left. I've also seen models where product can own it.
I do like the product orientation and ultimately, I even like aligning product to those channels, because really, these are three distinct product lines. Even having PM assume a GM function for that product line business, because of course, holistically the product, that go-to-market motion, the metrics are going to be different for each one of those tiers.
Tips / Other Questions
Couple tips as I almost land this at 30 minutes. Hopefully I've given you a little bit of insight to begin to think about how to work on these problems or some mistakes I've seen. The key thing is to have the right organization and ownership in planning your self-serve and team efforts. The biggest problem that I see is companies not being intentional and explicit about what the theory of their business is and where their customers are coming from.
Are your customers coming from lead gen, 'white paper'-gated content capture which is a classic sales 2.0 motion? Or are they coming from you converting them from being engaged active users, to then some 'teams' product? They're entirely different businesses, entirely different motions, yet we tend not to be as intentional or as explicit as I think we should be. I'll give you another analogy here. If you're running a product or an engineering organization, and you aaren't clear about whether you're building for on-prem or for cloud, imagine how confusing your engineering and product efforts are going to be. It will be a total mess of people just bashing against each other and you wouldn't understand why this is.
What happens all the time in organizations, as they plan their go-to-market because they don't have the right context, they don't have the right framing for what their customer journey is, for what the theory of the business is, for which of these modes they're operating. The second thing is, when you build these organizations, think very much about what the ownership looks like and what the kind of skills that you're bringing in are.
Another super common anti-pattern is a developer-facing company looking to build a self-serve business, hires a bunch of people with marketing in their title, but it turns out that they're classic sales 2.0 dimension people. So then what they start doing is buying ads and doing gated content you can capture, which is completely opposite of how the 3.0 model works. The 3.0 level model is about driving product adoption. 2.0 model is lead capture, trial, sell.
If you are confused about those things, you are going to waste a whole bunch of time and money. That will lead to your 'VP Marketing Early Death Syndrome,' where you churn out your VP Marketing in six months. That's super costly and emotionally taxing for the organization and a huge waste of time. It's important to be thinking about what are the skills the marketing organization that you're building needs to support this?
Act holistically. As I was mentioning, this is not just about a price point or a Stripe implementation. This is a distinct business value proposition. Plan for the journey. I could spend hours talking about how, as a self-serve business, it really relies on having a very robust understanding of customer behavior and activity, as well as building automated billing and provisioning systems. That is a significant investment. That is a big team.
How you do that as a startup is really tricky, but it's also really important. That's a particular area of interest of mine. Lots of interesting things happening in that space to make it easier. I'll leave with my last point. This was particularly true a couple years ago, it's less true now. There was a kind of a consciousness at companies like Heroku and GitHub in the early days, that going all the way to enterprise was going to be anathema to the company values or goals, and would somehow corrupt everything that had made the company and product successful.
I couldn't disagree with any of those statements more. If I see a business that's just done free and self-serve, and has resisted enterprise, I will see a business that is living up to only a fraction of its ultimate potential. So in the long run, self service isn't enough. You have to do the self-serve to enterprise transition as well while you're keeping all of those pillars healthy. That's the point. You're doing all three.
For me, the question is when, not yet, and as a benchmark, I wouldn't even begin thinking about it until your self-serve business. is at about 10 million ARR. So don't worry about it too early. But if you're up past 30, and you haven't done it, then I would be pretty suspicious. Hopefully that's a helpful framing to help orient you and your teams around thinking about self-serve.
I recently recorded an episode of EnterpriseReady podcast, where I spent a good hour and a half talking about this stuff in much more depth and probably more coherence. So I encourage you to check that out, I love talking about this stuff. I'm an official Heavybit advisor as well so please feel free to reach out to me at the email address.
The Effect of GDPR and CCPA on Enterprise Compliance
There's a baseline of capabilities you need to offer a self-serve cloud product. Let's pick a random example: FedRAMP. It's a strict compliance regime, which certainly doesn't make sense to have in your self-serve product. Compliance is nuanced. It's not just about these certifications, it's about how the product aligns to a company's own compliance regime. My default case would be, most anything that's kind of advanced compliance is clearly an enterprise capability. I would be very careful to not muddy the waters around what is just base requirement versus what is real additional value at the enterprise level. If my product helps you become GDPR compliant, that's clearly an enterprise feature.
Moving from a 2.0 Company to a 3.0 Company
Trials are an interesting case. Again, it's not one size fits all. I think trials make sense if there's no individual value proposition for your products or there's very limited long term use for an individual. So if you've been doing trials and you want to add a self-serve component to that, I think that makes a lot of sense. I would think about just having the self-serve be the main offering in the trial for the enterprise. I tend to be skeptical of trials in 2.0 and 3.0 companies.
Selling to Enterprises During Crisis
That's where that kind of meal kit versus restaurant analogy comes in. A lot of the costs of going enterprise are hidden. You don't realize the amount of person time and hand holding there is for every aspect of supporting the customer that goes into being an enterprise business. As an enterprise, they have expectations about how they're going to interact with you as an enterprise buyer. You have to effectively have all the API's, which are incredibly complicated and costly.
That said, I want to be very explicit about something. If you're selling to a department within an enterprise, that's totally fine. Enterprise sales is selling to the C suite with compliance features versus selling to the department with collaboration features. Those are my definitions. If you can get departmental customers, that is the key to your business, because those are the ones that are ultimately going to migrate up enterprise.
The other thing I see happen as an anti-pattern is, companies really want to go to enterprise and they skip self-serve. What ends up happening is, you end up selling via enterprise channels, which is very expensive. Essentially, self-serve deals, let's just call them deals under $40-50k annually. When I look at enterprise sales at an organization and they're doing $20k transactions annually, those should be self-serve deals. The biggest failure mode is not being intentional about where you are in the model and being indifferent to whether your customers are coming from trials and traditional lead capture versus via a freemium conversion process. There can be a tendency as a CEO to say those are just marketing tactics. Choose whichever one's best.
My message to you is, this is as different as being cloud or on-prem. These are existential questions about the orientation of your business and if you're not intentional about where you sit in this model, you are going to have a really bad time. You are just never getting alignment and you're going to be calling up your friends and being like, "wow, this job sucks. How come? My sales and marketing people are fighting with each other all the time, and I can't get anything out of any of them."
When we talk to other founders, that's pretty common. Why does that happen? We're not being intentional enough about our go-to-market. Be intentional about how you're hiring and building your marketing organization and who you're doing it for. We've talked about self-serve but we haven't talked about what marketing motions and what kinds of investments make sense to build for free. That's where most of you, if you're under $3-4M revenue, probably should be focused on, building at the top of the funnel and adoption and getting that machine going so ignore that.
3.0 Company: How to Pick a Head of Sales
Typically what happens is, or at least what I've seen is, if you've built a freebie thing that's getting engagement and adoption, you've got a self-serve machine. If you crank that up to $10M ARR or somewhere in that ballpark, then you start doing some exploratory enterprise, probing, and selling. So typically you're not starting with a Head of Sales, you're starting with a sales rep who is going to be much more solution-oriented. Not your traditional kind of transactional or repetition kind of sales rep but one who's more comfortable with helping you as a CEO, who's helping your product teams, helping your marketing team.
Discover what that value proposition is because if you don't know what your enterprise proposition is, you're going to have to tease that outwith your customers. When you're ready for 3.0, it isn't like, "boom, let's hire the head of X or a big fancy sales executive." By far the most common example is early days, you hire a sales exec, then you end up getting rid of them nine months later because the whole thing is burnt out and you had a bad time.
Getting customers is incredibly hard. What the VP of Sales will say is "how come you're not giving me better leads?" and you'll point to the marketing exec and tell them to deliver better leads. Then when you have a 1:1 with your Head of Sales, they'll say you need to fire the VP marketing because they're not delivering the leads. The problem isn't the VP of Marketing. The problem is that you're operating on the wrong model and you have no repeatable way of actually generating pipeline and business.
Marketing Self-Serve Products as a Different Company
The whole point is to take people from 1.0 to 2.0 to 3.0. If I had to interact with a different company or a different brand or a different product, that would be really goofy. So no, the whole point is that this this journey should be holistic and connected and that you're kind of moving people through these stages without forking the brand.
How Open Source Companies Fit into the Framework
I've had a whole bunch of conversations with existing or semi-mature open source companies, which I'll define as being older than 5 or 6 years old, because the whole model they went to market with was, get a whole bunch of free adoption, and then do some enterprise sales. They did 1.0 and 3.0. That was their pattern. They woke up and realized two things. One is, and this is I'm saying exclusively open source companies, they realized that they were managing a smaller number of larger accounts and they weren't gaining new customers.
And on top of that, if you went inside those organizations and talked to the people, you realize that they kind of supported 1.0, they supported the developer community as kind of this lip service, "oh, it's good for the brand." Sure, but it had no connection to the business and driving leads and driving revenue, driving dollars. Sometimes that becomes enshrined in all of this cultural cruft of saying, "no, we can't possibly interact with these people on a marketing basis because that would violate some unwritten rule of developership," when in fact, what these people actually wanted was to be able to take these technologies and use them more deeply in their organization.
Realize that that model is dead. So if you're a new open source company and you're thinking about doing 1.0 and 3.0, I can tell you that all the existing ones are trying to go back down and reinsert 2.0, because they don't have any way of driving new pipeline. The other thing I'll say is, which is a little more controversial, there is no distinction between an open source and a cloud company. Because if you're not doing cloud-first as an open source company, you're probably not going to survive.
But there's a guy who ran Heroku whose whole business premise was making cloud versions of open source products. So that might be a topic for a different day. But on-prem, don't do it. I don't care how many customers want to pay.
Risks of Moving from High-End AI to Self-Serve
That's more a function of the AI business than it is of the 1-2-3 model. Everything that I've come to understand about the AI business is, margins tend to be poor because it's so resource intensive. It tends to be very professional services heavy, which is implicitly a 3.0 business, not a 1.0 or 2.0 business. So, you know, there are exceptions. If you've got margin problems, you have value problems, and crafting value out of AI is super hard. That's just part of the space. It depends on what your definition of a good margin businesses is. Traditional SaaS businesses can operate at 20-30% and still have a good business. But there definitely are kind of yellow flags associated with the AI business in general.
Building a Support System
As I mentioned, I'm a fan of, at least in the beginning, building integrated support and sales teams for self-serve. Because in my experience, the work that those people are doing, the account managers who manage self-serve, it's almost always technical and support in nature. So why not actually integrate those things and just have it be a support team that is oriented around talking, not only to existing customers, and this is the difference, but to prospective customers as well and helping get them through the buying process.
So it's not to say that they're exactly the same as just taking a support organization and drawing them in. But I do think the same team and the same people with the right training can get you there in the most efficient way. The caveat is when you're ready to add 3.0 , then you need a different kind of account management to go into the self-serve accounts and aggregate the right ones and get them ready to go from the 2.0 to 3.0 motion. But that's a separate thing than going from 1.0 to 2.0, which is kind of primarily what we're talking about here.
The Metrics and Values Investors are Looking For
The metrics are about how you're doing or about the engagement and adoption of your product. In almost every Series A deal I've seen, what investors are looking for and what they expect is that you have a product that has developer engagement and adoption. What they're giving you money to do is to work out how to build 2.0 once you've done 1.0. This is another anti-pattern I see in fundraising, maybe even later than series A, is to confuse building revenue with building a machine.
Speaking for myself, I'm not looking at the business as a function of the revenue, I'm looking as a function of the opportunity. Frankly if a Series A company came to me and said they closed a $100k deal, I would probably treat that with some suspicion because I would worry that they were over rotating to enterprise, which I think wouldn't be sustainable. I'd be much more interested in what their adoption is, which ultimately translates into potential for building self service.
Viability of Mini Orgs in Self-Serve
I think you can make it work in different ways. At Heroku, enterprise was a separate part of the organization. We even had online sales as part of marketing. But there are a lot of different ways of sorting the org. The org structure isn't as important as the intentionality. Let's say you have a separate org for self-serve, okay, that can work. Well how are they interacting with product?
One of the key things that I've tended to do is create standing monthly meetings, across sales, marketing and product. One for the free business, one for the self-serve business, one for the enterprise business, to give the clarity of allowing each of those cross functional teams to have a common set of priorities and backlog items within each one of those verticals. Because if you just have one product backlog for the company as opposed to having some view or lens that allows you to think about it based on a business line, it affects your ability to really prioritize. How do you begin to rationalize those priorities in a way that's coherent, high trust? You have to have lanes for these things operate.
Differentiating Your Marketing and Sales Remotely
In some ways, this is a blessing. I'll tell you that one of the positive things I've seen-- this is an opportunity to save your organization, reset your people, have a conversation, and realign your organization around a better marketing model. You get a free pass to shake up your organization and realign without having to ruffle a whole bunch of organizational feathers. I don't want to minimize any of the challenges of the environment. But for the products that we sell, selling, engaging, and marketing online, given that we're all nerds, we're at least better off than most.
Differences Between Free, Individual and Self-Serve Team Tiers
You can think about CI/CD as being a team value proposition, right? Anytime you have multiple developers working on a code base, there's a whole universe of stuff that tends to come with it that's less important. If you were just an individual developer, writing by yourself, the reality is that we tend to have this idea, this mental model of developers as solo practitioners. What it means to actually develop and work in a team is very different from what it means to develop and work as an individual.
So an example is something like source control. We're all familiar with it. We all use it every day. It's implicitly a team value proposition. Other than backing things up, I don't really need source control. Think about the individual value proposition of Dropbox which is, I can pack my stuff up so if my computer catches on fire, it's still there and I can have access to stuff remotely. That's great, super valuable. Then think about the team value proposition of Dropbox which is, teams can collaborate and stay synced.
Examples of Enterprise Value Propositions
Most enterprise sales are about business transformation in some way. What an enterprise is buying a product for, is to be good at a business process. This is even true of something like Heroku. This is one of the more strategic things that you as an organization need to focus on. That's what commands the C suite attention. There's some fundamental business change that's trying to be affected. Great enterprise sales align to that. What company isn't trying to fundamentally grow its customer revenue? To use kind of a cliche, compliance is a good anchor, but also something that is really transformative and strategic to the business.
A lot of where developers get frustrated is like-- "I'm selling a Kubernetes run time. Why isn't that the most strategic thing in the world? Look how cool and different it is?" Well, you've got to build the delta between the potential of that product and technology change and its realization to make it as simple as possible to spoon feed to have an impact on transforming an organization. That is the difference between an individual product and an enterprise product. It's hard and you have to have empathy for organizations to do it.
Guidelines for Allocation of Resources Between Enterprise and Self-Serve
I think the key thing is that you better start with a product and product vision that is distinct from the enterprise product. One of the things that you see is failure modes in companies going from 3.0 to 2.0. A common path is, they take a product that ships usually with a busload of Deloitte consultants and what's implicit in the sale are all these people and all these processes that kind of surround the product and take it from sale to implementation. That smooths over a whole universe of edges that otherwise exist and that's okay for 3.0 for an enterprise sale. That's got to happen in order to really have impact on the business transformation.
But if you don't have that, it's a very different experience holistically to create value for self service, create value for a team. And so I'll see companies take an enterprise product and put it onto the self-serve channel and say, "go out and have fun." Of course it's chaos because it's a product that has no meat, that has no experience or orientation to actually serving those customers. Intentionality has to start with a product first.