EnterpriseReady - Ep. #28, Intentionality First with Enterprise Advisor Adam Gross

I'm a big believer that all platforms are really domain-specific. The word platform kind of conjures this use-case neutrality, which is probably not that helpful. And the idea that we're just all gonna operate on some core base set of common primitives is ultimately, if nothing else, depressing. Because that would imply that there's gonna be so little innovation that the only things that we can use are these kind of lowest common denominator, broadly homogenized tools and services. The thing that I think is most relevant to companies today is thinking about the relationship between bottoms-up and enterprise go-to-market.

You're listening to the Enterprise Ready Podcast, a show aiming to change the enterprise software narrative from how to sell to enterprises to how to build for enterprises. We'll interview industry experts and enterprise software founders as we break through the jargon, establish a common vernacular, and share the lessons learned from building the world's best enterprise software. Hi, I'm Grant Miller, creator of Enterprise Ready and founder and CEO of Replicated, where we enable cloud-native software vendors like HashiCorp, CircleCI, Snyk, and many others to operationalize and scale the distribution of their modern on-prem applications. Check us out at replicated.com. The Enterprise Ready Podcast is brought to you by Heavybit, a program dedicated to helping startups take their developer products to market. For more information, visit heavybit.com. If you're interested in being a guest on the show, or if you'd like to suggest a topic, or just learn more about enterprise features, find us at enterpriseready.io. This is one of several podcasts that were recorded pre-COVID, but are being released after this pandemic has changed so much for all of us. Nevertheless, there are many amazing insights in this conversation that are truly evergreen. In this episode of the Enterprise Ready Podcast, I sit down with Adam Gross, whose previous roles include CEO of Heroku, VP of Platform at Salesforce, and startup advisor investor extraordinaire. Adam and I start off discussing his background from starting his first company, joining Salesforce, through running Heroku. From his experience at early Salesforce, we dig into some of the more complex problems of the early SaaS world, such as challenges of creating customizable SaaS software, which is something that hadn't really been done before Salesforce. We then dive into several of Adam's key frameworks, starting with his 1-2-3 model for how companies should think about product assortment with 3 plans: create, collaborate, and compliance. Of course, we have a small debate about on-prem versus SaaS, which ends up with Adam's perspective on the importance of control planes for hybrid models. We cover a few other along the way, all of which I thoroughly enjoyed. I'm so pleased to share this episode with you all. All right, Adam, thank you so much for joining.

My pleasure. Thanks so much for having me here, Grant. Cool.

All right, let's dive into it. You have a pretty extensive background in enterprise software.

Are you saying that I'm old? Yeah, I kind of feel like you're saying that I'm old.

Slightly, slightly old. So tell me like how you got into enterprise software. You know, where did it start? Kind of how did you start doing this?

I think like most people, slightly completely by accident. I started my first company in the Web 1.0 era. It was a web analytics company. And at the time, I couldn't have known less about enterprise software. It's not something that you typically pick up in college or just kind of accidentally. And of course, this was obviously kind of pre the Y Combinator startup era, so a lot of learning had to happen on the street in general. So the company was called Personify, and as we came to kind of discover Over a period of years, it absolutely was an enterprise software company. Basically, it was kind of selling data warehousing solutions to, at the time, a lot of kind of internet web 1.0 companies. And in the process, probably made every mistake in building an enterprise software company that you can. And the whole thing was completely mysterious to me. You know, how one goes about building software for enterprises, how one goes about selling and supporting it. A lot of what motivates me now is trying to help companies at least avoid the mistakes that I've made because it's kind of a hard thing to pick up. It's not as intuitive or even necessarily as fun as the technical parts of what we all do. But learning about kind of building go-to-market, building an aesthetic for go-to-market, understanding how go-to-market is changing and evolving, in my mind, is probably one of the more undervalued and important kind of disciplines in our domain.

Interesting, okay, so I have definitely learned a lot from you in our numerous conversations throughout the last 5 years since I started Replicated. You know, I was mentioning a conversation we had maybe 3 or 4 years ago was one of the more interesting conversations that sort of helped push how I think about our company and how I think about the opportunity.

What did we talk about then? Remind me about that.

Yeah, we were arguing about on-prem versus SaaS. And so it was a very, you as, because, Didn't mention is you then spent a lot of time at Salesforce.

Yes.

And so you were very intimately familiar with a lot of the sort of nuance of why multi-tenant SaaS was like a really important part of how software is delivered. And so you helped me think through a lot of things, which is really interesting.

I'll share as kind of by way of introduction, a little bit of that story. I've been a pretty hard cloud zealot now for almost 2 decades. And again, like, kind of the enterprise go-to-market stuff in general, it comes from having learned a lot of hard lessons. So my first company, Personify, enterprise software company, you know, large, kind of doing on-prem what were effectively kind of data warehouse deployments with incredibly immature technology. This obviously predated all of the things that we take for granted now in terms of databases, but there was only on-prem, right? Sure. In that era. And man, one of the things that I learned the hard way was how difficult it was to make customers successful, especially with what was a very complicated kind of on-prem data warehousing, data analytics product. And so by the time Web 1.0 ended, so now we're kind of up to 2000, I was completely on board with what at the time was called on-demand. If there was a different way of deploying software, other than on CD, I was, you know, my fingers were raw and bloodied and ready. And so that's how I got cloud religion early. And after a brief stint at a company called Grand Central, very brief stint, ended up going to Salesforce in about 2002 when the company was, it's probably about $20, $30 million in revenue, maybe about 150, 200 employees. And I was obviously very, very attracted to the cloud thing, although we didn't call it that then. And if you connect the dots, I was effectively in the CRM space by virtue of doing customer analytics at my previous company. So there was actually some domain relationship there as well.

Okay, interesting.

But yeah, and, you know, developed a whole bunch of cloud religion, which only has become more reinforced over time.

Yeah, sure. And so, and what did you do at Salesforce? What was your role there?

So I was one of the first people hired to work on the platform, which has been renamed more times than Prince over the past 15, 20 years. At the beginning, it was called S-Force. Now it's largely called force.com. And my first product there, and this is 2003, was the web services API. Mm. But then went on to do kind of a whole bunch of platformy things, for those of you who know Salesforce. Everything from custom objects, AppExchange, Visualforce, all kinds of goodies. And there's a lot to unpack there. It was an amazing experience that I'm very, very grateful for. Among other things, it was really about creating a new kind of app dev model that was kind of specific for the cloud. Because of course, to take a little bit of an aside, if you rewind to say 2005 and the dawn of SaaS, The conventional wisdom was that SaaS was something that was okay for small business. It was okay to put in place while you were waiting for your kind of traditional Siebel CRM system to get up and running. Literally, Gartner's recommendation was deploy SaaS while you wait for on-prem implementation to be finished.

Oh, that's funny.

And the reason why that was kind of the market view was nobody had a kind of a mental model for what it would mean to customize and integrate a SaaS enterprise application in the cloud. It was like a speed of sound problem, right? Before Chuck Yeager did it, nobody— some people didn't think it was possible. There was no mental model for how that would work. And there was no way that a SaaS application could reach the kind of both value for customers and ultimately kind of economic value and market impact unless it could have those kinds of enterprise customization integration requirements, which we now completely take for granted. But at the time was completely novel to think about in a SaaS framework.

And is this because the way that applications were integrated on-prem was actually, like, through the database and through the data layer? What's the reason that that was such a complex or unsolved concept?

Yeah, it fundamentally had to do with the kind of abstraction layers or kind of mechanisms of control that one would have on-prem versus cloud. And of course, what Salesforce rightfully really kind of pioneered was the idea of multi-tenancy. And we could have a whole separate discussion about kind of the future of multi-tenancy and what's happening there. But at least for kind of the 1.0 SaaS era, it was a foundational concept. And the reason why it was so important, it was the first way in which you could, in today's terms, kind of elastically or kind of very simply provision an instance of an enterprise application. Before, you would think about kind of, you know, literally buy the boxes, image them, rack 'em, stack 'em, then, you know, ultimately get all the software installed.

From a CD.

From a CD, right? And versus go online, sign up, Get an email, you have an account. Again, today, obvious. Back then, that was kind of new. And the downside of that, or the counter to that, was, okay, if I'm kind of existing in this whole different kind of technical concept and set of constraints of multi-tenancy, I don't control the database, I don't control the OS, I don't control the app server. None of the traditional kind of app dev points are available to me. So, how do I even begin to reason about about making this thing match whatever my custom business processes are as an organization. And that's what required this whole kind of different model that was ultimately created.

Interesting, okay, and so, and that model was sort of part of the platform, right?

That was the platform, yeah. You know, it's a little long in the tooth now, but at the time was some pretty interesting and amazing stuff. And the fascinating thing was, working on the platform at Salesforce was, The kind of development of the platform was really tied to the development of the company and even the development of the SaaS market. So each time we were able to kind of build some new important capability, and I had the benefit of working with some of the most amazing engineers I've worked with in my career who were doing all this, whether it was being able to modify the schema or modify the business logic or modify the presentation layer, each time we were able to kind of demonstrate this, we would kind of open up the entire kind of addressable market for Salesforce in particular and SaaS in general. So we were kind of demonstrating and expanding the model as we were kind of introducing each one of these new platform features. And, you know, the, really the story of the first 10 years of Salesforce and the story of it going from a big deal being 100 seats to a big deal being 1,000 seats to a big deal being 100,000 seats is really the kind of story of the evolution of the platform because that's what helped it go from being able to meet kind of a departmental or small business need to ultimately, you know, being able to meet as complex a kind of set of requirements as you could throw at it.

And this is because, I mean, the integrations became so critical. Couldn't just be you use Salesforce and do all these things internally, but they had to integrate in this whole workflow and process.

Yeah, they're really kind of two related but separate ways to think about how the platform was kind of interacting with the enterprise and the market in general. On the integration front, that was obviously essential for your CRM system to be able to fit into your enterprise architecture. It was a whole nother thing for Salesforce to become the center of an entire CRM ecosystem, which I think it has now. And those are all kind of integration and API concerns. There's a related but kind of separate set of concerns, which are, I've got a bunch of business processes, you know, if I'm, a fast food chain, or I'm an airline, or I'm a software company, my business processes about how I fundamentally acquire and service and sell to customers are gonna be different, sometimes in subtle and sometimes in profound ways. And I need to be able to, as a business, really encode into this application whatever my business processes are. And that's more of that kind of app dev customization concern than it is an integration concern.

Yeah, okay. That makes a lot of sense. So that's like the ability to, As an internal developer at company X, I mean, can you name some really those early customers that are doing interesting things?

I'll give you a modern metaphor, right? A product that came out recently that I'm really impressed with is GitHub Actions.

Oh, right.

Right, and so if you think about— GitHub has always had an API. I can integrate with GitHub in all kinds of interesting ways. Now with GitHub Actions, I can program GitHub, right? That's kind of more of a business process concern.

Yeah, that makes sense. You know, the other part too, you kind of mentioned these things are long in the tooth now, but I think actually having the context on how Salesforce became so successful and why the platform was so successful, it's actually super relevant to companies that are being built today, right? Because these things repeat themselves, right? And they repeat themselves as new platform shifts come, the same lessons that were learned in previous generations end up needing to be applied again, right? In my opinion, the insights here are super applicable and in the stories and whenever we can pull out of this, like, do they just help folks sort of understand, like, well, why did that work, right?

One of the things I was very, very lucky to learn from some incredibly talented people at Salesforce, including folks like Peter Kastner, who went on to found Viva, is the aesthetics of building a platform as a kind of product concern, right? And Platform is such an overused term and maybe it's not even that helpful a word. But I think it is true that most of us are in some way thinking about how do we expose customization integration capability to our customers? And what are the kind of models and methods we use to do that? And how you choose to do that and ultimately kind of how good a platform you create and kind of the aesthetics that surround it is so, so important, right? Because those decisions are, one, very hard to change, and two, kind of very, very determinative of a lot of your success. And there was a lot that Salesforce got right in the early days of the platform. And this kind of idea of platform aesthetics, right? We have it as developers for different frameworks that we encounter. We could probably have a pretty robust discussion about the kind of aesthetics and decisions between a framework like Express versus a framework like Django, right? Like, we kind of understand that. And those are all examples of web frameworks. What we don't have as much collective experience or aesthetics around is kind of the enterprise application platform equivalent. But that is something we all are likely to have to work on, right? And we're all kind of facing in how do we think about exposing the right level of control to our customers without kind of overwhelming them or worse, kind of forcing yourself as the vendor into some kind of corner that is very difficult to extricate yourself from.

Right.

So I'm always, always interested to look at how different companies approach that. And it's just such an interesting time for platforms, this kind of platform revolution in general.

You kind of mentioned like platform aesthetics. Like what falls into that bucket when you talk about it?

A lot of it is how you think about the right, abstraction design, right? And abstractions are always a dangerous business because they always in some ways end up being leaky or they end up being, right, some kind of trade-off. But I'm a big believer that all platforms are really domain-specific. The word platform kind of conjures this use case neutrality, which is probably not that helpful, right? So, in practice, everything that we think about as a platform really does have some implicit kind of use case problem or market orientation, right? Even like a web framework like a Django or a Rails, these things are fundamentally about web apps. They're not about a whole other universe of other kinds of apps. And web apps themselves tend to be about creating customer experiences. So there's all kinds of expectations and ideas that are kind of implicitly inside of these frameworks. And if you then kind of have that view of a platform, you can say, okay, well, What is this platform trying to solve? Is it something around application deployment? Is it a CI/CD thing? Is it something to help a company do shipping better? Whatever it is, right, there tends to be some constraints around it. And then it's okay, well, what's the right way of kind of exposing control? What's the right way of articulating it, right? What's a well-designed set of Legos for this task versus, you know, something that's gonna be completely wonky and not have that right blend of control and abstraction. I wanna be able to do the things I wanna be able to do easily, but I don't want to be able to get myself into a corner or have to, you know, navigate some incredibly perilous technical terrain in order to be successful. If that were the case, right, then as a user of your system, Right? If the likelihood of my success is really poor because what you've exposed is the controls, you know, to use a— if I had to write WebAssembly, right? That would be pretty rough. But if you can articulate it well, it becomes super, super interesting. I'll use an example just to make it a little more concrete. Even if you look at something like AWS as a platform, right? Increasingly, and this started happening a couple years ago, this is nothing necessarily new, but you could start to think about AWS not as just a set of discrete services, but in fact, a set of discrete services that kind of emitted events in a common way and then had a programming model in the form of Lambda. And that's one of the things that I think people miss about in the broader discussion about serverless or Lambda or whatever, is it's super interesting as a way of programming AWS. Right. Right, versus as a way of creating— and that itself is like, okay, right, that's kind of thinking about it as a kind of domain platform problem versus like, it's just an arbitrary compute thing. And as you know, you can do some really, really fascinating things. And that's just, again, one very simple example, right? But imagine if instead of having Lambda, you had to fire up an app server or run a set of EC2 clusters, whatever it were, just to kind of respond to events inside of the AWS system. That would be a whole lot harder. Not that Lambda doesn't have its issues, but again, hopefully just one example that helps paint the picture.

Yeah, yeah. And to your point there, I think like, We talk about serverless and functions as a service, and the key thing that is so important is that eventing framework, right? It's all these different events that are happening that you're able to then respond to. That is it.

I'm gonna take a wild aside here. One of the more interesting things that's happening in enterprise platforms in general, or really just in application platforms in general, is the shift from what is kind of a CRUD traditional, right, database select star orientation to an event orientation. And right, that is, we are just at the, early days of that happening. And I think that is gonna be super, super impactful for what happens with enterprise applications in general.

And like, how do you mean? Like, where do you think it plays out? Or what are the implications? Like, what's the—

Sure. At a minimum, there are implications for how you're ultimately gonna comprise kind of larger architectures of multiple applications. And this has been, you know, a little bit of a distributed computing dream for a while, but I do think it's on the cusp of becoming more real. If you think about the standard model of let me pull some data here, let me push some data there, kind of very SQL CRUD-y kind of stuff, right? That has a certain, maybe I'll surround the whole thing with some kind of workflow wrapper, right? That's kind of the model that we've been in. When you think about systems kind of all emitting events, what you ultimately are able to do is decouple the customization and integration models for these applications from the applications themselves. So if historically the way that I customized Salesforce, to use a Salesforce-specific example, the way I added some business logic to Salesforce is I did it by writing some Apex, or in the way maybe I added some business logic to Slack was by doing X. Slack is probably a poor example because it's a newer company, but Workday did it Y, CircleCI did it with Z. We can now start to think about that being decomposed and because of these event architectures, and instead allowing all of those systems to have more kind of common customization integration components. And that's gonna have huge implications for kind of how this whole enterprise application ecosystem is gonna develop, and hopefully it will help it become less monolithic and more easily heterogeneous, which is I think what we want as developers, 'cause we want, you know, to be able to throw more and different stuff into the mix. And be able to use Redshift here and Lambda there or whatever else there, you know, as opposed to having to think about these applications as being more kind of vertically integrated and kind of silos into themselves.

And so, if we think about that sort of eventing within applications, for some reason my mind kind of jumped to the webhook as an example. Is that sort of like a—

Yeah, for sure.

Yeah, okay.

I'll reference a talk that I did at SaaSter, 2 or 3 years ago. And the point I was trying to make in the presentation was basically as platforms change and evolve, massive opportunities for new applications are created. And given the domain of this, I think that's broadly true. I think it's specifically true for enterprise applications, right? We are all now kind of broadly familiar with the idea of the shift of client-server to SaaS was a big platform shift and As a result of that, right, that completely turned over the set of incumbent vendors, right? Completely reorganized the entire market, created trillions of dollars of new market opportunity, right? Was a whole big kind of reset and recycle on the space. Well, there was an era before that, right? Mainframe, mainframe to client-server was kind of a similar thing. And we're now, right, that's not going to stop happening.

Yeah, sure.

So the point is, as kind of product people or in general, as kind of people involved in the space, you know, platform change is destiny. So what is happening in platform and technology change that's going to drive these kind of massive new windows of opportunity? And that's something I'm keenly interested in, because history tells us that that's how these massive new kind of opportunity categories are going to be created. And that's kind of— I just use eventing as kind of one small example in that broader mix. I'll jump a little bit to the punchline. There's an idea of cloud platforms that some people in the industry are incented to promote, which is to think of them as kind of neutral core infrastructure players, right? The mental model is this is a data center that exists somewhere else and it's just a bunch of metal and so be it. As opposed to thinking about them as platforms the way you think about Express or Django or again, to use, or Rails, to use that metaphor. And I think we are at the earliest days of the implications of these cloud platforms impacting the structure and nature of the enterprise software market. Mm-hmm. Right? My core belief is that cloud platforms will be as impactful to the kind of broader enterprise app ecosystem as the introduction of multi-tenancy and kind of Cloud V1, if you will, was in relationship to client-server. Now, and you can say, well, wait, it's just servers in somebody else's room, right? Well, we could have said the same thing, right? That was the argument about SaaS and multi-tenancy. It's like, well, it's just your data center, mine. What's the difference? And of course, the difference is that these are fundamentally different platforms, different concepts and abstractions. And there ultimately will be a divergence between what are the current SaaS multi-tenant architectures and the next generation of enterprise app architectures that are going to arrive. Genuinely from a cloud platform native way.

Yeah.

I think this is where you and I actually probably— that was the root of part of our original disagreement, probably because, you know, I know you have some interest in making all that happen on-prem. That's at the core of why I think that on-prem and cloud are fundamentally divergent, is that you can't assume any long-term commonality between what is the kind of baseline capabilities you can rely on on-prem versus cloud, right? They're just gonna diverge. It's like saying that whatever's in my garage is ultimately gonna be equivalent to what SpaceX has at their launch site. It's just like, they're on just different paths and they're gonna end up diverging.

Interesting, but do you believe that there will be commonality between the different hypercloud providers?

Maybe a controversial statement. I think the idea of commonality is both more sold and less important than it generally will be, right? Because what does commonality kind of really mean? It means we're gonna take the containers and run them, you know, I can orchestrate a bunch of containers in Kubernetes in some kind of common way. And like, I'm all for that, that's great, God bless. But there's so much more involved in making all those things work. And that's just within the container domain, right? How I manage security policies, how I manage network policies, right? How I manage access controls, all these things are are incredibly important and are gonna be virtually impossible to, nor should we even attempt to kind of generalize. But even that, it's, that's just the container orchestration part is a tiny piece of the broader puzzle, right? Of all the systems and services I need for databases or data movement, all those kinds of things. And the idea that we're just all gonna operate on some core base set of common primitives is ultimately, if nothing else, depressing. Because that would imply that there's going to be so little innovation that the only things that we can use are things that are these kind of lowest common denominator, broadly homogenized kind of tools and services. I'm not in any way saying that the cloud providers are going to kind of lock it up. And, you know, we can look at the Snowflakes of the world, and that's kind of powerful evidence otherwise. But I do think this idea of your workload should be portable across clouds is, an idea that's only convenient or useful for the vendors that support it.

Interesting. I guess my like small caveat there would just be, I think it's less depressing if you imagine these services exist. It's just that like they're less human-oriented and they're more like automated, right? And so that the portability comes through the automation rather than through the like manual operations.

I feel like we're gonna start having our argument again.

Yeah, yeah, we'll pause that for later. I definitely appreciate your perspective on this and everything else you talk about.

So like, and, you know, my view is a, um, a luxurious, principled, long-term one. It, you know, kind of ignores the reality of all the hard things they need to get done between here and there. But again, the broader point is I'm looking for the very, very kind of long-term trends and cycles. Sure. And that does not by any means mean that there aren't a whole bunch of different sets of opportunities in between.

Yeah, I mean, and I do, like, generally I think that Big companies are founded on these massive platform shifts and paradigm shifts. And so like you find those and, you know, we all sort of bet on which ones we think are the important ones and then we build companies around them and that's sort of, or we, you know, work for companies that choose those and that's kind of how we decide, right? We kind of get skin in the game.

Yeah, and I think you and I could probably agree that Kubernetes is a version of one of those and that is an important platform shift, much as, you know, the emergence of, J2EE app servers in the '90s was an important shift. I would probably just say yes and more. Sure. There are even kind of bigger implications over the horizon.

It's interesting. I mean, it's always, you know, so personally, I get a little bit focused on the thing that I think is, you know, is really right there. But it's great to sort of pull back and look for those other paradigm shifts to make sure that you don't miss, you know, the next generation of whatever's coming down the pipe. So. It's always good to have that perspective. Let's talk a little bit about what you did at Heroku too, 'cause I think this is a really interesting piece, 'cause you basically were the CEO of Heroku for several years, right? And so kind of where was Heroku when you took it over, and sort of where did it end up?

Sure, so I joined Heroku in 2013 via acquisition of a company I'd started called Cloud Connect, a heavy-bit company that is in the customer data integration space. I wasn't smart enough to call it a CDP. That's probably what you would call it today. It did some important things in terms of being able to bring CRM data into a kind of traditional modern development environment in Postgres in particular. So there's a lot of strategic value for Heroku in that. And after I was at Heroku for about a year, year and a half, took over the rest of the organization. And I mean, Heroku, it was an amazing, amazing opportunity. It was an amazing ride. And—

So wait, Cloud Connect was acquired by— Heroku or Salesforce, or what was the?

In 2013, Heroku had already been acquired by Salesforce, but was an independent entity.

Okay, got it, okay.

That's no longer the case, but at the time it was. So ultimately it's Salesforce, but effectively it was Heroku.

Got it. And then what year did Heroku get acquired?

Heroku was acquired in 2011.

Okay, so they'd been around for a little bit, like, and then they acquired you as part of this?

Yep. Cool, great. And among the many, many things that I had the privilege to learn there, Probably the most important and the thing that I think is most relevant to companies today is thinking about the relationship between bottoms-up and enterprise go-to-market.

Sure.

And I think this was more true then than it is now, but this is still certainly— I think how to manage and think about your company's go-to-market is the number one issue that most organizations face. And at least maybe it's biased. I work with a whole bunch of different startups now. It's certainly the topic that I see that kind of vexes most organizations. And it's because unlike previous eras, we now live in a world of really what is kind of multimodal go-to-markets, right? It was hard, it's hard enough to be good at one mode of go-to-market. It's hard enough to know how to do enterprise sales. It's hard enough to know how to do self-serve. It's hard enough how to just get free adoption of something. And effectively, at least for developer companies, likely for most enterprise SaaS companies as well, companies need to be good at all three of those things. And that is a very, very difficult thing to do. And it's, we don't have a lot of kind of frameworks or guideposts to think about that. And how companies kind of navigate and negotiate that is a huge challenge. Rewind to 2013, and I would say this is broadly true of the whole class of companies that Heroku was part of, which, you know, think about kind of the '08, '09, Y Combinator, Heroku, GitHub, that whole kind of universe of companies. I'd also previously worked at Dropbox. I kind of broadly put that in the mix. And they were all fascinating companies, because they all had this incredible, innovative, bottoms-up, kind of freemium-style adoption and go-to-market, which was incredibly innovative at the time, right? The SaaS world before was defined by kind of free trial. It was a whole, it was only with this kind of '08, generation, you know, or 2010 to keep it a round number generation that we started really having the idea of freemium, which was an entirely new go-to-market model. Incredibly interesting. And the opportunity, and this was apparent to me even back then, was if we can convert ultimately, right, those free customers, not only into paid individuals, not only into paid teams, but ultimately into larger enterprise accounts, that could radically impact the economics of customer acquisition.

Yeah, sure.

And in the process, kind of change the entire model, 'cause of course customer acquisition costs are not only really high typically, but also it's just painful, right? Just kind of spinning up that whole machine. So the fascinating thing for me about Heroku was I was in the position to kind of put some of those ideas to test really for the first time. So when I started in 2013, about 95% of Heroku's business was just kind of online credit card swipe.

Sure.

And when I left—

Couple developers.

Yep. Yeah. When I left in 2018, it was about 50/50 online enterprise, and the business had roughly grown 10x in that period of time. And I was very lucky to be able to kind of put some of those ideas to test and kind of learn how to hopefully make some of those things work. And ultimately, how to connect a, in this case, developer bottoms-up premium business with an enterprise, you know, large deal business in a way that was kind of mutually beneficial and complementary versus adversarial and destructive. Because again, rewinding to 2010, on one hand, all these companies got this, got this incredibly important thing right of freemium. But on the other hand, most of them developed this internal psychology that doing anything enterprise was completely antithetical to your ability to be successful. This idea that these two things were in total opposition, as opposed to in fact, they're in total harmony. Right. And that is, I think, one of the most important things for developer-facing companies to kind of understand and work out. And it's not easy. but there's enough kind of frameworks and patterns out there now that you can kind of learn how to navigate that. But as you know, and I'm sure you saw firsthand, it's hard to overstate how deeply ingrained that psychology was. And, you know, we had to go through a big organizational transformation to kind of shake free of it.

Yeah, I think that, you know, definitely true at GitHub, if you remember at that time.

For sure, for sure.

Hostile enterprise sales.

And I should say, as full disclosure, I was lucky enough to do a little bit of consulting work for GitHub. After the acquisition, so, and I'm lucky to have a lot of friends there, and I'm super impressed with what they're doing. If you look at Heroku, if you look at GitHub, you know, there are some pretty core patterns of organizational dysfunction you can find. And it's, I'm lucky that I've now seen enough different companies that hopefully you can kind of spot it in the distance to avoid it. But it was certainly true of Heroku, and it was certainly true of GitHub. I ask myself this question a lot. Why in these organizations— and these aren't the only two for sure— but why in these organizations was the enterprise viewed with such skepticism, if not outright aversion? And it's not because these aren't smart people. And like most things, I have a long answer for that.

So let's hear it.

This is where I kind of ended up, and this is kind of one of my framework pieces. So what What I think people understandably don't recognize is that go-to-market evolves at a similar, if not faster pace than even the core technologies. We're not building apps the same way that we did 20 years ago, but the mental model that we carry around about how we sell and market software is largely grounded in many decades prior. And in fact, there have been huge— kind of revolutions in go-to-market that are kind of clearly identifiable and segmented. And I think the kind of cognitive error that organizations fall into, very understandably, and I, again, I lived it myself, is that they kind of misapply the framework of one era to the era that they're in. And I'll give you specifics. So if we kind of decompose the entire history of enterprise technology go-to-market, kind of breaks down in roughly modern eras into 3 eras, right? '90s, aughts, and kind of 2010s. In the '90s, selling happened, what we kind of think about as Sales 1.0, right? A sale happened between a sales rep and a CIO on a golf course with somebody wearing Gucci shoes. You know, us as technologists are completely averse to that, right? Why? Because there's an asymmetry between the buyer and the user, right? It has nothing to do with how good the product is. It has nothing to do with like what the capabilities are or empathy for the experience. It just has to do with, with, you know, some schmoozy golf thing, which we're developers, we don't play golf. So, you know, like, again, the whole thing's disgusting, right? And that was the '90s, right? And that's pretty distasteful. But that's the mental model that a lot of us still carry around in our head.

Yeah.

And in fact, we're two generations away from that. What happened in the aughts with the development of SaaS is SaaS not only brought an entirely different technology model, it brought an entirely different go-to-market model. Because your entire provisioning cost went from thousands, tens of thousands, hundreds of thousands of dollars to a marginal cost of effectively zero, you could now do something called trials. We forget that the idea of having a trial of an enterprise application in 2003 was a revolution.

Hmm, interesting.

You think about it, like the way it used to work is you would go through some big long sales process, and at the end you'd get a CD, and then a year later you'd have a system that was up and running. And, you know, there's a 12-month lag on a good day between your purchase process and you actually experiencing the thing, right? Trial inverted that. The other thing that happened, which was totally revolutionary and under— kind of considered, is in the Sales 1.0 era, there was a kind of a strict separation between selling to SMB and selling to enterprise. Because of those channels were very different, right? If you were selling to SMBs, you couldn't afford to go to a golf course.

Right.

So you had to have go through the channel, which at the time meant being on the shelf at CompUSA or whatever the case was. In Sales 2.0, right, the SaaS era, you could do, it was really co-emergent with search, right? Now I could do a Google search, do a paid ad for whatever, CRM, click on a link, go to a trial, I now have a lead. Radically different access to a market. And this is why when people talk about selling to SMB versus enterprise, it makes my skin crawl. Because what they're talking about is Sales 1.0, and that completely doesn't apply in the modern go-to-market era. So, anyway, so that was Sales 2.0. And Sales 2.0, if you think about selling to the CIO in 1.0, you were selling to the department first in 2.0, right? So you're down one notch in where you start in the organizational hierarchy. And of course, the other thing that was completely radical was now a department head, a team leader, could make an application or technology decision because they didn't have to drag a bunch of technology considerations, i.e., deployment, with them. So all these things, radical, radical implications for go-to-market. So now we're right in the SaaS era. And that's where most people, I think, kind of collectively our consciousness kind of ends. But the thing that happened was, over the past 10 years, an entirely new model, right? Sales 3.0 developed. And just kind of rinse and repeat. Instead of selling to the team or department, go one more level, one more notch down, you're selling to the individual. And by selling, you're not selling, what you're trying to do is get freemium adoption. Yeah. Right? And so in SaaS 2.0, your model was get a bunch of team use and then try and notch it up to the enterprise via kind of seed and grow, which was kind of the famous Salesforce motion. In Sales 3.0, start with the user. You're driving adoption, right? You're not really typically trying to monetize that. Then you're trying to notch up to team, and you're trying to notch up again to enterprise. And these things are all entirely connected. And if you think about it in that context, there are lots of implications. One is, don't be afraid because you're putting your customers on a journey. You're not saying we're just going to skip to having golf course reps. And among other implications, be mindful because you now in your fully kind of bloomed organization are going to effectively have these 3 discrete but connected go-to-market motions. One for free, one for team, one for enterprise. And that's the model. Aligning to that model is where so many, so many startups go south. Because the typical mode is you're living down in Sales 3.0 freeland, right? You've got some developer project, it's super successful, people are using it, you're starting to think about monetization. And then like a bunch of VCs or board members or people like me, like come and talk to you. And all of a sudden you built an independent Sales 1.0 golf course serving organization on the top of that. And then the whole thing just spirals out of control and goes south.

Sure.

Right? And that's when you have a bad enterprise go-to-market experience. And so how you kind of balance that, how you kind of build your progression from free to team to enterprise, kind of broadly I think about this as Goldilocks go-to-market. Because the conversation I'm always having with companies is, you know, when are the right times to invest at each of those breakpoints? When is the right time to move from free to team, which really means building kind of an online self-serve function? When is the right time to go from team to enterprise? And kind of same set of questions, right? That's an incredibly expensive and kind of organizationally taxing move. And if you do it at the right time with kind of the right groundswell of demand from your existing team customers, it'll be smooth and easy and you're off to the races. And I was very, very, very lucky that we were kind of able to orchestrate that transition at Heroku. And that's how we ultimately kind of built that enterprise business. But it can really, really be tricky.

And just for context, I would assume that that like this same model sort of also applies to like open source companies as well, right?

For sure.

Yeah.

In a way, open source companies were a bit more bimodal. So there was an open source model because open source was really kind of independent from cloud historically. It's only recently those things have started to reconcile where you would have a bunch of free adoption and then at the other end of the spectrum, you'd have a bunch of enterprise adoption. You didn't have kind of that team or self-service motion in between. And what that led to was a bunch of overrotation to enterprise. And this is the situation that a lot of open source companies find themselves in today. They've got a bunch of open source community users that they sometimes don't entirely understand why they have. And then they have, you know, a very small number of very large enterprise accounts. And they've organized their entire organizations around that kind of bimodal model. Where, you know, that's gonna affect how you sell, it's gonna affect what products you build, it's gonna affect your pricing, it's gonna impact everything. And in today's world, if you don't have a more gradual ramp, if you don't have a way of taking a developer, individual developer to a team to an enterprise, you're just gonna miss out because it's so damn expensive to kind of go for that enterprise first sale. If you don't have any existing support inside of the organization, and you're just gonna like try and force a bunch of demand for this thing in there or awareness for it, I mean, Good luck. Incredibly expensive. And that's again, very, very kind of common anti-pattern, if you will.

And so, like from a product and technology perspective, if I'm trying to go from free to team to enterprise, you know, so when you kind of said something funny, like which was makes your skin crawl when you talk about SMB and enterprise.

Yes.

Like why is that?

Because selling to an SMB is exactly the same to selling to a department within an enterprise.

Okay, so—

From a sales motion and value prop point of view, those are identical. So you are hitting the SMB market by virtue of hitting the team market.

Got it.

It's only that those SMB customers will tap out at some point versus enterprise customers will be further opportunity for growth. But if you think about them as separate concerns, you're toast.

Got it, okay. So you should probably have an understanding that like some of them are gonna tap out, right? Yes, that's fine. And that like, that's the highest tier. But just like, so some enterprise teams will tap out as well, right? And they'll just stay at the Team edition and they won't ever really go up to Enterprise.

Sure. And you know, the model depends on some small, it's very Pareto, some small percent of customers moving from that team level to that enterprise level. But you only need, you know, you're working off of an incredibly large free base. You get to a smaller team base and you get to a smaller on top of that enterprise base. But the dollar amounts, you know, are 10x+ of what you're getting at the team level, because the kinds of problems that you're solving are so much more valuable. I'll take another aside to kind of go a little bit layer deeper on, again, what I kind of think about this free team enterprise model or individual team enterprise model, or sometimes I think about it as kind of the 1-2-3 model. The other pattern that emerges is that the value proposition of your product changes at each one of these tiers in an incredibly predictable way.

Really?

Yes. And when I talk to startups, I kind of go in with this framework as my default. And I'm open to, you know, sometimes— 9 times out of 10, it actually holds up, which is for individual, the value proposition is creation. For team, it's collaboration. And for enterprise, it's compliance. Mm. And in broad terms, I kind of think that holds as a metaphor. I think that's true of products like Heroku and GitHub. I think it's true of products like Dropbox. I think it's true of even things like AWS. If you think about like kind of individual developer, right? That's a real creation act. Or even, you know, any number of the kind of creative tools that are emerging now. Sure.

You wanna be able to do it by yourself and—

Yeah, so that's creation act. Great. What is the value proposition on top of that? It's collaboration. Yeah. It's somehow I'm doing that in a team context. What makes GitHub so amazing? It's a team collaboration product. Like, that's solving an entirely different set of concerns. And then finally compliance. Often that has to do with strict traditional definitions of compliance like HIPAA, and that's really important. But it also can have a lot to do with just compliance in a little bit more holistic sense of, you know, integrating with whatever the ways in which an enterprise works from kind of a broader systems and business process point of view. And there's a tendency sometimes the further up the org chart we look to be less empathetic to solving those kinds of problems. And I would say that's kind of another one of these kind of organizational psychology things that I would try and disabuse people of. And it's because, again, we're carrying over that Sales 1.0 frame. We're like, if we— we can't solve problems for those people because they only care about what happens on a golf course. So let's not even try. What's the point?

That's the man.

Yeah. And like, I reject that wholeheartedly. The idea that as product people or entrepreneurs, that we are only capable of creating products and solving problems for individuals, individuals who ultimately look and behave like us. That's kind of what we're saying, right? Versus we can truly practice empathy and understand organizational problems and think about solutions for organizations that are going to behave in kind of different ways. That idea of organizational empathy is so important to really kind of opening up yourself to be able to solve those problems and reach those kinds of value propositions. I'll give you one of my favorite examples and I'll pick on GitHub because they know that I love them. When I was at Heroku, we were in the process of kind of adding some different compliance things to our own software engineering practices for our own regulatory concerns. Sure. And we were pretty appropriately, in a way that I was proud of, kind of light on prescriptive engineering tools and processes and all that kind of stuff. We tried to keep things as open as we could, but we did need to add some more kind of standardized issue tracking. And so we use GitHub. Great. Let's look at GitHub Issues. Will this do the trick? And of course it wouldn't. And this is now 2015, 2016. I'm not saying anything about current GitHub. Why did the GitHub Issues product suck so much?

Yeah.

It's because GitHub didn't behave in any more rigorous way. GitHub was building GitHub for GitHub. Because that was the length of their empathy. Therefore, they didn't need a better issues product. And you know, you've heard of Conway's Law, which is, right, that organizations ship their org chart. There's kind of a Conway's axiom, which is organizations are only capable of producing software that matches their own business processes. And if you are stuck in that, if you don't fight that the same way that you fight Conway's Law, you are gonna not be able to have the right kind of empathy and mindset to be able to solve higher value problems. And to say that you don't care about those problems because they're golf course problems is a total cop-out. That is just a cop-out, right? That's like an engineering saying, I don't care about the UI, get a smarter user, right? Total cop-out. So it's a pretty common anti-pattern as well.

That's really interesting. And so obviously from creation, like this to me feels like just the standard value and the core thing your product does. And then collaboration just being like add some type of team functionality and layering in and be able to invite and have some, like, you can do things together with people on your team, right? Is there anything else that you would add into that, like, sort of team in terms of the feature set?

I go deeper in thinking about the relationship between creation, collaboration, and compliance. Great. And it's one of the most beautiful and rewarding things that I see in a company or have had the opportunity to be part of is when you really develop this additional and distinct value proposition. And I'll give you one of my favorite recent examples from Heavybit. And my apologies to Edith if I get this wrong. But as I understand it, right, if you think about LaunchDarkly, kind of LaunchDarkly in the equivalent of kind of that individual mode, right? They solve an important kind of mechanical problem around feature flagging. It's like, okay, you know, this is a convenience, it's a productivity thing, it's helped me create this thing more easily. Look, that's great. But that's not that strategic, right? It's like, okay, that's cool. But like, how much value in the world can we ultimately create and capture doing that? Well, think about LaunchDarkly in team mode. What is LaunchDarkly really doing by providing the kind of capabilities and the feature flagging they're doing? Really what they're doing is creating a framework for product and engineering to think about feature delivery together, right? That is a business process problem. That is a business maturity problem. That is a digital transformation problem. to just, you know, say, oh, well, I can kind of share what I'm doing or provide visibility, that mode of collaboration. Yeah, but if you can find this kind of second order problem where now, right, I'm adding value to the organization by helping them be good at something that they weren't good at before. And in that mode of collaboration, then like, wow, right? And we had a similar thing at Heroku, right? People are familiar with the individual developer experience of Heroku. Gee, isn't that nice? I can push code that much easier and not worry about production. Like, yeah, that's unbelievably amazing. It was one of the more brilliant products ever created. But the team value proposition is really kind of distinct, right? Especially when you think about kind of modern Heroku and the pipeline capabilities and being able to organize all of your environments and how you as a team build software is an entirely different problem from how you as an individual build software.

Sure.

Which itself is a distinct problem from how you as an enterprise have a software creation capability, right? So, at Heroku, when I started, we had, you know, parts of the team's product. We certainly didn't have the enterprise product. And we didn't know what that enterprise product looked like.

Mm.

But I was pretty damn sure there was one out there. And it was a constant exercise in, you know, kind of that careful product listening to customers to really understand what the common patterns and problems were. That gave us the information to ultimately build those products. So I'm not in any way suggesting that you're starting off, you're in free mode, you know what that journey looks like. Absolutely not. In my experience, you only know as you kind of uncover it, but you have to have the intentionality of looking for it.

Okay, interesting. And so this is actually like somewhat contrary to like the, it's part of the thesis of Enterprise Ready, which is just that like, hey look, there's a set of enterprise features that everybody should add. In order to start selling in enterprise, right? You need single sign-on and role-based access control and auto-logging. You're saying that's probably all true, but there's also this thread that needs to come up from creation into collaboration and then into compliance. And it's not just like bolt on these features, but it's like really it's distinct for every product. Like find that thread and pull it all the way through.

The first feature of Heroku Enterprise, when we started it was all those things, SSO, RBACs, and those take up a lot of time. They're hard to build, right? And so I'm not discounting that.

Right.

That is the table stakes. But if you just take the value proposition that you have at team or at individual, in this case to build an enterprise product, and you say, okay, I'm just going to put our back around it, absolutely, that's where you start. Sure. And by having that, you then, that's the price of admission to start getting some enterprise-level adoption, to start having those discussions to really understand what the nature of the problem is that you're solving for your customer.

Okay.

So that is the starting point. That is by no means the finish line.

Yeah, yeah. So that's what, will get you in the room because they expect those things. And if you have that, then you maybe earn the right to actually understand what do they need you to solve even at a bigger, at a bigger problem.

Exactly.

Yeah.

And the conversations that we were ultimately privileged to be able to have at Heroku, you know, meeting with the CIO of a major pharmaceutical company. And they've got a problem. Which is an incredibly strategic problem, which the entire nature of their business is changing from ultimately creating what we think about as drugs to being really kind of in the holistic patient care business and being able to have a, a long-term relationship with a patient that is ultimately more kind of outcomes-driven. Radical transformation in their business that's being driven by 1,000 different things. What is the central way in which that's going to be enabled? It's going to be enabled via technology and applications and customer experience applications, all those kinds of things. Nothing more important and strategic to the business. How can a company like, and a product like Heroku Enterprise, in this case, help them with that transformation? Which, incredibly challenging. You're a 150-year-old company, you've got to be as good at building software as Amazon and Google are, literally, because they're getting into healthcare space.

Yeah.

That's a business problem, right? And how can you really kind of line up a set of capabilities that are going to really speak to that and address that in a way that's compelling for them. And guess what? You already have the individual user because you've been working on that for a decade. So they're only too happy. You already have the teams and you already know how to make that work because you already built that. Here you're just adding this on top and like, wow, the whole thing just comes together and sings. And it is going to be a far more successful solution for them than anything else they can look at, right? Who are we competing against then? We are competing against companies that only had that enterprise motion. They had no organizational support and the likelihood of actually being successful once the thing was purchased was pretty small because it was that traditional more sales, 1.0-y kind of model and mentality. So it can be really, really rewarding to solve those kinds of problems. And I'm trying to build kind of the appetite and interest within our collective entrepreneurs for doing that.

Yeah, I mean, I think that those problems, again, to your point, like you have to have that sort of empathy. And I actually explain it sometimes and say the empathy, it's not just for the like, manager or the executive, but it's actually like if you want the developer to be able to use the thing, you need to be able to give the organization the tools that they can use to adopt your product.

Totally. This is why the idea that enterprise is antithetical to developer is so mystifying.

Exactly.

Because it's like we want these people to be able to use the stuff at work. Can't we at least put the minimum stuff around it so they can safely bring it into the organization? Why does that freak us out.

Yeah, yeah. You know, one of the things that's interesting about this is when I think about organizations now, because like the freemium model introduces some really interesting challenges, and then you think about shadow IT and sort of these, you know, like exfiltration of data and things. So I think there's been some tightening around like, you know, the adoption. So like most financial services organizations can't adopt freemium, right? And my sort of takeaway for this is like, this is often why, like as a SaaS service, right? But this is often why they can adopt open source projects. And so I think this is part of the reason that open source has become such a like important part of enterprise go-to-market at the like highest levels.

I have agree with you and have disagree with you.

Great.

And I'm super long on open source. I personally invest a ton in open source. This is a moment for open source. That's never been more important for a whole bunch of reasons. That being said, I think even if you look at the most locked-down organizations, mm-hmm, you will see some introduction of freemium. And I emphasize that because I want people to have as kind of wide as possible an aperture in thinking about the difference between kind of that Sales 1.0 and Sales 3.0 versus what's really happening in the organization. So if I go into the most tightly regulated organization or— that's maybe setting myself up a little too hard. But let's say more traditional, old-school kind of company. I'm pretty sure I'm going to see iPhones. I'm pretty sure that, you know, I'm going to see some kind of work productivity happening on those phones in some shape or form. Right? You can't stop and you shouldn't stop. You know, there's obviously— that doesn't mean we should be ignoring any of the essential compliance regimes. At the same time, you know, picking up the phone and having a conversation on an iPhone that I pay for myself is a business activity. So I encourage kind of having a wider lens that is possible because it'll help you see where those opportunities for adoption at the individual level are happening.

Yeah, I guess, and to your point, there's also like people will adopt some software in their personal lives that they then want to see in their professional lives.

And I mean, I'll also— part of my pushback also comes from I've been doing cloud for 20 years. And as long as I've been doing cloud, there's always been, well, they'll never use it. Sure. Right? And it's funny because I have that conversation with new entrepreneurs and they're like, well, they said they'll never use it. I'm like, don't worry, they always say that, right? I understand it's new information for some people, but like, history is clear. And even in the past couple of years, as you've watched that curve accelerate, like the future of on-prem, Is not, again, I have a long-term view, but there's cloud-prem, that's a thing. I'm not, I'm trying to be a little more accommodating. You know, it's just, you can't beat history like that.

Yeah, I mean, there's a couple different things that I've been thinking about recently. Part of it is just, I think the relationship that companies have with their data is changing. And so sometimes now, because of just the zeitgeist, like people think about data privacy and data security in a different way than they did 5, 10 years ago. And I think that maybe because of that, organizations now see themselves, for a particular set of data, less as data owners for any data that they process, and more like data stewards or data custodians. And so, there's this inherent responsibility, and I think it's kind of an emerging thing that's happening, where organizations are like, they're fundamentally changing how they think about this additional data. And I think it's a combination of compliance from the GDPR, GDPR side, but it's also just like, it's like how we individually think about our data, right? And like data ownership. And I do think it's having impacts in the enterprise ecosystem.

Here's where you and I think at least one area where we will agree. The future of SaaS, I do not believe in the long term looks like multi-tenancy in the way that it does today, precisely for the reasons that you describe. I think we are going to enable a whole new world of security and compliance and data management controls. By introducing a new kind of quote-unquote SaaS architecture that does not resemble the Slacks and the Salesforces of today. So I completely agree with that.

Well, tell me more. How do you see that evolving?

I'm gonna make two points at once, and I'm gonna pivot to an incredibly controversial one just to keep things fun.

Perfect.

Okay. So one of the more interesting spaces in the universe right now is the database as a service space. So much happening, so fascinating, so transformative, right? Like, we are inning one and wow, is it getting crazy out there. And if you think about the tenancy model for Heroku Postgres or RDS, right? Like, my control over that data, my ownership of the data in that thing is lock solid comprehensive. I can bring my own encryption. I have even a physical, logical understanding of broadly what happens with the data. I feel warm and fuzzy about that architectural pattern and the kind of segmentation of my information with others. And it is great. And I get all the wonderful features of Postgres. Life's good. From a tenancy point of view, right? That's not multi-tenant in the way that we think about a Slack or Salesforce, right? It's single tenant, to me, the user of that system. From Amazon or Heroku's point of view, it's not single tenant. They're not like manually operating a bunch of those boxes. They have these incredibly sophisticated control planes, which I know because I work with some incredibly brilliant people who wrote them, right, that manage these incredibly complex fleets of services. If you think container orchestration is hard, think about managing active live stateful databases, millions at a time. And then applying Heartbleed patch to all of them, right? Like, these are incredibly complicated problems. These control planes are nuts in what they can do. Think about the control plane now behind something like Aurora. I do one Postgres write and my data gets sent to 3 different data centers, right? These are incredibly sophisticated pieces of software, which leads me to 2 unrelated, one controversial points. One, that is a model broadly for how you can think about how enterprise applications and tenancy can work. That's different than multi-tenancy. But it's also not single tenancy.

Sure.

It's something new and different. Well, that's one. Two is, when people tell me about Amazon just taking open source software and like extracting the value, that is, it completely misses the point, which is look at the control plane. The control plane is where the value is. And shame on you. For not giving the appropriate technical deference and respect to the people who are creating that. And as a result of that, creating more value for your entire open source ecosystem. I love Postgres. I think Postgres is amazing. Postgres is a better product for the fact, and is a better ecosystem, and it's a whole better thing by virtue of the fact that there are services like RDS. I'm not intimately familiar with all of, all the cloud players' policies. I don't wanna speak outta school for, I'm sure, things that have happened that are good or bad. But the idea that somehow companies are taking open source software and just, you know, reprinting it without any additional value add, that is the frame that I reject. So that's my controversial statement.

No, that's really great. And actually, it brings me to this interesting piece, which what I've seen in the database as a service ecosystem over the last 6 months, maybe a year, is actually the sometimes open sourcing, but generally the delivery of those control planes, right? And then in the Kubernetes ecosystem, we think about it as it's the operator frameworks and it's these, you know, it's this idea of operators that are basically taking the common actions that you would use to operate and scale these applications and then baking it into and kind of codifying it, right? And then that sort of control plane gets used to create the instances of the actual databases. You know, and we're seeing that more and more becoming like a very popular pattern.

Yeah, and isn't it fascinating? And I'm a control plane guy, right? So like, I naturally wanna see the world that way. But to think about Kubernetes potentially as a little bit more of an abstract control plane rather than just a container orchestration thing. Which when you look at it that way, you can say, wow, isn't it great that we now have open source successful control planes? You can think about it in terms of like really going meta, right? And that control planes are the app servers of the future. Right, right. Because it's all about like this whole next level of abstraction. And you can also probably argue that there's not going to be one and that we should expect to see kind of innovation there. But that lens of Thinking about the control plane as a key fulcrum of value.

Yeah.

I think that's something that is not in the consciousness.

You're right. It's not acknowledged in the license debate and everything else. It's like, you know, oh, they took the thing and they ran it. It's like, no, they built the control plane around it. They built this.

Yeah. And even beyond the whole open source thing, which I'm just saying to be a little controversial and have fun, the role of these projects and also to maybe be controversial in a different way. The idea that Kubernetes as a control plane will accommodate all the use cases, right? I clearly don't believe that. Because there's just never been— back to our early discussion of platforms. See, I'm trying to tie it back. The idea that any platform can be both useful for a domain and generic to helpfully facilitate all domains is a contradiction in terms. So by definition, right, if it's gonna work for something, it has to not work for some other things.

But this is where the Kubernetes folks will tell you that Kubernetes is not a platform, it's a platform for building platforms. Which is like this sort of meta level. And it's why I think the most powerful, and this is kind of the operator thing, is like the most powerful thing about operators is it's for extending the Kubernetes API, right? So you're taking—

Platform for building platforms.

Yeah, that's what it is.

Did they get that out of like some J2EE, JSP document or something? I don't know. I mean, come on. I want a platform for building platforms too. Like what a classic. I could not disagree with any framing of a platform more, right? Because the whole idea is that, my whole idea is that platforms are domain specific. At some point, what are we creating, Turing machines? Like, what's going on here?

Yeah, I mean, the thing that I believe to be true is that—

Particularly— Here's where that argument ends. Okay. That argument ends with, if you just do it our way, then it'll work, right?

Well, I think that, I talk about Kubernetes as the patterns and primitives of reliability, right? And I say that generally, we have in the industry now a pretty robust number of security primitives, right? Like if you wrote your own encryption algorithm, people would be like, why did you do that? And so I think with Kubernetes, we're hitting this point with reliability. We now have these reliability primitives and all the stuff that happened with like Mesos and Docker, you know, and Tupperware and Peloton, all these things are being like reintroduced into like a, you know, sort of a best practices for reliability. And that's kind of coming through with Kubernetes.

And I'm pro-Kubernetes, don't get me wrong. I just think as an industry, we're a little bit over-rotated to it and that we should expect that stuff's gonna happen.

Well, that's because it's the greatest thing in the world, okay? End of podcast. No, I'm just kidding.

I encourage all Kubernetes people to help me get more religion. Clearly I need it.

Okay, so like, let's talk a little bit about what you've been doing then after Heroku. It's like you've been working with a bunch of companies, right? And really helping people understand sort of go-to-market. And one of the things I asked you about, and I think you gave me some great advice, is like, I'm thinking about hiring executives, right? And what should I look for? What are the things that I should pull in? Particularly for like really great go-to-market executives that are gonna help, you know, a company like Replicated, which, you know, we're trying to hit, we finally are really about to scale. And so what are the key things that you look for when you're hiring really great leaders into your company?

Yeah, hiring is obviously, is tough and there's a whole thing, but I'll happily share kind of some of what I've learned. I'm working on building go-to-market organizations, which is what I spend a lot of time working with a whole bunch of different startups now. On, and I can empathize with how mysterious and overwhelming and kind of hard to parse a space of marketing and salespeople it is when you're sitting, you know, having built some product and you're largely kind of an engineering and product organization and how challenging that can be. And the main thing I would kind of advise is intentionality. And what I mean by that is going back to kind of how I was thinking about before, or saying before, right? Okay, if you have this kind of 1-2-3 model, free, team, enterprise, what of those problems are you trying to solve? And in very specific terms, I think the likely case that companies encounter is they have, and this isn't, you know, there are many, many exceptions to this rule, but broadly speaking, you've got a lot of free developer adoption. Okay, what's next? And well, it's to build the teams piece, which typically means to build a self-serve online business. So what are the two anti-patterns that kind of typically arrive? One is that you hire a marketing person that comes from Sales 2.0. Most marketing people out there were trained in Sales 2.0. Not 1.0, 2.0, right? Not Sales 3.0. Not that many of them exist. And what that means is the way they're used to doing customer acquisition is through paid demand gen, lead capture, white papers, stuff like that. Tends to be kind of very gated content heavy, all that kind of stuff. And there's a role for that in all organizations. There's a time when all companies need that. But if that's kind of your first marketing hire, or even your kind of dominant, you know, you're bringing in that kind of person into an organization that's going from free to team, that's a total mismatch, right? Because your job as a Sales 3.0 company is to migrate your customers from free to team. That's a conversion exercise. That's marketing to your existing install base and customers. That's not a traditional lead gen capture job. And the punchline being, it is about those framings, and it is about those kind of modes. And the biggest mistake you can get is putting somebody who's in the wrong mode into, right, having a mode mismatch. Because it's so hard to detect, right? You just end up, people go about, they drop in, they start doing their things, they start doing their tactics. You don't know that it's not working until you've missed like 2 quarters, right? And you have all this friction, you don't know what the hell's going on, you're like, well, I don't trust marketers 'cause I'm an engineer, but really I should counter that feeling and like, it's all confusing inside. And so it's a really kind of tough failure mode to detect, which is why it's just so important in the beginning to be intentional. And you can find people from the 2.0 world who are like, yes, I'm ready to make this move, I wanna learn about these things, I have the right background and skills to think about this, OK, great. But just be really, really intentional. There is a company I'm working with now, and I would just for hours talk with the CEO about this. I would say, what is the theory of your business? Explain to me the theory of your business. Because if you do not have a theory of your business, I don't know what you're attempting to align your organization around. And the theory of the business is basically, where do your customers come from, right? What is the entire holistic journey from, from the minute somebody hears about you the first time to a full-fledged— and this is your goal— enterprise customer that's paying you $1 million a year. You have to have some theory about how that works. It doesn't even have to be right. But if you don't even have a theory, then you're just throwing shit against the wall, right? And that is the common case, is you don't have a theory of the business. You've hired a bunch of people. They're just doing what they did at their last job. You have predictable chaos and predictable CEO heartburn about why my enterprise journey is going so poorly. So think about that. Have that discussion with your board, with your company, with your friends, and think about what that means for you, and then match your hiring plan to that. Better to get that intentionally wrong than to not have it at all. Because it's that not having it all, like, just chaos case, that is so spiritually and financially draining for an organization.

And so how would someone go about trying to sort of uncover their theory of their business, right? Like what's the exercise that you would suggest that they like, the questions that they should ask themselves and look at?

At the simplest level, it should be pretty simple, which is to overuse a phrase, you know, what's the customer journey holistically? The simplest customer journey you can imagine, which is a little clichéd but okay, right? I'm gonna write a really cool open source thing. I'm gonna get a bunch of notice about it from great content around it that I get to the front page of Hacker News. That's gonna drive a bunch of downloads. I'm gonna have an email capture or at least some value-add email submission thing to actually have a way of communicating with these people. I'm going to create a Teams product to convert them to that has this distinct value proposition from the free thing, and I'm going to drive them to a self-service form where it costs $20 and there's a credit card to get them to do the thing. And my expectation is I'm gonna get a million people to give me their email address and I'm gonna convert 10% of them and that's gonna be— I mean, it doesn't have to be right. Yeah. It's much more important that it's holistically plausible than it is correct. 'Cause the whole thing is you're gonna constantly learn and iterate and like, like dry, but at least you have some. If you don't have that framework or just base set of expectations, what's the other case? The other case is you bring in a marketing person and you bring in a salesperson. The salesperson is off trying to make golf dates because they're a Sales 1.0 person and that's what they did in their last company to be successful. And then your marketing person is off in Sales 2.0 land, you know, doing gated content or, you know, some random events to do lead gen there. Well, okay. None of those things are aligned with a holistic understanding of your customer journey, and they're certainly not aligned with where you as a developer-facing company are starting from. And then the problems start, right? Because your salesperson is gonna start crapping on your marketing person because they're not delivering these hand-wrapped leads that are ready for golf dates. And they're now, you as the CEO are now managing the fact that you've got this like, tentious relationship, tenuous relationship. Then you fire your CMO because your salesperson says they're not working. And now you're like, you've lost 7 months and a whole bunch of time and money, and you're having to reboot that whole thing. And that's why these executives fail so frequently, is because there just isn't a framework for them to plug into.

It's like when you were CEO at Heroku, you were like, you were thinking through what's our theory of the business, and like you were sharing this with the team and like you were iterating on it every—

Absolutely.

Yeah, okay, interesting.

Absolutely. Most of what I know about all of this came from the work that we did as a team, and I was very lucky to have a lot of incredibly talented people helping me with, basically build that 1-2-3 model at Heroku.

Okay.

And it's a whole art. Just like Sales 1.0 is art, Sales 2.0 is its own thing. Sales 3.0, we could do an entire podcast just about that. How you do your customer data infrastructure. How you manage the transition states between free and self-serve. How you structure a sales organization for self-serve versus how you do it for enterprise. Right, how you do comp for those things. There's a million, pieces to this model. But the first thing is to understand that you're in that model versus in one of these other modes. So you have the kind of clarity and intentionality to kind of build it the right way and get everybody aligned. Because you're going to get a whole bunch of people aligned to do this thing, right? Even if you have it in your head, you've got to get your whole organization along with you. And I think the default case, at least most of the CEOs I talk to, is to be frustrated. Is to be frustrated with their go-to-market because they're like, one, it's stressful, and two, the teams aren't getting along and they don't seem to be, they're grinding gears and nobody's happy, right? Sales isn't happy with marketing and vice versa. You're happy with neither of them, right? It's kind of a bad time. So how do you avoid being in that state? It's okay, well, you have to be really, really intentional about thinking about these frameworks.

It's interesting when you think about sort of the model you talk about, you know, 1, 2, 3. Do you think it's possible people today to do a pure top-down enterprise sale?

Absolutely.

Okay. 'Cause that's not 123.

No, it's not at all. We're talking primarily about developer-facing, freemium, bottoms-up startups.

Okay.

I do think that that is the default case. I think that's certainly the case for most of the Heavybit community. But by all means, you can do traditional top-down. And for some industries, it's required.

Has it changed in the last 10 years? Like, has that model changed? Is it still—

Honestly? I don't think so.

Interesting.

I think the way that you do it, and I, you know, I see some of these companies, it's very targeted, you know, CEO dinners, lots of kind of field marketing, you know, executive engagement. I think, you know, in like highly specialized verticals, that would be common. Well, here's a classic example, is like an OEM sale. So let's say we're a self-driving car company.

Okay.

Or like, like you're NVIDIA. Right? And you've got a bunch of self-driving car tech. Yes, there's a developer piece of that. But really, that's a large design win. That's an enterprise sale, right? That's top-down. I'm selling to the, probably the board of the company, right? That's buying into all the economics. I don't know anything about these businesses, but you know, that's a very, very different motion and journey than you or I selling a Kubernetes operator to bottoms up through an organization. So those models exist. And they're important, but they're uncommon.

I mean, you went up against Pivotal, which was probably doing that, right?

Yeah.

I mean, my take would be generally like, if your product is going to be adopted by the developers and loved by the developers, then there's probably a bottom-up motion that can happen anyway. And so if you're only doing top-down and you're not getting the bottom-up, then either, your product's not really ready for the developers, or they're not gonna wanna use it anyway, and they're gonna wanna use something else?

There is a mode of developer and enterprise, as opposed to 1, 2, 3, as opposed to just like developer team enterprise, right? And my guess is that Pivotal was probably more in that mode, which I think is an error condition.

With like Spring and these other things they were doing.

Yeah, and that's a little bit further back, but there is an old school open source mode, which is that, and I think that that, where you kind of give lip service to your developer program, and like it's important and it like gets you a little bit of groundswell, but you haven't mechanically connected to the operation of your business.

Got it.

And I would, out of ignorance, probably assign it to that category. Okay.

Feels like maybe in the security ecosystem there's maybe a little bit more of that like straight top-down.

Yep.

'Cause there's more centralized buying within like a CISO.

Or like there are certain kinds of infrastructure decisions. Like if I'm buying Wi-Fi, I don't, access points, I don't do that on an individual basis.

Right.

There are a whole set of cases where there's an asymmetry between the buyer and the user, and where that kind of makes sense. There's actually kind of an interesting example here that's relevant to maybe our world a little more closely, which is productivity software.

OK.

Right? Because suites, i.e., Office 365 and G Suite, are sold enterprise-wide, top-down. Sure. Right? Those are lock-in, wall-to-wall decisions that happen. Those do not happen. Bottoms up. So there are some interesting debates to be had about what the nature and the shape of the productivity market looks like because of that dynamic.

And there's a little bit of freemium from the Gmail side since you can sort of start to use that, right?

Yeah, but the only time where that really directly gets you anywhere would be some online conversion to team, which is exactly how Google tries to do it, right? They sell to a team or an SMB by throwing in some AdSense credits, whatever the case is.

Interesting.

I'm on shaky ground with this analogy though, so.

But I mean, it also kind of highlights this other point, which is like, I mean, a collaboration tool is not necessarily very useful on an individual level, right?

But here's the beauty of this discussion. We are having a discussion about the theory of the business for G Suite or Pivotal. We could be wrong.

Sure.

But we're having a discussion about the theory of the business. And insofar as we're just having more of these discussions, as a community, we're better training ourselves to kind of apply that reasoning to ourselves.

And more importantly, probably have this within your team.

Exactly.

Have this like regularly and be clear about what your current theory of the business is at any moment and revisit it every month, every 2 months, or, you know, some cadence.

Yep.

You know, probably faster at the beginning and more, you know, quarterly and annually, you know, later on if you're publicly traded.

I'm telling you, I've spent a lot of time with this 1-2-3 Framework, and anybody who's worked with me, anybody who has the misfortune of listening to this will know this. The further I get into it, the more predictive it becomes. So even when you think about kind of what are the metrics that you need, you know, how you start thinking about how you measure it, I genuinely believe there are a lot of commonalities here. So I do think that there's prior, really helpful prior art that you can borrow from.

Yeah, it definitely makes sense. And then your point is your messaging, your product, everything needs to sort of like, capture these 3 things and you should be—

No.

Oh, no.

That you as a business need to understand which of those 3 you're operating in. One way of thinking about it is just they're almost like 3 distinct but connected businesses. So maybe you're engaged in all 3, maybe you're engaged in one of the 3. But if you're doing a— and it's not to say that you can't do marketing activities that apply to all 3, or they kind of overlap a little bit. I'm not going to be, you know, it's not— a kind of a strict thing. But you have the intention of, I'm trying to do X. This is for the free business. This is for the self-serve business. This is for the enterprise business. And the motions I'm gonna use, how I do marketing is different for those. How I do customer support is different for those, right? And I'm gonna have the intentionality of saying, okay, I'm building this for 1, 2, or 3, or I'm launching this for one of those groups. In an ideal world for me, I'll even give you some kind of practical examples of kind of what this looks like fully materialized. And we came close-ish to having this at Heroku, where you would even have, a PM owner for each of those. So it really becomes almost like a line of business organizing principle. So you would, you would have a PM who's holistically thinking about, okay, if I'm in free, my job is to drive signups and activation, ultimately activity. So like, those are my core metrics. I'm just thinking about features that do that. That's my slice. If I'm in self-serve, I'm thinking about, right, conversion, retention, whatever those things are. And I'm going to be thinking about about whatever those things are, as well as like the collaboration features that make sense. So you can think about organizing product that way, and you can even think about organizing the business that way. And by that I mean, um, you're gonna have different functions— marketing, sales, support, whatever— that are gonna have to align to that. But having cross-functional meetings around each of these, I find to be hugely useful. So this is something I've done at multiple organizations where I've come in and things have been a little you know, not working great. How do you help make it better? It's like, okay, we're gonna do 3 meetings. Once a month, we're gonna have our free meeting and we're gonna have representation from marketing PM, maybe sales, whoever's appropriate. And we're gonna talk holistically about the business and we're gonna talk about it in that way, right around those metrics. And we're gonna talk with marketing, we're gonna talk about product, we're gonna talk about support. What are all the things we're doing, stacked, ranked, aligned that we're doing to support this business, which is free. Okay, next, next meeting, we're gonna do the same thing for team. Next, we're going to do the same thing, talk about enterprise. And if you don't align that around those different business lines, then whatever sales is doing, whatever marketing is doing, just becomes kind of a functional view, and it can be very difficult to align. And it's also then sales is pissed because why is marketing working on this thing that isn't for them, and yada, yada, yada.

Yeah, it's broader. It's more than just like, it's really the whole framework. It's the theory of the business. It's like know where each part is operating, what you're doing. And the other interesting piece here is I think with this framework, it allows you to not just look at like what you've done, but look at what you aim to do and then evaluate which of those things is the weakest area at any point, right? Like, you know, in the beginning, maybe you're not focused at all on 3, you're just doing 1 and 2. And then you realize, okay, our top of funnel is weak, so we need to focus on 1 for a while, right? Do new features around that or something.

Yep, and I'll go back to what I was saying earlier, because I by no means mean to imply that a random company should be engaged in all 3 of these. You know, we at Heroku were when we were a multi-hundred million dollar business. When we were a sub-50 business, we weren't at all. So I'm not saying, gee, we're, your theory of the business should encompass your answers for all these things, but you should have the intentionality of knowing where you are. Which is you're likely in free if you're starting, right? You're likely thinking about when do you do team. And getting back to kind of this Goldilocks idea, the hardest question that I, or discussion I have with CEOs is typically, when do you make that investment? And how do you make that investment? And kind of when do you move from kind of being in one to being in two, one and two, or when do you move from being in one and two to three? And I often have to frankly kind of check myself because I can be like— and I think this is a common outsider. I'm not a VC, but VC-ish point of view, like, rah, rah, rah, go, go, go, you know, go build all the things. And in practice, if you do it too soon, it can be really difficult because you don't have the kind of groundswell and base to build the next business on. And the closest I've come to a rule of thumb, which I'm entirely unsure is true, is that I would be hard-pressed to think about going from team to enterprise anything sub $10 million. That's my, the closest I can come. At Heroku, we were materially more than that before we made that move. So, you know, when you even see a company that's doing like $3 or $4 million, you're like, "God, you guys are doing great, let's go, you know, rah, rah, rah." I sometimes have to hold myself back and remember that no, letting a team business more fully develop will make that transition to enterprise oh so much easier because you have all these customers that are at the top of their capabilities with, or your capabilities with Teams and they're ready and they're ready to help you go on that enterprise journey.

Yeah, there's a bit of a luxury of time there, right? Where if you're looking at some inbound enterprise deals that you need to get done and you're like, these will be the biggest deals and they're gonna move us from 3 to 6, You're probably going to do it at that point unless you have just like huge amounts of funding or runway that you're like, no, we're gonna stay super focused on staying in 1 and 2 and push that off for another 2 years until we're really ready to focus on it.

I think that's really helpful for you to bring that up 'cause it's exactly the kind of hard, not pithy discussion that one has to have. And we've all lived that. Yeah. I remember even at Heroku, there were times where customers were willing to write us huge checks before we had HIPAA compliance. And we're like, okay, well, "Can we do kind of, you know, to one-off this for these customers and would it be worth it?" And I'm very grateful that we said no. This is with the luxury of time, but I'm hard-pressed to think of a lot of cases where companies are happy they said yes.

Yeah, I mean, unless they're still alive, right? Like, you know, that's—

Well, yeah, what's the, there's survivor bias. I don't know if the survivor bias though, which way it points.

I believe that like you basically do, whatever you need to, to survive. And like sometimes that's just like, it's kind of obvious.

It's very Donner Party of you.

Yeah, exactly. As an entrepreneur. Exactly, yeah. But no, as a startup, you're like, we know we need to get this done if we're gonna keep going. And like, it's just like all debt, right? It's just debt. You're just taking on some amount of debt and there's financial debt, there's product debt, and there's technical debt. And like you're accepting it and you're saying, yep, it's debt, we gotta pay it back later.

Or we need it now. Here's what I would worry about. If a company came to me that I work with and was like, we have this opportunity for this million-dollar deal from this customer. You know, what do you think? Should we do it? I would ask a lot of questions about where that deal came from. Is it because their sales organization is pointed in the wrong direction? And super, super common, right, is over-rotation to enterprise. You've got a successful free open-source community online thing New CEO come in, I'm not gonna name names, and you bring in an enterprise sales team and you start knocking on doors, and they're like, they start having the most predictable conversations for a bunch of compliance features you don't have. That puts a lot of pressure on PM and engineering, which can't deliver those things, and now you've got this kind of, but oh, there's this deal waiting out there if we can just do this thing.

We just do this thing.

We just do the thing. And then what you end up doing is skipping team, right? So more often than not, I'm guessing that that is a sign of not being true to your theory of the business and trying to shortcut something for some short-term enterprise gain. And that fails 99.9% of the time. Because what you end up— what ends up happening, quite fascinating, is your sales reps end up selling team deals. Because the only thing that they can actually match to the market is like, what is— instead of a $200K, $500K deal, it's a $25K deal. It should be transacted online.

Right.

Now the economics of your sales Adam Gross' function is broken, and now you're in the worst of both worlds. You've got an enterprise sales motion that's effectively serving your team's business, and you're in neither of them well. And that always ends in calamity.

Yeah, that's interesting. Always.

Yeah. And that happens a lot.

Yeah. I know, and I guess like my point is just simply, if you can avoid it, do, but if it's the thing that's gonna keep your business around for another 2 years, like you do it. I just know the nuance of running companies and you're like, ugh, we do this thing, it's gonna be painful.

That's why I have the luxury. I'm not an entrepreneur right now. I can say whatever, I don't have to live it. I can just pontificate about it.

Yeah, I think this part of it is just like the reality is there is a lot of really great advice and this is really sound advice. And it's, I think some of the stuff we talked about, Theory of the Business, the other pieces are really important. And there's just a lot of times other rules are like, you know, maybe—

I'm a frameworks guy. Yeah. Conjoined triangles of success.

They are amazing.

That's what I'm peddling.

They're amazing. Adam, I know you have to run, so thank you so much. This was incredible. Well, I mean, I really appreciate all your insights.

It was my pleasure, and thank you for all the great podcasts. I enjoy listening to them.

Awesome. Thank you. That's all we have time for today. If you're interested in being a guest on this show, or if you'd like to suggest a topic, or just to learn more about Enterprise features, find us at enterpriseready.io. To learn more about Heavybit, visit heavybit.com to check out the library. It's packed with amazing talks on sales, marketing, product, and general management from founders of developer tools companies and other industry leaders. This podcast is also brought to you by my company, Replicated, where we enable cloud-native software vendors like HashiCorp, CircleCI, Snyk, and many others to operationalize and scale the distribution of their modern on-prem applications to the largest enterprise customers. Check us out at replicated.com.