October 31, 2018
Ep. #50, Marketing an Open Source Project
In episode 50 of To Be Continuous, Edith and Paul look at how marketing plays a role in open source and how creators can turn a vision into ...
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 past18 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 along 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 nots urprisingly, 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 kitf rom 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. You can look at companies like Viva, which is one of the most successful and capital efficient startups in the past 10years. They are not a bottom-up company but they're incredibly successful. It's not the only path. But for most companies, especially developer and infrastructure companies, it is the path.
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 but if you're in the other camp, don't feel alone, that's definitely a pattern as well.
H ere 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.
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 Hacker News, etc. We have these refined aesthetics for looking at technology trends and migrations and patterns. But as a community, wet 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 wait 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 those 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 I 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 seating 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.
And 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. And this is my second slide that I'd asked you to pay attention to today, if you ignore the rest. This is what I call the 123 model. If anybody on the call ever worked with me at Roku, they would have seen this before, this was really kind of mind Northstar for the organization, our growth from as you heard about 35 to 300 million. And the idea here is that there are really kind of three distinct but adjacent business But you're ultimately running. Now for today's call, 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 kind of across them. Well, that you all probably know, what's really interesting is how kind of predictable and repeatable the value proposition, the go-to-market motions. And the metrics are across these pillars. And that's really where that kind of helpful patterns emerge, as you think about what you're self-serve businesses. And 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 salt service, just to go-to-market motion. It really has to be holistic and has to be about a different value proposition. And 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. What's interesting about this is if you look across all of the all the companies that are kind of adopting, again, what I kind of consider a one to three model, which is, again, 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, you know, in a free product, the value proposition tends to align to creation, right. I'm an individual developer, I'm using Heroku I'm deploying an app, life's good. I'm a individual using a tool like Figma. You know, I'm creating, you know, like the same kind of single user mode right 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 kind of a shared process, right? So Heroku and single player mode versus Heroku and team mode, very kind of distinct things And it's essential that you kind of approach self-serve with that intentionality. Right, 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 what self-serve you're trying to take some percentage of that and convert it into ultimately what is typically a monthly MRR based business. But the punchline again here is that one the value proposition with a collaborator of the product is different. So this has to Start from kind of a product value orientation and to the metrics are going to be different, and they're going to be predictably different in that almost always what you're measuring on one is engagement. And what you're measuring on two is MRR.
What's really interesting and what I look for both as somebody creating products or ass an investor, or as a coach in other companies, is how you do that transition from team up from free to team and then ultimately from enterprise. And what's most fascinating for me, is looking at kind off that nonlinear value proposition change as you go from free to team. And when you have that when you it's almost like they're kind of to product market fit or kind of customer discovery cycles that need to happen. One is you have kind of engagement with a free thing, but that 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 kind of creation, authoring management tool. And so you can think about it in kind of individual mode is this is a really useful utility for a developer to kind of 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 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, right? And what postman found, at least in my interpretation, is that by using that same tool with modifications, it now became kind of this wave orchestrating this really strategic business process, certainly launch darkly if you just look at it as a utility for creating feature flags, you can say, Okay, 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. Okay, that's kind of an interesting but limited value proposition. When you think about launch darkly in team mode, what it becomes is a way for a team to organizer its business process around in between pm and engineering, about how features are actually being created and deployed. So it almost becomes kind of a product management process tool on rails, very distinct kind of value proposition, as you go into kind of fundamentally enabling these collaborative business processes. That's a hugely valuable thing. That's where you start really driving conversion, right? If you're just offering the same product, and this one, you know, 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 kind of just saying For something on the enterprise side, what comes after that almost universally is compliance. So, again, he was the Roku example. I'm an individual developer and 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 codebase and doing testing all that kind of good stuff. And then in enterprise, it becomes again distinct, where now it becomes primarily about what the compliance is with the organization, which means, you know, specifically typically security, HIPAA, all those kinds of things, although there's also important kind of business process elements there as well. Okay. What's also interesting then, is if you could think about what your different customer facing functions are, right, 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. And 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. So as an example, you know, the primary who's the primary marketing owner? Is it a kind of traditional programs oriented marketing owner? Or is it a PMM, marketing owner. And so often where companies go sideways, and why this framework I find it 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 kind 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. So it's really important that you understand what organization what are the people in the teams that kind of own these along the way. As an example, one of the more interesting discussions is who owns sales. Now sales here The free mode really means right? How are you driving adoption. And so that is, of course that while not, of course, but that's most often a marketing function. As you get into team, there are a lot of different ways of slicing it. And this is an area where a team and selves are 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 didn't Heroku sometimes you have a support organization that in addition to doing support is effectively doing sales as well, again, in that self-serve mode. And one of the many kind of things that you need to get right similarly, thinking about kind of who wins on success and retention model. 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 And support slash sales organization for the self-serve tier. Again more to unpack there, but hopefully gives you some of the kinds
of things that are that are important consider 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 kind of 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,000,005 million 100 million. Who owns that number? And it is fascinating to me that this is a question that seems to elude so many companies or they get it wrong, right? Because, well, it's funny when I go talk to him companies and I say, I asked them this question. And they say, well, I don't know. We don't know who owns the number. Then I talk I tried the CEO. I say okay, well you own Right, that's the kind of default state. So there's a default state which the CEO owns that which is not always a great model. And then of course, I think the common practice is to have sales owner. And 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 land and they don't get it. And 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 two out Oh, and why framing is so important because they will tend to kind of drag the company back to a 2.0 frame or they'll just be kind of a frame mismatch. So a classic example here is a company has you know a bunch of I see this all the time. A company has a bunch Free adoption, it's going great. They hire their sales exact because their VCs told them to. And you know, as a standard product technology founder, they're like, great, you go work on all this mysterious stuff. And then they start immediately jumping to enterprise. And even in those environments, if you then try and backtrack and try and you know, have some self-serve efforts, emerge, sales will discount itself doesn't understand it, they will kind of yoke the organization back towards enterprise because they're operating in that $2 model. So it's possible for sales to own it, butt I'm skeptical because it's often hard for them to really understand the value of having self-serve as kind of a viable business. So then you're down to marketing product. And at Heroku, we had kind of a hybrid function where marketing on the self-serve business, which was pretty substantial, over 100 million when I left. I've also seen models where product and own it and II do like thee product orientation and ultimately on Unlike aligning product to those channels, because really, these are three distinct kind of product lines, and even having pm assume a kind of a GM function for that product line business, because of course, holistically the product that go-to-market motions, the metrics are going to be different for each one of those tiers.
Okay, couple tips as II almost land this at 30 minutes and hopefully have 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-server and kind of team efforts. So the biggest problem that I see is companies not being intentional and explicit about kind of, as I like to think about it, what the theory of their business is. 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 them some teams product, entirely different businesses entirely different motions, yet, we tend not to be as intentional as explicit as I think we should be I'll give you a kind of other analogy here. If you're running kind of a product or an engineering organization, and you are you aren'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. There's a docs team over there writing an install guide. There's somebody else over there saying you need to have coffee as a dependency. 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 is the ownership look like and what are the kind of skills that you're bringing in. 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 their classic sales 2.0 dimension people. So then 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 right the three 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 turn out your VP marketing in six months. And that's super, super costly and emotionally taxing for the organization and a huge waste of time. So really, really important to be thinking about what are the skills the marketing organization that you're building support this act holistically. As I was mentioning, this is not just about a price point or a strike implementation. This is really a distinct business value proposition playing for the journey. Again, limited time here today but 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. You know, 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 some interesting things happening in that space to make it easier. And then I'll just kind of leave with my last point. And this was particularly true a couple years ago, too less true. Now, there was a kind of a consciousness that companies like Roku, and give up in the early days, with 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. And 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 you're self-serve business. As a About 10 million, MRR, 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. So a bunch of stuff there, we'll move to kind of more q&a discussion. Hopefully that's a helpful framing, to help orient you and your teams around thinking about self-serve. I recently recorded an episode of enterprise writing 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. And I love talking about this stuff. I'm an official habit advisor as well. So please feel free to reach out to me at the email address. They're happy to talk to you about your companies and your journeys.
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 or compliance regimes. 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 kind of base requirement versus what is kind of real additional value that's at the enterprise level. If my product helps you become GDPR compliant, that's clearly an enterprise feature
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 kind of 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 .
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 sale 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. Howc ome? 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.
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 o1: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.
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.
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 realize 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 became 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, your I can tell you that all the existing ones are trying to go back down and reinsert 2.0, because they don't have anyway 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 opensource 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.
That's more a function of the AI business than it is of the 123 model. Everything that I've kind of 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. I f 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. I t 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.
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 are abouthow 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 a nd 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. T his is another anti-pattern I see in fundraising, maybe even later than series A, is to confuse building revenue with building a machine . S peaking 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 a self service.
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? O ne 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. H ow do you begin to rationalize those priorities in a way that's coherent, high trust? You have to have lanes for these things operate.
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.
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.
Most enterprise sales area bout 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 s 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 runtime. 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.
I think the key thing is that you better start with a product and better start with a 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, t hey 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 servingt hose customers. Intentionality has to start with a product first.